[14:48] slyon: hey, you around? [14:49] Eighth_Doctor: hey! [14:50] how are we doing for https://github.com/canonical/netplan/pull/285? [14:50] and VXLAN support? [14:51] also, is it intentional that netplan can't built on RHEL 8? [14:51] Eighth_Doctor: Implementation is done for VRF, currently under review. [14:51] I tried building netplan on RHEL 8, and it choked on a missing glib2 function [14:52] VXLAN is next up on my list, a draft has been posted in https://github.com/canonical/netplan/pull/272 – but that needs quite some extra work, still [14:52] both VRF and VXLAN are planed to be released in the upcoming netplan v0.105 due in August [14:52] okay [14:53] It is certainly not intentional that netplan can't be built on RHEL 8... did you try using `make` or `meson`? [14:53] ah the breaking glib change... I think I made it functional using old and new glib... let me check [14:54] Eighth_Doctor: this patch should be included in the current 0.104 release: https://github.com/canonical/netplan/commit/15c98fec3948c19854f270225f552aa50d9cabcd [14:54] is there any other glib problem? [14:55] yeah [14:55] gimme a sec and I'll pull it up [14:56] I do vastly prefer meson over make, but I haven't switched the Fedora/EPEL package to it yet [14:56] I don't think 0.104 had it [14:57] Eighth_Doctor: ok. for < 0.104 you could probably apply/adopt the patch I pasted above to make it work, using old glib [14:58] the glib patch is in 0.104 [14:58] it still ftbfs [14:58] there's a different glib2 function [14:58] * Eighth_Doctor is running the build again to get that issue [14:59] wrt meson: we need a relatively new meson (>= 0.61 IIRC) so that probably won't work for RHEL [14:59] yeah, it's currently at 0.58 [15:00] so I think I'm stuck with make for a while [15:00] yes. [15:00] slyon: g_clear_list() doesn't exist in glib2 2.56 [15:00] let's see if we can find a solution to that other glib issue... I might have missed it in Debian/Ubuntu [15:00] which is what's present in RHEL 8 [15:01] Eighth_Doctor: I need to run for a meeting now. Will have a look at g_clear_list() later. (Or if you feel like, you could prepare a patch/PR) [15:01] thank you very much for your involvement in netplan to cover the RPM side, btw! [15:02] 👍️ [15:08] slyon: I'm not sure how to deal with g_clear_list(), since I am not very familiar with glib2 stuff [15:08] but if you can find a fix later today, that'd be great [15:33] I guess we could add something like this https://gitlab.gnome.org/GNOME/glib/-/issues/1943 to a header, isolated by a "#if GLIB_CHECK_VERSION (2, 56, 0)" macro to locally define that function for builds on old glib [15:55] Eighth_Doctor: does something like this work for you? https://pastebin.com/NtdhQPHH [15:55] slyon: I can't access pastebin.com here [15:55] can you use paste.centos.org or similar pastebin? [15:56] https://paste.centos.org/view/acceab72 [15:56] trying to reproduce this on Ubuntu Bionic (glib 2.56) I can see another similar issue: g_hash_table_steal_extended -Werror=implicit-function-declaration – It might need a similar fix [15:57] 👍️ [15:57] yeah, we might want to introduce CI on CentOS 8 once this is all fixed [15:58] This has been in glib since 2018 times... so I'm not sure if I really want to have glib symbols defined in upstream netplan, just for backwards compatibility. Maybe it'd be better to add that patch to the rpm package locally? [15:58] It would be great to get CentOS 8 CI, though. (I want Debian, too, but didn't find the time to set that up, yet) [15:59] well, at least having CentOS 8 in CI will give decent compatibility coverage [15:59] ack [16:03] my recommendation is to use alternate names rather than keeping the glib names for compat functions [16:03] e.g. np_g_* rather than just g_* [16:09] yeah.. but then we'd need to differentiate between the two symbol names when calling the funciton... As I said, I'm not sure if id' want to include those glib functions inside netplan headers at all... :-/ I need to think about this a bit more. [16:09] gtg now