- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 20 2024
Dec 22 2023
Dec 21 2023
Rework test case
Dec 20 2023
Nov 30 2023
Nov 28 2023
Sep 26 2023
In D41983#957328, @arichardson wrote:You could push to a GitHub fork, then it will run the bootstrap steps as part of the GitHub action
In D41927#956266, @kib wrote:In D41927#956264, @yuripv wrote:In D41927#956261, @kib wrote:I do not know much about runes/locales either.
I'm not that worried about the fix itself, more about adding the public symbol to libc, and wanted to hear from you if this is acceptable.
If the symbol is needed, why not? The concern is that we must support it forever, with the same or compatible semantic. But then again, this is the question for the locale code maintenance.
In D41983#957267, @yuripv wrote:In D41983#957266, @arichardson wrote:This will almost certainly break the cross build. The typedefs in the local _ctype.h are needed. Can you modify that file to include the new generated header?
Yep, I am working on getting cross-build, but I don't see why it would break though, nothing in ctype.c uses those types and we are not including/using the is*() functions.
In D41983#957266, @arichardson wrote:This will almost certainly break the cross build. The typedefs in the local _ctype.h are needed. Can you modify that file to include the new generated header?
Sep 25 2023
Apparently NetBSD has a bit more complete fix for this (thanks Kyle), use it instead.
Sep 23 2023
In D41927#956261, @kib wrote:I do not know much about runes/locales either.
Sep 22 2023
- Versions.def updated in separate commit
- drop extern as suggested by Konstantin
complete change (except for linux cross build testing)
Sep 21 2023
As discussed with Mina on IRC, entries with correct email but missing accent in surname need to be normalized as well, i.e.
diff --git a/.mailmap b/.mailmap index 3760aeece44..1f27f22efdb 100644 --- a/.mailmap +++ b/.mailmap @@ -1,5 +1,6 @@ <ehem+freebsd@m5p.com> <ehem_freebsd_m5p.com> <ehem+freebsd@m5p.com> <ehem_freebsd@m5p.com> +Mina Galić <freebsd@igalic.co> <freebsd@igalic.co> Mina Galić <freebsd@igalic.co> <freebsd_igalic.co> Mina Galić <freebsd@igalic.co> <me_igalic.co> Mina Galić <freebsd@igalic.co> <me@igalic.co>
Sep 20 2023
Sep 18 2023
(re)generate nn_NO.ISO8859-15 from CLDR
In D41899#954906, @imp wrote:Though nynorsk and bokmal aren't quite the same, this does fix the circular issue. And the two are close enough.
Sep 5 2023
Sep 4 2023
Just wondering what triggered this change, i.e. does it fix any known issues?
Sep 2 2023
Aug 5 2023
In D41329#941150, @jrtc27 wrote:
In D41329#941144, @jrtc27 wrote:In D41329#941142, @yuripv wrote:In D41329#941115, @jrtc27 wrote:Ok, I think I understand what's going on here. Does https://termbin.com/895q resolve the issue instead for you? That's what we're actually trying to do here, I think.
The following part from your patch is enough to unbreak gcc and is exactly what the patch here does:
--- a/sys/sys/linker_set.h +++ b/sys/sys/linker_set.h @@ -66,8 +66,8 @@ #endif #define __MAKE_SET_QV(set, sym, qv) \ - __WEAK(__CONCAT(__start_set_,set)); \ - __WEAK(__CONCAT(__stop_set_,set)); \ + __GLOBL(__CONCAT(__start_set_,set)); \ + __GLOBL(__CONCAT(__stop_set_,set)); \ static void const * qv \ __NOASAN \ __set_##set##_sym_##sym __section("set_" #set) \I know, but it's bogus to mix things like this. There's a lot of detail in all this that you're glossing over by just doing that. You need the rest to make it less fragile in corner cases, and of course to make it work for both LLVM's assembler and binutil's.
In D41329#941115, @jrtc27 wrote:Ok, I think I understand what's going on here. Does https://termbin.com/895q resolve the issue instead for you? That's what we're actually trying to do here, I think.
In D41329#941115, @jrtc27 wrote:Ok, I think I understand what's going on here. Does https://termbin.com/895q resolve the issue instead for you? That's what we're actually trying to do here, I think.
Aug 4 2023
Committed in rGb306c604df541dede4d0f3cc96188bbf5b6719fe.
Hmm, this doesn't seem to be automatically closed on commit.
Jul 26 2023
Jul 22 2023
Jul 19 2023
Jul 18 2023
Jul 17 2023
In D41056#934733, @mav wrote:I like removal of IN_FREEBSD_BASE. I would be happy if autotrim was enabled by default, but if it wasn't for some time, then I see no problem to clean this up. I just wonder how long it was broken. Respective part of the patch will need to be upstreamed to OpenZFS also, may be in parallel to make sure more people are in sync about it.
Jun 29 2023
Sadly, I had to revert this, with all these defines being ambiguously named I missed the fact that IN_BASE is only used in FreeBSD-specific code to signify userland/kernel differences, while IN_FREEBSD_BASE really means FreeBSD-specific code inside the common code. Will need to think more about proper approach (and naming?) here.
Jun 28 2023
Jun 19 2023
May 30 2023
May 23 2023
May 13 2023
modify spa.h instead as proposed by Warner
May 12 2023
re: stand, I don't see a call to zpool_prop_init() in there anywhere, zpool_prop.c does not seem to be compiled as well; am I missing something obvious?
I *guess* it was done this way as it's the only FreeBSD-specific part in the "common" code, and everything using IN_BASE is located under sys/contrib/openzfs/lib/libzfs/os/freebsd and sys/contrib/openzfs/include/os/freebsd proper.