In D17950#389310, @bapt wrote:as this been upstreamed? (https://github.com/lichray/nvi2)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Nov 26 2018
Nov 26 2018
Nov 23 2018
Nov 23 2018
regexec: fix processing multibyte strings.
yuripv updated the diff for D18302: regcomp() recurses infinitely on a case-insensitive pattern containing wide characters in 128-255 range.
drop unrelated changes
yuripv updated the diff for D18302: regcomp() recurses infinitely on a case-insensitive pattern containing wide characters in 128-255 range.
After providing the quick fix, I have started wondering how GNU grep (or libgnuregex, more precisely) does the matching without providing any locale specific data; the answer is pretty simple, not sure why I didn't think about it from the start -- fold the case of *both* sides of comparison, and compare both-upper and/or both-lower.
Please submit diffs with full context.
yuripv retitled D18302: regcomp() recurses infinitely on a case-insensitive pattern containing wide characters in 128-255 range from regcomp() recuses infinitely on a case-insensitive pattern with unidirectional case-mappings to regcomp() recurses infinitely on a case-insensitive pattern with unidirectional case-mappings.
Nov 22 2018
Nov 22 2018
typos.
In D18297#388056, @pfg wrote:I am not an expert on the area but I see where the comment comes from:
RFC3629 states on page 2:
The byte-value lexicographic sorting order of UTF-8 strings is the
same as if ordered by character numbers. Of course this is of
limited interest since a sort order based on character numbers is
almost never culturally valid.The Boyer-Moore fast search algorithm can be used with UTF-8 data.
redo.
There's a reply and action upstream, the patch integrated there is more complete (removing all "bits" stuff from mansearch), will use that one.
Nov 21 2018
Nov 21 2018
Nov 17 2018
Nov 17 2018
Make mbstowcs_basic test pass, now that we have more ctype definitions.
Nov 15 2018
Nov 15 2018
Nov 14 2018
Nov 14 2018
Baptiste, anything else you want to see done/answered for this to proceed?
Fix WITHOUT_ICONV build after r340276.
Nov 13 2018
Nov 13 2018
In D17449#375265, @yuripv wrote:In D17449#375264, @bapt wrote:First we should ship the said manpage :)
I think this is debattable, but I think upstream is opened enought to accept such change, you should anyway talk to them to see if that will remain a freebsd only patch or not :)
OK, will do.
Nov 11 2018
Nov 11 2018
yuripv committed rS340354: Use blank am_pm and t_fmt_ampm for de_AT and de_DE locales as apparently.
Use blank am_pm and t_fmt_ampm for de_AT and de_DE locales as apparently
Nov 9 2018
Nov 9 2018
In D17842#382775, @bapt wrote:That look sane to me, the thing is I wonder how hard it would be to maintain
Reset persistent mbstates when rune locale encoding changes.
Nov 8 2018
Nov 8 2018
I think this makes perfect sense. You might want to update editline(3) as well so it doesn't say it only knows about UTF-8 and C locales.
Nov 7 2018
Nov 7 2018
cleanup done separately; rebase
Nov 6 2018
Nov 6 2018
Nov 5 2018
Nov 5 2018
Nov 4 2018
Nov 4 2018
Add hybrid C.UTF-8 locale being identical to default C locale except
Just for the note: perl bits here are only the helper tools for someone updating the locale sources in share/, and aren't run during the build, so even if something is broken there (and I tried not to as I used them), it's only bad until there's a need to update the data again where they will be fixed anyway :)
Teach man(1) about C.UTF-8.
Nov 3 2018
Nov 3 2018
strptime: make %k and %l specifiers match their description in
Update to CLDR 34 and UNICODE 11.
Bump my limit for CLDR update.
Nov 1 2018
Nov 1 2018
yuripv updated the summary of D17796: locale: persistent mbstates should be reset when rune locale changes.
Oct 31 2018
Oct 31 2018
dtrace(1): remove reference to dtruss that was removed from base
Do I need explicit approval from @gnn here?
usr.bin/sed/tests: fix one of the regression test cases by adding its
Oct 30 2018
Oct 30 2018
Connect libc/tests/time to the build, adding test cases for strptime()
Oct 28 2018
Oct 28 2018
Oct 27 2018
Oct 27 2018
yuripv added inline comments to D17719: Improve ipfw.8 manual page with more clear layer2 processing documentation.
localedef: define characters in "space" class also as "print", except
yuripv committed rS339826: Provide basic descriptions for VMX exit reason (from "Intel 64 and IA-32.
Provide basic descriptions for VMX exit reason (from "Intel 64 and IA-32
In D17531#378698, @araujo wrote:Hi @yuripv , is there anything pending for this patch to be committed?
Oct 22 2018
Oct 22 2018
I have updated the suite to pass everything that is enabled, still having tz tests disabled as there's no easy way to make them pass and our parsing code is rudimentary compared to netbsd's one.
Can I proceed with kib being the reviewer for this, or bhyve group will take a look?
Oct 21 2018
Oct 21 2018
pw: fix the checks in boolean_str() after r326738. Add related test
yuripv updated the diff for D17467: PR225692: localedef: mark "space" also as "print" excluding known conflicts.
rebase on top of recent localedef changes; make the change less intrusive keeping the warning and only stripping "print" from "space|control" combination.
rebase after the fix for PR231653 landed separately
With this change alone (and that's what it actually looked for mips) collation is broken. The changes *and* the amount of conversion we need to do every time we load the collation tables make this way not worth it IMO.
Oct 20 2018
Oct 20 2018
Add -b/-l options to localedef(1) to specify output endianness and use
Oct 19 2018
Oct 19 2018
In D17618#376157, @sbruno wrote:In D17618#376145, @yuripv wrote:Sean, could you please give this a try on ref12-ppc64?
You would like me to revert D17603 and apply this singular diff?
Sean, could you please give this a try on ref12-ppc64?
yuripv added a comment to D17603: PR231965: make localedef output locale data in target endian order.
In D17603#376086, @emaste wrote:
yuripv updated the diff for D17603: PR231965: make localedef output locale data in target endian order.
issue fixed (wchar_t, that is (unsigned) int, is *4* bytes).
Oct 18 2018
Oct 18 2018
yuripv added a comment to D17603: PR231965: make localedef output locale data in target endian order.
In D17603#376016, @yuripv wrote:In D17603#376009, @sbruno wrote:In D17603#375981, @yuripv wrote:In D17603#375980, @sbruno wrote:In D17603#375978, @yuripv wrote:In D17603#375975, @sbruno wrote:I'll apply this to the fbsd cluster build.
The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?
I'd really like to compare results from native EB (e.g. powerpc64) build for /usr/share/locale with what amd64 cross-build produces.
Ok. I'll update ref12-ppc64 to this review (product of cross build) and then you can natively do a buildworld there to see what it looks like?
Thank you!
Ok, I've only updated the ref12-ppc64 jail and I zfs snapshotted it as well in case we want to to rollback. Take a look around and see if it seems "fine"
Yes, it seems to be fine (tmux works now, as well as basic collation test program).
yuripv added a comment to D17603: PR231965: make localedef output locale data in target endian order.
In D17603#376009, @sbruno wrote:In D17603#375981, @yuripv wrote:In D17603#375980, @sbruno wrote:In D17603#375978, @yuripv wrote:In D17603#375975, @sbruno wrote:I'll apply this to the fbsd cluster build.
The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?
I'd really like to compare results from native EB (e.g. powerpc64) build for /usr/share/locale with what amd64 cross-build produces.
Ok. I'll update ref12-ppc64 to this review (product of cross build) and then you can natively do a buildworld there to see what it looks like?
Thank you!
Ok, I've only updated the ref12-ppc64 jail and I zfs snapshotted it as well in case we want to to rollback. Take a look around and see if it seems "fine"
yuripv added a comment to D17603: PR231965: make localedef output locale data in target endian order.
In D17603#375980, @sbruno wrote:In D17603#375978, @yuripv wrote:In D17603#375975, @sbruno wrote:I'll apply this to the fbsd cluster build.
The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?
I'd really like to compare results from native EB (e.g. powerpc64) build for /usr/share/locale with what amd64 cross-build produces.
Ok. I'll update ref12-ppc64 to this review (product of cross build) and then you can natively do a buildworld there to see what it looks like?
yuripv added a comment to D17603: PR231965: make localedef output locale data in target endian order.
In D17603#375975, @sbruno wrote:I'll apply this to the fbsd cluster build.
The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?