The CommonMark module cannot be built using gcc 15 and perl 5.40.1

This is perl-5.40.1-515.fc42 as packaged in Fedora rawhide (the dev branch of Fedora)

Module: XS

Description
Since upgrading from gcc 14 to 15, the perl-CommonMark package cannot be rebuild. This does not look like an error in the CommonMark module but one in the XS module from core.

gcc -c   -D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   -DVERSION=\"0.310100\" -DXS_VERSION=\"0.310100\" -fPIC "-I/usr/lib64/perl5/CORE"   CommonMark.c
CommonMark.c: In function ‘XS_CommonMark__Node_interface_get_node’:
CommonMark.c:675:18: error: too many arguments to function ‘XSFUNCTION’; expected 0, have 1
  675 |         RETVAL = XSFUNCTION(node);
      |                  ^~~~~~~~~~ ~~~~
CommonMark.c: In function ‘XS_CommonMark__Node_interface_get_int’:
CommonMark.c:701:18: error: too many arguments to function ‘XSFUNCTION’; expected 0, have 1
  701 |         RETVAL = XSFUNCTION(node);
      |                  ^~~~~~~~~~ ~~~~
[...]

Steps to Reproduce
Build the CommonMark module using gcc 15 and Perl 5.40.1

Expected behavior
The module should build successfully

Perl configuration

+ /usr/bin/perl -V
Summary of my perl5 (revision 5 version 40 subversion 1) configuration:
   
  Platform:
    osname=linux
    osvers=6.11.0
    archname=x86_64-linux-thread-multi
    uname='linux localhost 6.11.0 #1 smp preempt_dynamic 6.11.0 x86_64 gnulinux '
    config_args='-des -Doptimize=none -Dccflags=-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Dldflags=-Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1   -Dccdlflags=-Wl,--enable-new-dtags -Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1   -Dlddlflags=-shared -Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1   -Dshrpdir=/usr/lib64 -DDEBUGGING=-g -Dversion=5.40.1 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5/5.40 -Dsitearch=/usr/local/lib64/perl5/5.40 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize -Duse64bitint'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
  Compiler:
    cc='gcc'
    ccflags ='-D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    optimize='  -g'
    cppflags='-D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fwrapv -fno-strict-aliasing -I/usr/local/include'
    ccversion=''
    gccversion='15.0.1 20250114 (Red Hat 15.0.1-0)'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='gcc'
    ldflags ='-Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1  -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib64 /lib64 /usr/lib64 /usr/local/lib /usr/lib
    libs=-lpthread -lresolv -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lpthread -lresolv -ldl -lm -lcrypt -lutil -lc
    libc=/lib/../lib64/libc.so.6
    so=so
    useshrplib=true
    libperl=libperl.so
    gnulibc_version='2.40.9000'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,--enable-new-dtags -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 '
    cccdlflags='-fPIC'
    lddlflags='-lpthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1  -L/usr/local/lib -fstack-protector-strong'


Characteristics of this binary (from libperl): 
  Compile-time options:
    HAS_LONG_DOUBLE
    HAS_STRTOLD
    HAS_TIMES
    MULTIPLICITY
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_HASH_FUNC_SIPHASH13
    PERL_HASH_USE_SBOX32
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    PERL_USE_SAFE_PUTENV
    USE_64_BIT_ALL
    USE_64_BIT_INT
    USE_ITHREADS
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
    USE_REENTRANT_API
    USE_SITECUSTOMIZE
    USE_THREAD_SAFE_LOCALE
  Locally applied patches:
    Fedora Patch1: Removes date check, Fedora/RHEL specific
    Fedora Patch2: support for libdir64
    Fedora Patch3: use libresolv instead of libbind
    Fedora Patch4: USE_MM_LD_RUN_PATH
    Fedora Patch5: Provide MM::maybe_command independently (bug #1129443)
    Fedora Patch6: Dont run one io test due to random builder failures
    Fedora Patch8: Define SONAME for libperl.so
    Fedora Patch9: Install libperl.so to -Dshrpdir value
    Fedora Patch10: Make *DBM_File desctructors thread-safe (RT#61912)
    Fedora Patch11: Replace EU::MakeMaker dependency with EU::MM::Utils in IPC::Cmd (bug #1129443)
    Fedora Patch12: Link XS modules to pthread library to fix linking with -z defs
    Fedora Patch13: Pass the correct CFLAGS to dtrace
    Fedora Patch200: Link XS modules to libperl.so with EU::CBuilder on Linux
    Fedora Patch201: Link XS modules to libperl.so with EU::MM on Linux
    Fedora Patch202: Add definition of OPTIMIZE to .ph files
  Built under linux
  Compiled at Jan 20 2025 00:00:00
  @INC:
    /usr/local/lib64/perl5/5.40
    /usr/local/share/perl5/5.40
    /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib64/perl5
    /usr/share/perl5

This looks like it's caused by a combination of gcc-15 and the INTERFACE: XS feature.

Can someone who has access to gcc-15 or later on Linux build a threaded perl-5.40.1 and attempt to install Common Mark. (I can only get gcc-14.)

XSUB.h: fix C23 incompatibility in XSINTERFACE_* macros

GCC 15 hasn't been released yet. But anyway, this issue is because GCC 15 bumped the default C standard version to C23, and in C23 the meaning of an empty prototype has changed.

In the presence of the INTERFACE keyword (which allows the same XSUB to wrap multiple C functions by storing a pointer to the C function in every CV associated with that XSUB), the C code generated by the XS parser relies on the XSINTERFACE_CVT macro to declare a function pointer variable. In XSUB.h, this macro is defined as: #ifdef __cplusplus # define XSINTERFACE_CVT(ret,name) ret (*name)(...) #else # define XSINTERFACE_CVT(ret,name) ret (*name)() #endif Presumably gcc-15 is complaining about a pointer to a function which has non-zero number of args begin declared as some_type (*my_function_ptr_var)() Is there a portable way in C to tell the compiler not to complain about this, or so we need to make the generated C code in some way include the function arg types?

…

-- "I used to be with it, but then they changed what ‘it’ was, and now what I’m with isn’t it. And what’s ‘it’ seems weird and scary to me." -- Grandpa Simpson (It will happen to you too.)

(Moving this discussion back onto problem ticket, rather than PR #23194) Leon wrote:

I'm not sure this fix is right (I have to dig deeper for that), but I am very sure that the implementation of the `INTERFACE` feature is rather broken and should probably be fixed. xsubpp knows the types of the arguments of the function, it should be able to cast to the right type without needing this silly macro.

It's complicated by the fact that there is also the INTERFACE_MACRO: XS keyword, which allows code to specify their own macros to replace the default XSINTERFACE_FUNC and XSINTERFACE_FUNC_SET macros. I'm not sure it would be possible to change things in a back-compat way for code which defines its own macros. On the other hand, the INTERFACE_MACRO appears to be almost completely unused on CPAN: just two distros, MIME-Fast and Wx. Compared with 16(*) CPAN distros which use the INTERFACE: keyword. So perhaps breaking the former is acceptable? In any event, I currently have a WIP branch which has over 100 commits and which almost completely rewrites the XS parser, and which I planned to merge post-5.42.0 release. It would be (I imagine) a royal pain to fix INTERFACE in blead and *then* rebase my branch over that. On the other hand, it would be nice to get some sort of basic fix into the 5.42.0 release. Presumably over the next 2 years, gcc-15 is going to become mainstream, and then 5.42.0 will start breaking on XS modules with INTERFACE. Could the proposed '...' fix or similar to XSUB.h be used now as a stop-gap measure, then I'd fix INTERFACE properly post 5.42.0???

…

-- But Pity stayed his hand. "It's a pity I've run out of bullets", he thought. -- "Bored of the Rings"

Could the proposed '...' fix or similar to XSUB.h be used now as a
stop-gap measure, then I'd fix INTERFACE properly post 5.42.0???

That's not a good fix either, becaus vararg argument passing is not guaranteed to be the same as non-vararg argument passing. Most notably it isn't on Apple on ARM.

On the other hand, the INTERFACE_MACRO appears to be almost completely
unused on CPAN: just two distros, MIME-Fast and Wx

Just MIME::Fast, it's commented out (with #if 0) in Wx.

MIME::Fast looks to me like it needs to use PREFIX instead.

But also, it hasn't been updated in 20+ years (and gnome certainly hasn't been standing still in that period), and no passing entries are known on CPAN Testers. I think we can assume it's dead.

It's complicated by the fact that there is also the INTERFACE_MACRO:

Yeah I don't think it was possible to write a sensible INTERFACE_MACRO before vararg macros, but we can actually make something better now.

Though I'm still not quite sure when someone would ever need this feature.

On Mon, Apr 14, 2025 at 05:12:09AM -0700, Leon Timmermans wrote: Leont left a comment (Perl/perl5#23192) > Could the proposed '...' fix or similar to XSUB.h be used now as a stop-gap measure, then I'd fix INTERFACE properly post 5.42.0??? That's not a good fix either, becaus vararg argument passing is not guaranteed to be the same as non-vararg argument passing. Most notably it isn't on Apple on ARM.

Thinking some more: C_ARGS is going to be a problem. For example, with: foo(int a, char *b) INTERFACE: ...... C_ARGS: munge(b), a, FOO_SOME_FLAG C_ARGS is just an uninterpreted string which is used as-is to generate the call to the real C function. We have no idea what munge returns, or whether FOO_SOME_FLAG is a int or pointer or whatever. We can't even know the number of args: for example, munge() might be a macro which expands to "b, strlen(b)". So in general, the XS parser can't know the signature of the C function. Unless there is some new C feature I don't know about which provides that info? A sort of __FUNCTION_SIGNATURE__(some_function_name)?? We leads me to wonder: is there a viable fallback position for an INTERFACE XSUB which also contains C_ARGS? Such as a pragma which turns off arg checking? But if so, couldn't we just use that always? Just out of curiosity, does any C expert one know how detailed the function pointer declaration has to be? For example, could we just declare all args as 'void *' or something like that? (Note: my C knowledge is basically K&R, albeit updated with the newfangled ANSI way of declaring a function's parameters. I don't understand all this fancy C99 and later stuff.)

…

-- This email is confidential, and now that you have read it you are legally obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have received this email in error, place it in its original wrapping and return for a full refund. By opening this email, you accept that Elvis lives.

Thinking some more: C_ARGS is going to be a problem.

That is a good point. Yeah that will be hairy.

Unless there is some new C feature I don't know about which provides that
info? A sort of FUNCTION_SIGNATURE(some_function_name)??

C23 actually has a typeof operator, but we can't exactly require C23.

Just out of curiosity, does any C expert one know how detailed the
function pointer declaration has to be? For example, could we just declare
all args as 'void *' or something like that?

Absolutely not. In the original version of C all arguments were word sized so none of this mattered, but that has long stopped being the case.

Perhaps instead of doing this weird function-pointer-hidden-in-CV voodoo, we could generate a separate XSUB for each function listed in INTERFACE?

So basically, this:

int foo_interface(int a, int b)
INTERFACE:
fun1 fun2

would be equivalent to this:

int
fun1(int a, int b)

int
fun2(int a, int b)

(and remove INTERFACE_MACRO)

In any case, I'm assuming anything we do to fix this will have to done
post-5.42.0.

Yeah, that seems wiser than rushing a solution to a problem that's caused by a change outside of our power.

Speaking with my PSC hat on, we consider this a release blocker… for 5.44. This really needs solved but we don’t foresee the solution to be simple enough to still get into 5.42 at this late stage in the release cycle.

As a workaround, can this problem be overcome by adding -std=c17 to ccflags when gcc-15 is used ?

As a workaround, can this problem be overcome by adding -std=c17 to ccflags when gcc-15 is used ?

But should we do that, or should CommonMark do that?

But should we do that, or should CommonMark do that?

Or .... should the user attend to that ? I don't know.

I was wondering what advice we would offer to someone who wants to install CommonMark-0.310100 on a perl that has been built using gcc-15, and c23.

I've meddled around a bit and found that if ccflags already specifies something less than c23 (as is currently the usual case on Windows), then CommonMark builds fine.
Nothing remarkable about that.

And if, on my gcc-15 build (on Windows), I remove -std=c99 from ccflags, then I hit the issue as reported by the OP.
To then overcome that problem, rather than restore ccflags to its original state, I can simply rebuild CommonMark as a manual build, starting with:

perl Makefile.PL CC="gcc -std=c17"

Nothing remarkable about that, either. (I presume I could alternatively tweak CCFLAGS at that command line, but IIRC that gets a bit messy in the cmd.exe shell.)

Is that "manual" build the type of approach we would recommend for the time being ?

Should the current blead test suite expose this issue (FAIL or TODO ?) when it is present ?
FAIK, it might already do that. So far, all of my perl builds using gcc-15 have specified -std=c99 in ccflags, so I wouldn't be be experiencing such failures, anyway.

I presently have gcc-15 on Windows 11 only.

On Fri, Apr 25, 2025 at 10:11:08PM -0700, sisyphus wrote: I've meddled around a bit and found that if ccflags already specifies something less than c23 (as is currently the usual case on Windows), then CommonMark builds fine.

So if standard builds on Windows set -std= to something which doesn't trigger this problem, why is this a problem? (I'm not denying that it's potentially a problem, I'm just trying to understand the scope of the problem.)

…

-- "I used to be with it, but then they changed what ‘it’ was, and now what I’m with isn’t it. And what’s ‘it’ seems weird and scary to me." -- Grandpa Simpson (It will happen to you too.)

So if standard builds on Windows set -std= to something which doesn't trigger this problem, why is this a problem?

I don't think it's helpful in the long term to be hiding such issues under the C99 blanket.
What other issues might we be masking ?
I've pretty much decided that my own builds of perl-5.42 will be built without that "C99" wind-back - just like perl-5.38 and earlier.
I've spent most of today building and testing blead (using gcc-15.1.0) on Windows such that the C level remains at C23, and haven't yet found any additional issues at all.
But I feel that all of that would be more appropriately discussed in a separate issue/PR.

As for the "scope of the problem", it looks to me that if perl's underlying C level is at C23 && you want to call XSFUNCTION with one or more arguments, then you'll come up against this issue.
At least, that's about as far as I've got. (FAIRK, there could be caveats.)

XS: fix INTERFACE on strict C compilers

I now have a proposed fix in PR #23640. It basically extracts the types of the parameters and uses them in a cast before calling XSFUNCTION. In the presence of C_ARGS, if its just a simple list of reordered parameters names, it splits the C_ARGS string and looks up the types of each referenced parameter. For complex C_ARGS lines it gives up on any complex args and just uses 'void*' as the arg's type. I'm using the philosophy of "the perfect is the enemy of the good". There is some theoretical XS code this commit won't fix, but it is unlikely to actually be seen in the wild.

…

-- In England there is a special word which means the last sunshine of the summer. That word is "spring".

XS: fix INTERFACE on strict C compilers

For complex C_ARGS lines it
gives up on any complex args and just uses 'void*' as the arg's type.

I'm using the philosophy of "the perfect is the enemy of the good". There
is some theoretical XS code this commit won't fix, but it is unlikely to
actually be seen in the wild.

I have absolutely written complex C_ARGS, but void* might just be close enough that it will work because I think they all used pointer types.

XS: fix INTERFACE on strict C compilers

[MERGE] fix two XS INTERFACE keyword issues

Fixed by v5.43.2-85-gb81e58c28b

Navigation Menu

Repository navigation

The CommonMark module cannot be built using gcc 15 and perl 5.40.1 #23192

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The CommonMark module cannot be built using gcc 15 and perl 5.40.1 #23192

Description

Activity

mauke commented on Apr 13, 2025

jkeenan commented on Apr 13, 2025

xenu commented on Apr 13, 2025

iabyn commented on Apr 14, 2025

iabyn commented on Apr 14, 2025

Leont commented on Apr 14, 2025

xenu commented on Apr 14, 2025

Leont commented on Apr 14, 2025

Leont commented on Apr 14, 2025

iabyn commented on Apr 15, 2025

Leont commented on Apr 15, 2025

xenu commented on Apr 15, 2025

3 remaining items

Leont commented on Apr 20, 2025

ap commented on Apr 24, 2025

sisyphus commented on Apr 25, 2025

Leont commented on Apr 25, 2025

sisyphus commented on Apr 26, 2025

iabyn commented on Apr 27, 2025

sisyphus commented on Apr 28, 2025

iabyn commented on Aug 24, 2025

Leont commented on Aug 28, 2025

iabyn commented on Aug 30, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions