1.9.2 Regression. 'Use UTC Time' in reporter settings is ignored.

[barjac]

All in the summary.

[tmiw]

I tried to duplicate this with the changes in PR #542 and I don't think I can now, so I could have ended up fixed this in the process of doing other changes. Try it out and let me know?

[barjac]

Yes it seems fixed in ms-reporter-regressions - nice!

[tmiw]

Cool, I'll leave this open until you confirm that the other changes in #542 work as intended. 👍

[Tyrbiter]

I believe that all the changes work for me with the exception of the UTC time setting, can anyone else confirm this?

I can monitor active stations with the modem running and with reporting to FreeDV Reporter turned off. However, changing the UTC setting makes no difference either with FreeDV reporting enabled or not.

[tmiw]

Seems to for me. (Note the Last TX columns below.)

UTC Time off

UTC Time on

I've been changing that setting prior to pushing Start since it's grayed out otherwise.

[Tyrbiter]

OK, well I have checked that the code I'm building has the latest PRs applied, however nothing happens when I select UTC in the Options dialog and re-open the reporter or indeed restart freedv-gui.

I had a look at system settings, time and date is automatic and London, UK is selected (which indicates BST at this time of year).

I think this used to work, but will confess that I have not looked at it carefully but it doesn't work for me now.

[barjac]

On 19/09/2023 17:36, Brian wrote:

OK, well I have checked that the code I'm building has the latest PRs applied, however nothing happens when I select UTC in the Options dialog and re-open the reporter or indeed restart freedv-gui.

I had a look at system settings, time and date is automatic and London, UK is selected (which indicates BST at this time of year).

I think this used to work, but will confess that I have not looked at it carefully but it doesn't work for me now.

It's working OK for me now but there was a build where it didn't when I reported it.

Also on BST here and the time changes for all dates in the reporter when checking/un-checking the box and OKing the dialogue. With or without Reporting enabled.

[Tyrbiter]

I'm stumped, everything seems to be set correctly, I have re-diff'd the source in my local git tree with the source I use to build from and there are no differences in the src directory or indeed anywhere else.

As a check I rebuilt using build_linux.sh and ran the newly created binary, the same problem shows up.

The system reports the correct timezone, I get the correct time with the date command and date --utc provides the correct UTC time.

Going to re-check if the callsign list shows UTC when selected.

Any ideas?

[tmiw]

Is it possible that FreeDV is somehow getting the incorrect timezone? Or is it showing times in BST and just not converting times properly?

[barjac]

@tyrbiter What does locale show?

$ locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL=

[Tyrbiter]

Locale outputs identical information to your system @barjac

@tmiw can you suggest some debug code to try? I see the same behaviour when using the freedv icon or starting from command line, also the same with the packaged binary or the locally built static library version.

It's very odd, but I can't recall exactly when it stopped working, assuming that it ever did when using the internal reporter.

[Tyrbiter]

I modified the code to be:

return tmpDate.Format(_("%x %X %Z"), timeZone);

The reporter now shows BST whether or not the Use UTC setting is ticked. That suggests something in the conversion code to me, but I am no expert.

I have just managed to get an on-air signal into freedv and the callsign list is showing UTC times when the Use UTC setting is ticked. Something in the reporter code then?

Further investigation reveals that the useUTCForReporting string is not found anywhere in my ~/.freedv file, but I do have this as one section:

[CallsignList] UseUTCTime=0

and this as another:

[Reporting] Enable=1 Callsign=G8SEZ GridSquare=IO92tc Frequency=5366500 FrequencyList=3.6250,3.6400,3.6430,3.6930,3.6970,5.3665,5.3715,5.4035,7.0450,7.1770,14.2360,14.2400,18.1180,21.3130,24.9330,28.3300,28.7200,10489.6400 ManualFrequencyReporting=0 [Reporting/PSKReporter] Enable=1 [Reporting/FreeDVReporter] Enable=1 UseMetricDistances=0 [Reporting/FreeDV] Hostname=qso.freedv.org Enable=1 CurrentBandFilter=0 UseMetricDistances=0 BandFilterTracksFrequency=0 TxRowBackgroundColor=#FC4500 TxRowForegroundColor=#000000 RxRowBackgroundColor=#379BAF RxRowForegroundColor=#000000

I think that the problem is that the Reporting TZ is not actually set or saved.

grepping for the string gives this:

bdm@deangelis:~/git/freedv-gui/src$ grep -r useUTCForReporting * config/ReportingConfiguration.cpp: , useUTCForReporting("/CallsignList/UseUTCTime", false) config/ReportingConfiguration.cpp: load(config, useUTCForReporting); config/ReportingConfiguration.cpp: save(config, useUTCForReporting); config/ReportingConfiguration.h: ConfigurationDataElement useUTCForReporting; dlg_options.cpp: m_ckbox_use_utc_time->SetValue(wxGetApp().appConfiguration.reportingConfiguration.useUTCForReporting); dlg_options.cpp: wxGetApp().appConfiguration.reportingConfiguration.useUTCForReporting = m_ckbox_use_utc_time->GetValue(); freedv_reporter.cpp: if (wxGetApp().appConfiguration.reportingConfiguration.useUTCForReporting) main.cpp: if (wxGetApp().appConfiguration.reportingConfiguration.useUTCForReporting)

[tmiw]

Maybe add the debug fprints in src/freedv_reporter.cpp? (Lines 892-911)

    wxRegEx timezoneRgx(_("([+-])([0-9]+):([0-9]+)$"));
    wxDateTime::TimeZone timeZone(0); // assume UTC by default
    fprintf(stderr, "received %s from server\n", (const char*)tmp.ToUTF8());
    if (timezoneRgx.Matches(tmp))
    {
        auto tzOffset = timezoneRgx.GetMatch(tmp, 1);
        auto hours = timezoneRgx.GetMatch(tmp, 2);
        auto minutes = timezoneRgx.GetMatch(tmp, 3);

        int tzMinutes = wxAtoi(hours) * 60;
        tzMinutes += wxAtoi(minutes);

        if (tzOffset == "-")
        {
            tzMinutes = -tzMinutes;
        }

        timezoneRgx.Replace(&tmp, _(""));
        fprintf(stderr, "time zone offset from UTC in minutes: %d\n", tzMinutes);

        timeZone = wxDateTime::TimeZone(tzMinutes);
    }

[Tyrbiter]

Ah, we crossed. I am just adding in the debug now.

[tmiw]

Also keep in mind that the settings only save on successful exit. If you Ctrl-C the process (for example), changes made to the settings don't get committed.

[Tyrbiter]

Also keep in mind that the settings only save on successful exit. If you Ctrl-C the process (for example), changes made to the settings don't get committed.

I have never done that, I always stop the modem and use the File->Quit or Exit (I forget which it is)

Debug output with the added debug:

received 2023-09-20T15:50:39+00:00 from server time zone offset from UTC in minutes: 0

[Tyrbiter]

I don't see anything to allow me to set UTC in the reporter window, I thought it would use the setting for the callsign list.

[tmiw]

Yeah, it uses the "Use UTC Time" checkbox here for that (corresponding to the following in the config):

[CallsignList]
UseUTCTime=0

If you check that checkbox and then exit FreeDV, does your config file change UseUTCTime to 1?

[Tyrbiter]

Yeah, it uses the "Use UTC Time" checkbox here for that (corresponding to the following in the config):

[CallsignList]
UseUTCTime=0

If you check that checkbox and then exit FreeDV, does your config file change UseUTCTime to 1?

Yes, it does. The thing is that this code in freedv_reporter.cpp:918

    if (wxGetApp().appConfiguration.reportingConfiguration.useUTCForReporting)
    {
        timeZone = wxDateTime::TimeZone(wxDateTime::TZ::UTC);
    }
    else
    {
        timeZone = wxDateTime::TimeZone(wxDateTime::TZ::Local);
    }

is looking for an entry in the config file called 'useUTCForReporting' which does not exist in my ~/.freedv and doesn't get set anywhere I can find, there is no separate checkbox for reporter UTC even though the code seems to suggest there is.

In ReportingConfiguration.cpp I see this line:

, useUTCForReporting("/CallsignList/UseUTCTime", false)

which seems like it should read one config entry, give it a different name and then these two:

load_(config, useUTCForReporting);

and:

save_(config, useUTCForReporting);

store it separately.

This doesn't seem to work for me, maybe this is a Fedora bug in wxWindows code?

[Tyrbiter]

Just noticed the boilerplate at the top of ReportingConfiguration.cpp reads ReportingConfiguration.h

Only a minor thing :)

[tmiw]

Yes, it does. The thing is that this code in freedv_reporter.cpp:918

    if (wxGetApp().appConfiguration.reportingConfiguration.useUTCForReporting)
    {
        timeZone = wxDateTime::TimeZone(wxDateTime::TZ::UTC);
    }
    else
    {
        timeZone = wxDateTime::TimeZone(wxDateTime::TZ::Local);
    }

is looking for an entry in the config file called 'useUTCForReporting' which does not exist in my ~/.freedv and doesn't get set anywhere I can find, there is no separate checkbox for reporter UTC even though the code seems to suggest there is.

useUTCForReporting (and the other configuration objects) have their associations with the config file variables set during startup. Note the below, where useUTCForReporting gets associated with UseUTCTime under [CallsignList]:

, useUTCForReporting("/CallsignList/UseUTCTime", false)

It doesn't mean that there's supposed to be a config variable called "useUTCForReporting" :)

This doesn't seem to work for me, maybe this is a Fedora bug in wxWindows code?

I'm not sure how that would be the case unless the code somehow wasn't recognizing that the checkbox was being checked. Questions:

1. Do you push OK or Apply to save that setting?
2. Try adding this debug code just below dlg_options.cpp line 843 and then toggle that setting again:

fprintf(stderr, "useUTCForReporting now %d\n", wxGetApp().appConfiguration.reportingConfiguration.useUTCForReporting.get());

[Tyrbiter]

Questions:

1. Do you push OK or Apply to save that setting?

I have tried both, OK and Apply followed by OK.

2. Try adding this debug code just below dlg_options.cpp line 843 and then toggle that setting again:

fprintf(stderr, "useUTCForReporting now %d\n", wxGetApp().appConfiguration.reportingConfiguration.useUTCForReporting.get());

OK, so the result is as follows:

[2023-09-20 19:13:18] [connect] Successful connection [2023-09-20 19:13:19] [connect] WebSocket Connection 208.85.243.198:80 v-2 "WebSocket++/0.8.2" /socket.io/?EIO=4&transport=websocket&t=1695233598 101 useUTCForReporting now 0 [2023-09-20 19:13:42] [warning] got non-close frame while closing [2023-09-20 19:13:42] [disconnect] Disconnect close local:[1000,End by user] remote:[1000] [2023-09-20 19:13:43] [connect] Successful connection [2023-09-20 19:13:43] [connect] WebSocket Connection 208.85.243.198:80 v-2 "WebSocket++/0.8.2" /socket.io/?EIO=4&transport=websocket&t=1695233622 101 useUTCForReporting now 1

which suggests that the problem is further through the code path from the point where the setting is changed in dlg_options.cpp

I have added some more debug as follows:

    if (wxGetApp().appConfiguration.reportingConfiguration.useUTCForReporting)
    {
        fprintf(stderr, "using UTC for reporting\n");
        timeZone = wxDateTime::TimeZone(wxDateTime::TZ::UTC);
        fprintf(stderr, "UTC timeZone is %d\n", timeZone);
    }
    else
    {
        fprintf(stderr, "using local TZ for reporting\n");
        timeZone = wxDateTime::TimeZone(wxDateTime::TZ::Local);
        fprintf(stderr, "Local timeZone is %d\n", timeZone);
    }

The debug output shows this:

using local TZ for reporting Local timeZone is 0 using local TZ for reporting Local timeZone is 0 using local TZ for reporting Local timeZone is 0 useUTCForReporting now 0 using local TZ for reporting Local timeZone is 0 using local TZ for reporting Local timeZone is 0 using local TZ for reporting Local timeZone is 0 using local TZ for reporting Local timeZone is 0 using local TZ for reporting Local timeZone is 0 using UTC for reporting UTC timeZone is 0 [2023-09-20 19:37:40] [disconnect] Disconnect close local:[1000,End by user] remote:[1000] [2023-09-20 19:37:41] [connect] Successful connection [2023-09-20 19:37:41] [connect] WebSocket Connection 208.85.243.198:80 v-2 "WebSocket++/0.8.2" /socket.io/?EIO=4&transport=websocket&t=1695235060 101 using UTC for reporting UTC timeZone is 0 using UTC for reporting UTC timeZone is 0

So

timeZone = wxDateTime::TimeZone(wxDateTime::TZ::UTC);

and

timeZone = wxDateTime::TimeZone(wxDateTime::TZ::Local);

always returns a value of 0

which seems incorrect to me, however I found this:

Notice that, as with FromTimezone(), using wxDateTime::Local as tz doesn't really make sense and may return a different object when DST is in effect and noDST is false.

Here:

https://docs.wxwidgets.org/3.0/classwx_date_time.html

I now hand over to you as I doubt I can work out what will do the right thing :)

[tmiw]

Since timeZone is an object, I'd recommend doing the following instead:

    if (wxGetApp().appConfiguration.reportingConfiguration.useUTCForReporting)
    {
      fprintf(stderr, "using UTC for reporting\n");
        timeZone = wxDateTime::TimeZone(wxDateTime::TZ::UTC);
        fprintf(stderr, "UTC timeZone is %d\n", timeZone.GetOffset());
    }
    else
    {
      fprintf(stderr, "using local TZ for reporting\n");
        timeZone = wxDateTime::TimeZone(wxDateTime::TZ::Local);
        fprintf(stderr, "Local timeZone is %d\n", timeZone.GetOffset());
    }

If wxWidgets is behaving properly, I suspect the UTC one will print 0 and the Local one will print something like 60.

[tmiw]

BTW I'm reopening the issue so that there's visibility to others (in case someone else is running into this too).

[Tyrbiter]

OK, I have changed the debug variable from timeZone to timeZone.GetOffset()

There is no change to the output, I just get 0 for both UTC and Local cases.

I'm going to hope that the answer to this starts here:

https://docs.wxwidgets.org/3.0/overview_datetime.html

[tmiw]

What's your TZ environment variable look like? Apparently wxDateTime::TZ::Local may be causing tzset() to get called, which can use it depending on what it's set to:

The tzset() function initializes the tzname variable from the TZ environment variable. This function is automatically called by the other time conversion functions that depend on the timezone. In a System-V-like environment, it will also set the variables timezone (seconds West of UTC) and daylight (to 0 if this timezone does not have any daylight saving time rules, or to nonzero if there is a time, past, present, or future when daylight saving time applies).

If the TZ variable does not appear in the environment, the system timezone is used. The system timezone is configured by copying, or linking, a file in the tzfile(5) format to /etc/localtime. A timezone database of these files may be located in the system timezone directory (see the FILES section below).

If the TZ variable does appear in the environment, but its value is empty, or its value cannot be interpreted using any of the formats specified below, then Coordinated Universal Time (UTC) is used.

[Tyrbiter]

OK, well:

$ ll /etc/localtime lrwxrwxrwx. 1 root root 35 May 2 2021 /etc/localtime -> ../usr/share/zoneinfo/Europe/London

and:

$ rpm -qf /usr/share/zoneinfo/Europe/London tzdata-2023c-1.fc38.noarch

which being an official package is in tzfile format.

$ echo $TZ

and as you can see there is no explicitly set TZ variable. Results of usual commands follow:

$ date Thu 21 Sep 12:51:36 BST 2023

$ timedatectl Local time: Thu 2023-09-21 12:52:11 BST Universal time: Thu 2023-09-21 11:52:11 UTC RTC time: Thu 2023-09-21 11:52:11 Time zone: Europe/London (BST, +0100) System clock synchronized: yes NTP service: active RTC in local TZ: no

[tmiw]

Just to make sure, this returns nothing, right?

$ env | grep TZ
$

Also, try adding tzset() to the top of FreeDVReporterDialog::makeValidTime_():

wxString FreeDVReporterDialog::makeValidTime_(std::string timeStr, wxDateTime& timeObj)
{    
    tzset();

    wxRegEx millisecondsRemoval(_("\\.[^+-]+"));
    wxString tmp = timeStr;
    millisecondsRemoval.Replace(&tmp, _(""));
    ...
}

[Tyrbiter]

Just to make sure, this returns nothing, right?

$ env | grep TZ
$

No, nothing at all.

Also, try adding tzset() to the top of FreeDVReporterDialog::makeValidTime_():

wxString FreeDVReporterDialog::makeValidTime_(std::string timeStr, wxDateTime& timeObj)
{    
    tzset();

    wxRegEx millisecondsRemoval(_("\\.[^+-]+"));
    wxString tmp = timeStr;
    millisecondsRemoval.Replace(&tmp, _(""));
    ...
}

This has not made any difference either.

[tmiw]

There's some other timezone stuff in wxWidgets that seems to be dependent on how it was built. It might be worth updating build_linux.sh as follows (note the added BOOTSTRAP_WXWIDGETS):

cmake $PULSEAUDIO_PARAM -DUNITTEST=$UT_ENABLE -DCMAKE_BUILD_TYPE=Debug -DCODEC2_BUILD_DIR=$CODEC2DIR/build_linux -DLPCNET_BUILD_DIR=$LPCNETDIR/build_linux -DBOOTSTRAP_WXWIDGETS=1 ..

and then building completely from scratch using build_linux.sh. Hopefully this helps.

[Tyrbiter]

I tried this, but the linker fails with the following:

[100%] Linking CXX executable freedv cd /home/bdm/git/freedv-gui/build_linux/src && /usr/bin/cmake -E cmake_link_script CMakeFiles/freedv.dir/link.txt --verbose=1 /usr/lib64/ccache/c++ -Wall -g CMakeFiles/freedv.dir/dlg_audiooptions.cpp.o CMakeFiles/freedv.dir/dlg_easy_setup.cpp.o CMakeFiles/freedv.dir/dlg_filter.cpp.o CMakeFiles/freedv.dir/dlg_options.cpp.o CMakeFiles/freedv.dir/dlg_ptt.cpp.o CMakeFiles/freedv.dir/freedv_reporter.cpp.o CMakeFiles/freedv.dir/main.cpp.o CMakeFiles/freedv.dir/plot.cpp.o CMakeFiles/freedv.dir/plot_scalar.cpp.o CMakeFiles/freedv.dir/plot_scatter.cpp.o CMakeFiles/freedv.dir/plot_spectrum.cpp.o CMakeFiles/freedv.dir/plot_waterfall.cpp.o CMakeFiles/freedv.dir/hamlib.cpp.o CMakeFiles/freedv.dir/serialport.cpp.o CMakeFiles/freedv.dir/topFrame.cpp.o CMakeFiles/freedv.dir/sox_biquad.c.o CMakeFiles/freedv.dir/util.cpp.o CMakeFiles/freedv.dir/eq.cpp.o CMakeFiles/freedv.dir/voicekeyer.cpp.o CMakeFiles/freedv.dir/playrec.cpp.o CMakeFiles/freedv.dir/ongui.cpp.o CMakeFiles/freedv.dir/freedv_interface.cpp.o -o freedv -Wl,-rpath,/home/bdm/git/freedv-gui/codec2/build_linux/src:/home/bdm/git/freedv-gui/LPCNet/build_linux/src: audio/libfdv_audio.a pipeline/libfdv_audio_pipeline.a config/libfdv_config.a gui/util/libfdv_gui_util.a reporting/libfdv_reporting.a sox/libfdv_sox.a /home/bdm/git/freedv-gui/codec2/build_linux/src/libcodec2.so.1.1 /usr/lib64/libpulse.so /usr/lib64/libhamlib.so ../sioclient_build/libsioclient.a /usr/lib64/libsamplerate.so /usr/lib64/libsndfile.so /usr/lib64/libspeexdsp.so /usr/lib64/libdl.a ../_deps/wxwidgets-build/lib/libwx_gtk3u_core-3.2.a ../_deps/wxwidgets-build/lib/libwx_baseu-3.2.a ../_deps/wxwidgets-build/lib/libwx_gtk3u_aui-3.2.a ../_deps/wxwidgets-build/lib/libwx_gtk3u_html-3.2.a ../_deps/wxwidgets-build/lib/libwx_baseu_net-3.2.a ../_deps/wxwidgets-build/lib/libwx_gtk3u_adv-3.2.a ../_deps/wxwidgets-build/lib/libwx_gtk3u_propgrid-3.2.a /home/bdm/git/freedv-gui/LPCNet/build_linux/src/liblpcnetfreedv.so.0.5 -lm /usr/lib64/libcurl.so ../_deps/wxwidgets-build/lib/libwx_gtk3u_core-3.2.a ../_deps/wxwidgets-build/lib/libwxpng-3.2.a ../_deps/wxwidgets-build/lib/libwxtiff-3.2.a ../_deps/wxwidgets-build/lib/libwxjpeg-3.2.a -lnotify ../_deps/wxwidgets-build/lib/libwx_baseu-3.2.a ../_deps/wxwidgets-build/lib/libwxzlib-3.2.a ../_deps/wxwidgets-build/lib/libwxregexu-3.2.a -lsecret-1 -ldl -lgtk-3 -lgdk-3 -lz -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lglib-2.0 -lgobject-2.0 /usr/lib64/libSM.so /usr/lib64/libICE.so /usr/lib64/libX11.so /usr/lib64/libXext.so /usr/lib64/libXtst.so /usr/lib64/libgnomevfs-2.so /usr/bin/ld: ../_deps/wxwidgets-build/lib/libwx_gtk3u_core-3.2.a(imagpng.cpp.o): undefined reference to symbol 'png_get_pHYs@@PNG16_0' /usr/bin/ld: /usr/lib64/libpng16.so.16: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[2]: [src/CMakeFiles/freedv.dir/build.make:469: src/freedv] Error 1 make[2]: Leaving directory '/home/bdm/git/freedv-gui/build_linux' make[1]: [CMakeFiles/Makefile2:1410: src/CMakeFiles/freedv.dir/all] Error 2 make[1]: Leaving directory '/home/bdm/git/freedv-gui/build_linux' make: *** [Makefile:156: all] Error 2

[tmiw]

Is it possible you may need to update libpng on your machine as well?

[Tyrbiter]

These are the installed versions:

libpng-1.6.37-15.fc39.x86_64 libpng12-1.2.57-18.fc39.x86_64 libpng-devel-1.6.37-15.fc39.x86_64 mingw64-libpng-1.6.37-11.fc39.noarch mingw32-libpng-1.6.37-11.fc39.noarch libpng12-devel-1.2.57-18.fc39.x86_64 libpng-1.6.37-15.fc39.i686

Not sure if there is anything newer, but I will have a look. libpng 1.6.40 exists, it is in Fedora 40 (rawhide in Fedora speak).

Also note that I have just moved on to Fedora 39 which will be released in October and is currently nominally a beta but is probably as stable as Fedora 38 was.

The libpng header files are here:

/usr/include/libpng16 /usr/include/libpng16/png.h /usr/include/libpng16/pngconf.h /usr/include/libpng16/pnglibconf.h /usr/include/png.h /usr/include/pngconf.h /usr/include/pnglibconf.h

the symbol name is in png.h, I assume the @@PNG16_0 is some sort of versioning macro?

$ grep png_get_pHYs /usr/include/libpng16/* /usr/include/libpng16/png.h:PNG_EXPORT(149, png_uint_32, png_get_pHYs, (png_const_structrp png_ptr, /usr/include/libpng16/png.h:PNG_EXPORT(198, png_uint_32, png_get_pHYs_dpi, (png_const_structrp png_ptr,

a wider grep reveals an #ifdef statement

/usr/include/libpng16/png.h-#ifdef PNG_pHYs_SUPPORTED /usr/include/libpng16/png.h:PNG_EXPORT(149, png_uint_32, png_get_pHYs, (png_const_structrp png_ptr, /usr/include/libpng16/png.h- png_const_inforp info_ptr, png_uint_32 res_x, png_uint_32 res_y, /usr/include/libpng16/png.h- int *unit_type));

[barjac]

In recently released Mageia 9 (that I am using) it's 1.6.38

[barjac]

@tyrbiter are you building in a clean chroot with only base system and buildrequires or on your actual machine?

[Tyrbiter]

@Tyrbiter are you building in a clean chroot with only base system and buildrequires or on your actual machine?

I am doing what I normally do using the normal machine, I suppose I could try and build using mock in a chroot, it might be possible now that Fedora 39 actually has codec2-1.2 in the repos. It wouldn't have been before without using build system fu that I don't possess.

[tmiw]

I'm downloading Fedora 39 right now and will try this in a VM (including changing the timezone to BST in case it's something to do with that).

EDIT: the live CD is taking an awfully long time to boot. Not sure if that's expected for a beta version of Fedora.

EDIT 2: well, then. Guess I need to install 38 and then upgrade to 39 from there:

[tmiw]

OK, I was able to get FreeDV running on a freshly upgraded Fedora 39. Even after changing timezone to BST, it looked like it was working for me. I did run it with its own wxWidgets and not the Fedora packaged one, if that matters.

[barjac]

@Tyrbiter I would recommend only using mock (or similar) to build packages for testing, otherwise you have no proper control of BuildRequires. That way dnf or whatever package manager you use will look after the run time Requires, Conflicts etc. I never build or install directly in my system, I only install built packages.

[Tyrbiter]

OK, I was able to get FreeDV running on a freshly upgraded Fedora 39. Even after changing timezone to BST, it looked like it was working for me. I did run it with its own wxWidgets and not the Fedora packaged one, if that matters.

I don't know. The current wxWidgets for Fedora 38 and 39 is version 3.2.2.1, which I would expect to be the same as you are using. That is what is installed, the old compat packages have just been retired, that was v 3.0.5.1 but I have just noticed that they are still installed on one of my updated machines which is the one that runs freedv.

I will be sorting this out later today and see if it helps.

[Tyrbiter]

Well I now have the answer, it seems that an update to use wxWidgets 3.2 never got into my modified spec file, so all this time I have been building against wxWidgets 3.0 due to this.

I have now fixed this up and rebuilt, I now have working GMT selection in the freedv internal reporter. Quite why this was not also broken in the callsign list I don't know, I assume that it used a different function call or something like that. My wxWidgets features also look slightly different, I have not noticed these differences before.

@barjac Yes, this would have been caught more easily if I was using a chrooted mock build process but that has only been possible for a short time since the codec2-1.2.0 update became part of Fedora 39 (it wasn't in Fedora 38), before that this would have been unable to use the updated codec2. I will have to read up on how to force mock to use packages that are not in the standard repos.

I think this issue can now be closed :) Sorry for all the grief, I have certainly learned something useful.

[tmiw]

Sounds good! Glad you were able to figure out the problem :)

[barjac]

I will have to read up on how to force mock to use packages that are not in the standard repos.

I cheat, I do the reverse. I have a local Mageia mirror and a local Extra repo that all my builds go into. My build script takes a -e option which adds my Extra repo to the mirror for the build. The script uses iurt by default or with -m it uses mock. I devised this method years ago as I never managed to force iurt to use an external repo, maybe mock will but I didn't try as it was easy to just add the mock option to the script. Have fun ;)