Re: problem with ls, not show a correct list

2017-04-09 Thread Andrey Chernov
On 09.04.2017 19:31, Nilton José Rizzo wrote: >try this > > ls [a-b,k-m] > >in sh using the locale setting to pt_BR.UTF-8 > > it's not work For the set below I got on -current a A b k K l m with any non-C locale which is right. > # ls >

Re: problem with ls, not show a correct list

2017-04-08 Thread Andrey Chernov
On 07.04.2017 23:20, Nilton José Rizzo wrote: > Em 2017-04-07 05:51, Toomas Soome escreveu: >>> On 7. apr 2017, at 11:29, Andrey Chernov <a...@freebsd.org> wrote: >>> >>>> Hi Allan, the ls show all files without case match >>>> >>>>

Re: problem with ls, not show a correct list

2017-04-07 Thread Andrey Chernov
On 07.04.2017 11:51, Toomas Soome wrote: > >> On 7. apr 2017, at 11:29, Andrey Chernov <a...@freebsd.org> wrote: >> >>> Hi Allan, the ls show all files without case match >>> >>> ls [a-z]* >>> >>> show all files beginning w

Re: problem with ls, not show a correct list

2017-04-07 Thread Andrey Chernov
> Hi Allan, the ls show all files without case match > > ls [a-z]* > > show all files beginning with a and A like this [aA-zZ]* No, last "Z" is not included. ___ freebsd-current@freebsd.org mailing list

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

2017-03-30 Thread Andrey Chernov
On 30.03.2017 21:53, Bruce Evans wrote: > I think it was the sizing. The non-updated mode is 80x25, so the row > address can be out of bounds in the teken layer. I have text 80x30 mode set at rc stage, and _after_ that may have many kernel messages on console, all without causing reboot. How it

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

2017-03-30 Thread Andrey Chernov
On 30.03.2017 18:13, Bruce Evans wrote: > On Thu, 30 Mar 2017, Andrey Chernov wrote: > >> On 30.03.2017 12:34, Andrey Chernov wrote: >>> On 30.03.2017 12:23, Andrey Chernov wrote: >>>> Yes, only for reboot/shutdown. The system does not do anythings wrong >

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

2017-03-30 Thread Andrey Chernov
On 30.03.2017 12:34, Andrey Chernov wrote: > On 30.03.2017 12:23, Andrey Chernov wrote: >> Yes, only for reboot/shutdown. The system does not do anythings wrong >> even under high load. On reboot or hang those lines are never printed: >> >> kernel: Waiting (max 60

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

2017-03-30 Thread Andrey Chernov
On 30.03.2017 14:23, Andriy Gapon wrote: > On 30/03/2017 12:34, Andrey Chernov wrote: >> On 30.03.2017 12:23, Andrey Chernov wrote: >>> Yes, only for reboot/shutdown. The system does not do anythings wrong >>> even under high load. On reboot or hang those lines are ne

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

2017-03-30 Thread Andrey Chernov
On 30.03.2017 12:23, Andrey Chernov wrote: > Yes, only for reboot/shutdown. The system does not do anythings wrong > even under high load. On reboot or hang those lines are never printed: > > kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done > kernel:

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

2017-03-30 Thread Andrey Chernov
> We don't understand the bug yet. It might not even be in sc. Do you only > see problems for shutdown? The shutdown environment is special for > locking. Yes, only for reboot/shutdown. The system does not do anythings wrong even under high load. On reboot or hang those lines are never

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

2017-03-30 Thread Andrey Chernov
On 30.03.2017 9:51, Andrey Chernov wrote: > On 30.03.2017 8:53, Bruce Evans wrote: >>> Maybe two will be enough too, I don't check. I just don't need _any_ of >>> vt lines. What is matter it is that syscons only mode (without any vt) >>> was recently broken, caus

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

2017-03-30 Thread Andrey Chernov
On 30.03.2017 8:53, Bruce Evans wrote: >> Maybe two will be enough too, I don't check. I just don't need _any_ of >> vt lines. What is matter it is that syscons only mode (without any vt) >> was recently broken, causing shutdown problems and file system damage >> each time. Syscons only mode works

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

2017-03-29 Thread Andrey Chernov
On 29.03.2017 6:29, Bruce Evans wrote: > Using rc_debug=yes I see that it is the kernel problem, not rc > problem. > Sometimes rc backward sequence executed even fully, sometimes only > partly, but in unpredictable moment inside rc sequence the kernel > decide > to reboot

New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

2017-03-28 Thread Andrey Chernov
On 29.03.2017 0:46, Ngie Cooper (yaneurabeya) wrote: > >> On Mar 28, 2017, at 14:27, Andrey Chernov <a...@freebsd.org> wrote: > > … > >>> Using rc_debug=yes I see that it is the kernel problem, not rc problem. >>> Sometimes rc backward sequence exec

Re: shutdown -r doesn't execute rc.d sequence

2017-03-28 Thread Andrey Chernov
On 29.03.2017 0:15, Andrey Chernov wrote: > On 28.03.2017 22:33, Ngie Cooper (yaneurabeya) wrote: >> >>> On Mar 28, 2017, at 12:30, Andrey Chernov <a...@freebsd.org> wrote: >>> >>> With latest -current amd64, reboot happens almost immediately, leaving >

Re: shutdown -r doesn't execute rc.d sequence

2017-03-28 Thread Andrey Chernov
On 28.03.2017 22:33, Ngie Cooper (yaneurabeya) wrote: > >> On Mar 28, 2017, at 12:30, Andrey Chernov <a...@freebsd.org> wrote: >> >> With latest -current amd64, reboot happens almost immediately, leaving >> FS dirty. No proper backward rc.d or /usr/local/etc/rc

Re: shutdown -r doesn't execute rc.d sequence

2017-03-28 Thread Andrey Chernov
On 28.03.2017 22:33, Ngie Cooper (yaneurabeya) wrote: > >> On Mar 28, 2017, at 12:30, Andrey Chernov <a...@freebsd.org> wrote: >> >> With latest -current amd64, reboot happens almost immediately, leaving >> FS dirty. No proper backward rc.d or /usr/local/etc/rc

shutdown -r doesn't execute rc.d sequence

2017-03-28 Thread Andrey Chernov
With latest -current amd64, reboot happens almost immediately, leaving FS dirty. No proper backward rc.d or /usr/local/etc/rc.d sequence execution is shown. No deactivating GELI swap too. ___ freebsd-current@freebsd.org mailing list

Can't build -current incrementally due to libnv changes

2016-08-27 Thread Andrey Chernov
Yes, 'make includes' (and 'make obj' and 'make depend') is done before 'make all' in /usr/src/lib ===> libnv (all) cc -O2 -pipe -march=sandybridge -I/usr/src/lib/libnv/../../sys -I/usr/src/lib/libnv -MD -MF.depend.cnvlist.o -MTcnvlist.o -std=gnu99 -fstack-protector-strong -Wsystem-headers

Re: date(1) default format changed between 10.3 and 11.0-BETA3

2016-08-05 Thread Andrey Chernov
On 05.08.2016 18:44, Mark Martinec wrote: > On 2016-08-05 17:23, Andrey Chernov wrote: >> On 05.08.2016 17:47, Mark Martinec wrote: >>> [Bug 211598] >>> date(1) default format in en_EN locale breaks compatibility with 10.3 >>> and violates POSIX >&

Re: date(1) default format changed between 10.3 and 11.0-BETA3

2016-08-05 Thread Andrey Chernov
On 05.08.2016 17:47, Mark Martinec wrote: > [Bug 211598] > date(1) default format in en_EN locale breaks compatibility with 10.3 > and violates POSIX > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211598 It breaks compatibility but not violates POSIX. POSIX care of only its own POSIX

Re: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc has odd mix of signed wchar_t and unsigned char]

2016-07-13 Thread Andrey Chernov
say so only. They are different entities differently encoded and cross assigning between wchar_t and char is not recommended. > > On 2016-Jul-11, at 8:57 PM, Andrey Chernov wrote: > >> On 12.07.2016 5:44, Mark Millard wrote: >>> My understanding of the criteria f

Re: GOST in OPENSSL_BASE

2016-07-12 Thread Andrey Chernov
On 12.07.2016 12:59, Daniel Kalchev wrote: > The standard HTTPS implementation is already sufficiently broken, with the > door wide open by the concept of “multiple CAs”. The protocol design is > flawed, as any CA can issue certificate for any site. Applications are > required to trust that

Re: GOST in OPENSSL_BASE

2016-07-12 Thread Andrey Chernov
On 12.07.2016 12:16, Andrey Chernov wrote: > On 12.07.2016 8:48, Kevin Oberman wrote: >> >> May be need file PR for dns/bind910? >> >> >> >> # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile &g

Re: GOST in OPENSSL_BASE

2016-07-12 Thread Andrey Chernov
On 12.07.2016 8:48, Kevin Oberman wrote: > >> May be need file PR for dns/bind910? > >> > >> # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile > >> .include http://bsd.port.pre.mk>> > >> > >> .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) && >

Re: svn commit: r302601 - in head/sys: arm/include arm64/include [__WCHAR_MAX definition mostly]

2016-07-11 Thread Andrey Chernov
On 12.07.2016 5:44, Mark Millard wrote: > My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: > > A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion of > ___wchar_t (if that is distinct). > B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; not >

Re: GOST in OPENSSL_BASE

2016-07-11 Thread Andrey Chernov
On 12.07.2016 1:44, Andrey Chernov wrote: > On 11.07.2016 21:41, Slawa Olhovchenkov wrote: >> On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote: >> >>> On 07/10/16 10:10 AM, Andrey Chernov wrote: >>>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:

Re: GOST in OPENSSL_BASE

2016-07-11 Thread Andrey Chernov
On 11.07.2016 21:41, Slawa Olhovchenkov wrote: > On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote: > >> On 07/10/16 10:10 AM, Andrey Chernov wrote: >>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote: >>>> I am surprised lack of support GOST in opens

Re: GOST in OPENSSL_BASE

2016-07-11 Thread Andrey Chernov
On 11.07.2016 23:13, Slawa Olhovchenkov wrote: > On Mon, Jul 11, 2016 at 07:48:44PM +0300, Andrey Chernov wrote: > >> On 11.07.2016 19:29, Slawa Olhovchenkov wrote: >>> On Mon, Jul 11, 2016 at 11:04:33AM -0500, Mark Felder wrote: >>> >>>> >&

Re: GOST in OPENSSL_BASE

2016-07-11 Thread Andrey Chernov
On 11.07.2016 19:29, Slawa Olhovchenkov wrote: > On Mon, Jul 11, 2016 at 11:04:33AM -0500, Mark Felder wrote: > >> >> >> On Mon, Jul 11, 2016, at 05:29, Slawa Olhovchenkov wrote: >>> >>> I.e. GOST will be available in openssl. >>> Under BSD-like license. >>> Can be this engine import in base

Re: GOST in OPENSSL_BASE

2016-07-10 Thread Andrey Chernov
On 10.07.2016 18:28, Andrey Chernov wrote: > On 10.07.2016 18:13, Andrey Chernov wrote: >> On 10.07.2016 18:12, Andrey Chernov wrote: >>> On 10.07.2016 18:01, Slawa Olhovchenkov wrote: >>>> On Sun, Jul 10, 2016 at 05:10:04PM +0300, Andrey Chernov wrote: >>

Re: GOST in OPENSSL_BASE

2016-07-10 Thread Andrey Chernov
On 10.07.2016 18:13, Andrey Chernov wrote: > On 10.07.2016 18:12, Andrey Chernov wrote: >> On 10.07.2016 18:01, Slawa Olhovchenkov wrote: >>> On Sun, Jul 10, 2016 at 05:10:04PM +0300, Andrey Chernov wrote: >>> >>>> On 10.07.2016 16:30, Slawa Olhovchenkov wrot

Re: GOST in OPENSSL_BASE

2016-07-10 Thread Andrey Chernov
On 10.07.2016 18:12, Andrey Chernov wrote: > On 10.07.2016 18:01, Slawa Olhovchenkov wrote: >> On Sun, Jul 10, 2016 at 05:10:04PM +0300, Andrey Chernov wrote: >> >>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote: >>>> I am surprised lack of support GOST in op

Re: GOST in OPENSSL_BASE

2016-07-10 Thread Andrey Chernov
On 10.07.2016 18:01, Slawa Olhovchenkov wrote: > On Sun, Jul 10, 2016 at 05:10:04PM +0300, Andrey Chernov wrote: > >> On 10.07.2016 16:30, Slawa Olhovchenkov wrote: >>> I am surprised lack of support GOST in openssl-base. >>> Can be this enabled before 11.0

Re: GOST in OPENSSL_BASE

2016-07-10 Thread Andrey Chernov
On 10.07.2016 16:30, Slawa Olhovchenkov wrote: > I am surprised lack of support GOST in openssl-base. > Can be this enabled before 11.0 released? AFAIK openssl maintainers says something like they can't support this code and it will become rotten shortly with new changes, so they drop it.

Re: Recent -current stable panic at later boot stage

2016-07-09 Thread Andrey Chernov
On 10.07.2016 4:30, Matthew Macy wrote: > > > > On Sat, 09 Jul 2016 18:19:57 -0700 Andrey Chernov <a...@freebsd.org> > wrote > > BTW, it never happens with 11-ALPHA3 even with world build for 12. > > > > On 09.07.2016 22:06, Andrey C

Re: Recent -current stable panic at later boot stage

2016-07-09 Thread Andrey Chernov
BTW, it never happens with 11-ALPHA3 even with world build for 12. On 09.07.2016 22:06, Andrey Chernov wrote: > SCHED_ULE used. I have textdump only. Interesting parts: > <118>Starting syslogd. > kernel trap 9 with interrupts disabled > > Fatal trap 9: general protection

Recent -current stable panic at later boot stage

2016-07-09 Thread Andrey Chernov
SCHED_ULE used. I have textdump only. Interesting parts: <118>Starting syslogd. kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 7; apic id = 07 instruction pointer = 0x20:0x806b2585 stack pointer =

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

2016-07-07 Thread Andrey Chernov
On 07.07.2016 10:14, Don Lewis wrote: > On 6 Jul, Matthew Macy wrote: >> >> >> >> On Wed, 06 Jul 2016 23:48:53 -0700 Andrey Chernov >> <a...@freebsd.org> wrote >> > On 07.07.2016 9:40, Matthew Macy wrote: >> > > >>

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

2016-07-07 Thread Andrey Chernov
On 07.07.2016 9:40, Matthew Macy wrote: > > > > On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov <a...@freebsd.org> > wrote > > On 07.07.2016 7:52, K. Macy wrote: > > > On Wednesday, July 6, 2016, Don Lewis <truck...@freebsd.org> wrote:

Re: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

2016-07-07 Thread Andrey Chernov
On 07.07.2016 7:52, K. Macy wrote: > On Wednesday, July 6, 2016, Don Lewis wrote: > >> On 6 Jul, Matthew Macy wrote: >>> As a first step towards managing linux user space in a chrooted >>> /compat/linux, initially for i915 testing with intel gpu tools, later >>> on to get

Re: 'make depend' or 'make' bug on recent --current

2016-06-02 Thread Andrey Chernov
On 01.06.2016 23:04, Bryan Drewery wrote: > No. The build and how dependencies are generated and handled is still > fundamentally the same. Open the .depend.* files and see. It is only > simple dependencies for the target built. There's nothing new about its > content. If foo.c includes

Re: 'make depend' or 'make' bug on recent --current

2016-06-01 Thread Andrey Chernov
On 01.06.2016 22:36, Bryan Drewery wrote: >>> The graph in the original commit for WITH_FAST_DEPEND disagrees. >>> https://svnweb.freebsd.org/base?view=revision=290433 >>> >>> We run the preprocessor once now, not twice. >> >> It sounds good, just implemented bad. You measure some spherical

Re: 'make depend' or 'make' bug on recent --current

2016-06-01 Thread Andrey Chernov
On 01.06.2016 21:18, Bryan Drewery wrote: > On 6/1/2016 6:11 AM, Andrey Chernov wrote: >> Steps to reproduce: >> >> cd /usr/src/lib/libc/stdlib >> touch *div*.c >> cd .. >> make depend >> make >> >> And see how imaxdiv.o only is recompile

'make depend' or 'make' bug on recent --current

2016-06-01 Thread Andrey Chernov
Steps to reproduce: cd /usr/src/lib/libc/stdlib touch *div*.c cd .. make depend make And see how imaxdiv.o only is recompiled. No div.o ldiv.o lldiv.o are recompiled. P.S. new make depend is simple disgusting. It tends to recompile everything in the system if some minor header file is touched,

Re: Recent -current cpucontrol panic: [cpuctl, 129]: cannot bind to target cpu 1

2016-05-22 Thread Andrey Chernov
On 22.05.2016 12:32, Konstantin Belousov wrote: > On Sun, May 22, 2016 at 12:19:32PM +0300, Andrey Chernov wrote: >> On 22.05.2016 10:14, Konstantin Belousov wrote: >>> On Sun, May 22, 2016 at 09:47:08AM +0300, Andrey Chernov wrote: >>>> With microcode_update_enable=

Re: Recent -current cpucontrol panic: [cpuctl, 129]: cannot bind to target cpu 1

2016-05-22 Thread Andrey Chernov
On 22.05.2016 10:14, Konstantin Belousov wrote: > On Sun, May 22, 2016 at 09:47:08AM +0300, Andrey Chernov wrote: >> With microcode_update_enable="YES" in rc.conf: >> >> db:0:kdb.enter.panic> show pcpu >> cpuid= 1 >> dynamic pcpu = 0xfe0

Recent -current cpucontrol panic: [cpuctl, 129]: cannot bind to target cpu 1

2016-05-22 Thread Andrey Chernov
With microcode_update_enable="YES" in rc.conf: db:0:kdb.enter.panic> show pcpu cpuid= 1 dynamic pcpu = 0xfe02ac1fd300 curthread= 0xf8000ae75a00: pid 736 "cpucontrol" curpcb = 0xfe023754eb80 fpcurthread = none idlethread = 0xf800022b5000: tid 13 "idle:

Re: Dropping some locales/encodings?

2016-03-01 Thread Andrey Chernov
On 01.03.2016 12:54, Baptiste Daroussin wrote: >> What benefit does it bring to remove an already existing locale? > > The benefit is the fact we have no source for those and collation for one are > wrong for those. (We have added proper collation support in head). Unicode mapping for CP1251

Re: Dropping some locales/encodings?

2016-02-29 Thread Andrey Chernov
On 01.03.2016 2:23, Baptiste Daroussin wrote: > Hi all, > > I have updated few month ago the locales to cldr v27.0.1. I would like to > simplify the generation of those locales from cldr to POSIX locales that we do > provides. > > I can properly generate almost any of the said locales/encodings

Re: /bin/ls formatting broken for non-C(?) locales

2015-11-25 Thread Andrey Chernov
On 25.11.2015 18:12, Andrey Chernov wrote: > On 25.11.2015 17:35, Baptiste Daroussin wrote: >>> BTW, array size looks suspicious: >>> static wchar_t wab_months[12][MAX_ABMON_WIDTH * 2 * MB_LEN_MAX]; >>> what MB_LEN_MAX doing here? This constant is for multiple-bytes e

Re: /bin/ls formatting broken for non-C(?) locales

2015-11-25 Thread Andrey Chernov
On 25.11.2015 17:35, Baptiste Daroussin wrote: >> BTW, array size looks suspicious: >> static wchar_t wab_months[12][MAX_ABMON_WIDTH * 2 * MB_LEN_MAX]; >> what MB_LEN_MAX doing here? This constant is for multiple-bytes encoded, >> not for wide chars. > Bad copy/paste sorry it should be

Re: /bin/ls formatting broken for non-C(?) locales

2015-11-25 Thread Andrey Chernov
On 25.11.2015 16:51, Baptiste Daroussin wrote: > wcslcat works like strlcat: > to quote the manpage: > "It will append at most dstsize - strlen(dst) - 1 characters." > So here with your version it will be n - wcslen(wab_months[i]) -1 > which won't fit what we want to do. > > btw that makes me

Re: /bin/ls formatting broken for non-C(?) locales

2015-11-25 Thread Andrey Chernov
On 25.11.2015 15:53, Baptiste Daroussin wrote: > What I did for now is set max_month_width to -1 and in ls_strftime I fallback > on > the plain strftime meaning you keep localized information but the alignement > is > broken as of now. It will be enough. >> 3) wcwidth/wcswidth may return -1

Re: /bin/ls formatting broken for non-C(?) locales

2015-11-24 Thread Andrey Chernov
On 25.11.2015 3:15, Baptiste Daroussin wrote: > On Sat, Nov 21, 2015 at 11:57:46PM +0300, Andrey Chernov wrote: >> On 21.11.2015 15:18, Ed Schouten wrote: >>> Hi Baptiste, >>> >>> I suppose you should use the wcswidth() function somewhere to compute >>&

Re: /bin/ls formatting broken for non-C(?) locales

2015-11-24 Thread Andrey Chernov
On 25.11.2015 4:31, Andrey Chernov wrote: > 4) The whole processing looks overcomplicated and not effective. What > about this instead? > for (i = 0; i < 12; i++) { > count wcswidth() of each month and store it in wab_months_width[]. > count max_width_month. > } &g

Re: /bin/ls formatting broken for non-C(?) locales

2015-11-21 Thread Andrey Chernov
On 21.11.2015 15:18, Ed Schouten wrote: > Hi Baptiste, > > I suppose you should use the wcswidth() function somewhere to compute > the visible width of the month name. Some characters may be > double-width, others may have no effective width at all. > I agree. Checking error return of wide

Re: /bin/ls formatting broken for non-C(?) locales

2015-11-20 Thread Andrey Chernov
On 21.11.2015 3:35, Baptiste Daroussin wrote: > Here is what I do propose (sorry for the ugly pad_to_col name, if one has > better > please share :D > > https://reviews.freebsd.org/D4239 The whole function is ugly, not only its name. Please no hardcoded constants assuming some internal

Re: Need help fixing failing locale tests

2015-11-15 Thread Andrey Chernov
On 15.11.2015 16:14, John Marino wrote: >> It is user confusion and his responsibility. It not leads to wrong >> program build f.e. Moreover, you can't protect users who set 8859-1 that >> way, they do not convert to 8859-15 as you assume but start to complain >> everywhere that FreeBSD is not

Re: Need help fixing failing locale tests

2015-11-15 Thread Andrey Chernov
On 15.11.2015 16:54, John Marino wrote: > We are talking about people that install FreeBSD 11 as a release. If > it's an upgrade, it's documented in UPDATING (it will be) and anybody on > -CURRENT is taking responsibility for knowing what they are doing. *IF* > this is an obstacle, it's either

Re: Need help fixing failing locale tests

2015-11-15 Thread Andrey Chernov
On 15.11.2015 18:38, Andrey Chernov wrote: >> For the traditional checks, It's ironic, DragonFly uses short locales >> like "fr_FR" which link to the approprioprate ISO8859 or UTF-8 locale. >> Bapt removed them to avoid a bike shed and if he had not done that, thi

Re: Need help fixing failing locale tests

2015-11-15 Thread Andrey Chernov
On 15.11.2015 17:47, John Marino wrote: >>> Please provide an example of such a program (in ports). >> >> See gettext-0.19.6/gettext-tools/configure, part started with >> # Test for the usual locale name. >> I don't have time to dig more such code now, but I remember I saw more >> for sure. > If

Re: Need help fixing failing locale tests

2015-11-15 Thread Andrey Chernov
On 15.11.2015 18:01, Baptiste Daroussin wrote: > I have restored the 8859-1 Thanx! BTW, speaking with John I find at least one configure script from ports which depends on 8859-1 presence. See gettext-0.19.6/gettext-tools/configure, part started with # Test for the usual locale name. --

Re: Need help fixing failing locale tests

2015-11-15 Thread Andrey Chernov
On 15.11.2015 18:17, John Marino wrote: See gettext-0.19.6/gettext-tools/configure, part started with # Test for the usual locale name. I don't have time to dig more such code now, but I remember I saw more for sure. > Of course it's the same topic. > If the configure of a

Re: Need help fixing failing locale tests

2015-11-15 Thread Andrey Chernov
On 15.11.2015 15:24, Andrey Chernov wrote: > On 15.11.2015 10:09, John Marino wrote: >> We (DragonFly) didn't just update locales. We took the opportunity to >> do spring cleaning. We didn't want to be as drastic as OpenBSD which >> removed all encodings except for C/POSI

Re: Need help fixing failing locale tests

2015-11-15 Thread Andrey Chernov
On 15.11.2015 15:46, Baptiste Daroussin wrote: > On Sun, Nov 15, 2015 at 03:24:19PM +0300, Andrey Chernov wrote: >> On 15.11.2015 10:09, John Marino wrote: >> ISO8859-1 locales are legacy even if obsoleted in modern world (I agree >> with that). Lots of ports (even at configur

Re: Need help fixing failing locale tests

2015-11-15 Thread Andrey Chernov
On 15.11.2015 16:00, Baptiste Daroussin wrote: > On Sun, Nov 15, 2015 at 03:56:26PM +0300, Andrey Chernov wrote: >> On 15.11.2015 15:46, Baptiste Daroussin wrote: >>> On Sun, Nov 15, 2015 at 03:24:19PM +0300, Andrey Chernov wrote: >>>> On 15.11.2015 10:09, John Marino

Re: Need help fixing failing locale tests

2015-11-15 Thread Andrey Chernov
On 15.11.2015 10:09, John Marino wrote: > We (DragonFly) didn't just update locales. We took the opportunity to > do spring cleaning. We didn't want to be as drastic as OpenBSD which > removed all encodings except for C/POSIX and UTF, but we did remove > several locales intentionally. > > In

Re: Need help fixing failing locale tests

2015-11-15 Thread Andrey Chernov
> Well, there is "harm". The -1/-15 confusion happens a lot. It is user confusion and his responsibility. It not leads to wrong program build f.e. Moreover, you can't protect users who set 8859-1 that way, they do not convert to 8859-15 as you assume but start to complain everywhere that FreeBSD

Re: make installworld failing with locales due to broken symlinks

2015-11-15 Thread Andrey Chernov
On 16.11.2015 4:57, NGie Cooper wrote: > make: stopped in /usr/src/git > $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE > lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 > /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -> ../la_LN.ISO8859-1/LC_CTYPE > $ readlink -f

Re: make installworld failing with locales due to broken symlinks

2015-11-15 Thread Andrey Chernov
On 16.11.2015 5:37, Andrey Chernov wrote: > On 16.11.2015 4:57, NGie Cooper wrote: >> make: stopped in /usr/src/git >> $ ls -l /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE >> lrwxr-xr-x 1 root wheel 27 Nov 1 16:24 >> /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE -&g

Re: libXO-ification - Why - and is it a symptom of deeper issues?

2015-11-15 Thread Andrey Chernov
On 15.11.2015 20:37, Adrian Chadd wrote: > On 15 November 2015 at 09:10, Dan Partelly wrote: >> Meaning, is that simple to push things in head , if somone does the work, >> even with with no proper review of the problem at hand , and the proposed >> solutions ? > > Nope

Re: FreeBSD_HEAD-tests - Build #1675 - Unstable

2015-11-08 Thread Andrey Chernov
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09.11.2015 0:46, Baptiste Daroussin wrote: >> Error Message: > printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], > expected [123,456,78.0625]<> Looks like numericdef "grouping" handling problem... >>> >>> Seems like the

Re: FreeBSD_HEAD-tests - Build #1675 - Unstable

2015-11-08 Thread Andrey Chernov
On 09.11.2015 0:08, Baptiste Daroussin wrote: > On Sun, Nov 08, 2015 at 11:10:58PM +0300, Andrey Chernov wrote: >> On 08.11.2015 22:08, jenkins-ad...@freebsd.org wrote: >>> FreeBSD_HEAD-tests - Build #1675 - Unstable: >>> >>> Build information: >>>

Re: FreeBSD_HEAD-tests - Build #1675 - Unstable

2015-11-08 Thread Andrey Chernov
On 08.11.2015 22:08, jenkins-ad...@freebsd.org wrote: > FreeBSD_HEAD-tests - Build #1675 - Unstable: > > Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/ > Full change log: > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/changes > Full build log: >

Re: FreeBSD_HEAD-tests - Build #1675 - Unstable

2015-11-08 Thread Andrey Chernov
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09.11.2015 0:46, Baptiste Daroussin wrote: >> BTW, see other tests fails here in jenkins too, they looks >> related to locale changes. > > I will look into them. About that one, it looks like collate support is broken in regex: FAILED:

Re: FreeBSD_HEAD-tests - Build #1636 - Still Unstable

2015-11-02 Thread Andrey Chernov
On 02.11.2015 11:36, jenkins-ad...@freebsd.org wrote: > FreeBSD_HEAD-tests - Build #1636 - Still Unstable: > > Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1636/ > Full change log: > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1636/changes > Full build log: >

Re: ls is broken for non-C locales due to libxo

2015-06-17 Thread Andrey Chernov
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17.06.2015 16:58, Marcel Moolenaar wrote: On Jun 16, 2015, at 9:53 PM, Andrey Chernov a...@freebsd.org wrote: Should be no any %FF, but single char in pre libxo ls or nothing in post libxo one. Use LANG=ru_RU.KOI8-R before touch

Re: ls is broken for non-C locales due to libxo

2015-06-16 Thread Andrey Chernov
Marcel Moolenaar mar...@xcllnt.net пишет: On Jun 16, 2015, at 8:46 PM, Andrey Chernov a...@freebsd.org wrote: Signed PGP part On 17.06.2015 6:23, Marcel Moolenaar wrote: Date/time is fixed. I don?t know how to reproduce the filename problem, so make sure sources are up-to-date and if still

Re: ls is broken for non-C locales due to libxo

2015-06-16 Thread Andrey Chernov
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17.06.2015 6:23, Marcel Moolenaar wrote: Date/time is fixed. I don?t know how to reproduce the filename problem, so make sure sources are up-to-date and if still a problem, provide me with a way to reproduce. touch `printf \377` env

ls is broken for non-C locales due to libxo

2015-06-16 Thread Andrey Chernov
Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just ls eats whole filenames with printable national characters inside. Long live libxo. ___ freebsd-current@freebsd.org mailing list

Re: ls is broken for non-C locales due to libxo

2015-06-16 Thread Andrey Chernov
On 17.06.2015 5:18, Andrey Chernov wrote: Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just ls eats whole filenames with printable national characters inside. Long live libxo. I mean ls -l. To be precise, for 8bit non-C locales at least: ls -lt: skip date column

Re: seekdir/readdir patch .. Call for Review.

2015-05-03 Thread Andrey Chernov
On 03.05.2015 16:01, Julian Elischer wrote: Before making single-purpose changes to the libc readdir and seekdir code, or to the kernel code, it would be useful to state exact behaviour of the dirent machinery we want to see. No, 'make samba works in my situation' does not sound good enough.

Re: Massive libxo-zation that breaks everything

2015-03-04 Thread Andrey Chernov
On 04.03.2015 19:21, John Baldwin wrote: On Tuesday, March 03, 2015 09:09:43 AM David Chisnall wrote: Hopefully there's a lesson here that we can learn from: human-readable formats do not make good intermediate representations when communicating between tools. I think this is actually an

Re: Massive libxo-zation that breaks everything

2015-03-02 Thread Andrey Chernov
On 03.03.2015 4:45, Alfred Perlstein wrote: On Mar 2, 2015, at 5:37 PM, Andrey Chernov a...@freebsd.org wrote: On 03.03.2015 4:30, Alfred Perlstein wrote: On Mar 2, 2015, at 4:22 PM, Andrey Chernov a...@freebsd.org wrote: On 02.03.2015 22:55, Julian Elischer wrote: On 3/2/15 5:27 AM

Re: Massive libxo-zation that breaks everything

2015-03-02 Thread Andrey Chernov
On 03.03.2015 3:48, Allan Jude wrote: On 2015-03-02 19:22, Andrey Chernov wrote: On 02.03.2015 22:55, Julian Elischer wrote: On 3/2/15 5:27 AM, Alfred Perlstein wrote: On 3/2/15 4:14 AM, Julian Elischer wrote: On 3/1/15 10:49 AM, Harrison Grundy wrote: Thanks! That does seem useful

Re: Massive libxo-zation that breaks everything

2015-03-02 Thread Andrey Chernov
On 03.03.2015 4:30, Alfred Perlstein wrote: On Mar 2, 2015, at 4:22 PM, Andrey Chernov a...@freebsd.org wrote: On 02.03.2015 22:55, Julian Elischer wrote: On 3/2/15 5:27 AM, Alfred Perlstein wrote: On 3/2/15 4:14 AM, Julian Elischer wrote: On 3/1/15 10:49 AM, Harrison Grundy wrote

Re: Massive libxo-zation that breaks everything

2015-03-02 Thread Andrey Chernov
On 02.03.2015 22:55, Julian Elischer wrote: On 3/2/15 5:27 AM, Alfred Perlstein wrote: On 3/2/15 4:14 AM, Julian Elischer wrote: On 3/1/15 10:49 AM, Harrison Grundy wrote: Thanks! That does seem useful, but I'm not sure I see the reasoning behind putting into base, over a port or package,

Re: buildworld broken on current with WITHOUT_CAPSICUM

2015-01-10 Thread Andrey Chernov
It is broken exact at the same place even without WITHOUT_CAPSICUM. On 09.01.2015 5:23, Manfred Antar wrote: On amd64 current build world is broken if defined WITHOUT_CAPSICUM svn revision 276867 here is the error: /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:80:10:

Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!

2014-11-01 Thread Andrey Chernov
On 01.11.2014 21:26, Trond Endrestøl wrote: What good does the file /entropy do if boot up is delayed everytime during Writing entropy file:? Probably some entropy is needed before saved file is loaded. As raw guessing of alternative solution it is possible to make some part of previously

Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

2014-09-13 Thread Andrey Chernov
On 13.09.2014 8:29, Peter Wemm wrote: On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov a...@freebsd.org wrote: On 09.09.2014 21:53, Patrick Kelsey wrote: I don't think it is worth the trouble, as given the larger pattern of libc

Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

2014-09-10 Thread Andrey Chernov
On 09.09.2014 21:53, Patrick Kelsey wrote: I don't think it is worth the trouble, as given the larger pattern of libc routines requiring multiple capsicum rights, it seems one will in general have to have libc implementation knowledge when using it in concert with capsicum. For example,

Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

2014-09-08 Thread Andrey Chernov
On 09.09.2014 0:28, Patrick Kelsey wrote: In r268997, _ftello() was modified to use _fcntl(F_GETFL) in the non-append, write-only path. Consequently, programs that use _ftello() (via ftell, fgetpos, fsetpos, fseek, rewind...) on non-append, write-only files and that use capsicum to restrict

Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

2014-09-08 Thread Andrey Chernov
On 09.09.2014 1:13, Patrick Kelsey wrote: You make a godo point about the wider use of fcntl() in libc - aside from the rpc code, by my count there are 14 other entry points in libc that use fcntl in their implementation. To experience breakage, programs that use those entry points would also

Latest -current panic in uaudio_detach() / bus_dmamem_free()

2014-06-22 Thread Andrey Chernov
Always happens at shutdown after all buffers are synced, see screenshot: http://i.imgur.com/8WXTMPj.png -- http://ache.vniz.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send

Re: Latest -current panic in uaudio_detach() / bus_dmamem_free()

2014-06-22 Thread Andrey Chernov
On 23.06.2014 6:46, Alexander Kabaev wrote: Please provide us with the information on the actual audio hardware you are using, preferably in form of a dmesg output. uaudio0: vendor 0x046d product 0x0990, class 239/2, rev 2.00/0.05, addr 7 on usbus3 uaudio0: No playback. uaudio0: Record: 16000

Re: login.conf -- UTF-8

2014-04-05 Thread Andrey Chernov
Few explanations to clarify maybe non-obvious moments: On 05.04.2014 7:35, Andrey Chernov wrote: big hack and slowing sorting down up to 10 times. Because our search for chains is linear because common single byte table have no more than 2-3 chains. I don't think it worth efforts to optimize

Re: login.conf -- UTF-8

2014-04-04 Thread Andrey Chernov
On 04.04.2014 16:46, Gleb Smirnoff wrote: On Thu, Apr 03, 2014 at 01:34:33AM +0400, Andrey Chernov wrote: A On 02.04.2014 21:15, Gleb Smirnoff wrote: A S + :lang=en_US.UTF-8:\ A S + :charset=UTF-8: A A And I'd like to do same change for the 'russian' login class A in /etc

Re: login.conf -- UTF-8

2014-04-04 Thread Andrey Chernov
On 05.04.2014 6:39, Sean Bruno wrote: On Sat, 2014-04-05 at 05:35 +0400, Andrey Chernov wrote: On 04.04.2014 16:46, Gleb Smirnoff wrote: On Thu, Apr 03, 2014 at 01:34:33AM +0400, Andrey Chernov wrote: A On 02.04.2014 21:15, Gleb Smirnoff wrote: A S + :lang=en_US.UTF-8:\ A S + :charset

Re: login.conf -- UTF-8

2014-04-04 Thread Andrey Chernov
On 05.04.2014 5:35, Andrey Chernov wrote: Even his version 2 have my objections. I already reply Alex about this in 2008. In short: 1) It is error there: almost all single chars above ASCII should be chains, i.t. two bytes minimum ... I check my whole correspondence with Alexey and withdraw

  1   2   >