Re: gettext - acl tests - cygwin specific code path

2018-08-21 Thread cyg Simple 
On 8/21/2018 4:13 PM, Andrey Repin wrote:
> Greetings, cyg Simple!
> 
>> During the testing at least one of the tests does `setfacl -m group:0:1
>> tmpfile0`.  Obviously this gets a 'permission denied' error as group 0
>> doesn't exist.  What do you suggest for reasonable replacement for 0?
> 
> Nothing. Not all systems have a concept of "group 0". Just skip this test.

I'm not interested in skipping the test; after all the path for the test
is Cygwin specific.  It's just not the correct thing to do for the
Cygwin specific path.  I believe 11 to be the correct test and will
pursue that upstream.  Marco suggested maybe 544(Administrator) but that
doesn't work with a typical user build while doing the same in Linux for
root group 0 as a typical user I would need to have elevated privilege
in Windows to use 544.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gettext - acl tests - cygwin specific code path

2018-08-21 Thread Andrey Repin 
Greetings, cyg Simple!

> During the testing at least one of the tests does `setfacl -m group:0:1
> tmpfile0`.  Obviously this gets a 'permission denied' error as group 0
> doesn't exist.  What do you suggest for reasonable replacement for 0?

Nothing. Not all systems have a concept of "group 0". Just skip this test.


-- 
With best regards,
Andrey Repin
Tuesday, August 21, 2018 23:12:42

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gettext - acl tests - cygwin specific code path

2018-08-21 Thread Marco Atzeri 

Am 21.08.2018 um 20:58 schrieb cyg Simple:

On 8/21/2018 11:52 AM, cyg Simple wrote:

I've been reviewing the testing of gettext and I have a failure for all
of the acl tests.  I've found that a file without acl will obtain acl if
the mode is changed to 605. STC below.







During the testing at least one of the tests does `setfacl -m group:0:1
tmpfile0`.  Obviously this gets a 'permission denied' error as group 0
doesn't exist.  What do you suggest for reasonable replacement for 0?
I'm thinking 11(Authenticated Users) as the purpose of the test is to
determine if the use of `set_acl (file, -1, mode);` will reset to a file
without acl.



group 0 is likely root.
In theory you can replace with 544 = Administrator
but you need to be an admin.

Otherwise 11 or 545 (Users) should be fine

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gettext - acl tests - cygwin specific code path

2018-08-21 Thread cyg Simple 
On 8/21/2018 11:52 AM, cyg Simple wrote:
> I've been reviewing the testing of gettext and I have a failure for all
> of the acl tests.  I've found that a file without acl will obtain acl if
> the mode is changed to 605. STC below.
> 
> 
> $ touch /tmp/tmpfile0
> $ ls -l /tmp/tmpfile0
> -rw-r--r-- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
> $ getfacl /tmp/tmpfile0
> # file: /tmp/tmpfile0
> # owner: myUser
> # group: myGroup
> user::rw-
> group::r--
> other:r--
> $ chmod 600
> $ ls -l /tmp/tmpfile0
> -rw--- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
> $ getfacl /tmp/tmpfile0
> # file: /tmp/tmpfile0
> # owner: myUser
> # group: myGroup
> user::rw-
> group::---
> other:---
> $ chmod 605
> $ ls -l /tmp/tmpfile0
> -rwr-x+ 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
> $ getfacl /tmp/tmpfile0
> # file: /tmp/tmpfile0
> # owner: myUser
> # group: myGroup
> user::rw-
> group::---
> other:r-x
> user:myUser:---
> 
> 
> gettext loops through a number of modes and fortunately one of those had
> an owner and other without the group. Anytime the other is set without
> the owner or group having permission we get an ACL for the user which is
> wrong.  A `setfacl -b /tmp/tmpfile0` doesn't correct the information
> from getfacl.
> 

During the testing at least one of the tests does `setfacl -m group:0:1
tmpfile0`.  Obviously this gets a 'permission denied' error as group 0
doesn't exist.  What do you suggest for reasonable replacement for 0?
I'm thinking 11(Authenticated Users) as the purpose of the test is to
determine if the use of `set_acl (file, -1, mode);` will reset to a file
without acl.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

gettext - acl tests - cygwin specific code path

2018-08-21 Thread cyg Simple 
I've been reviewing the testing of gettext and I have a failure for all
of the acl tests.  I've found that a file without acl will obtain acl if
the mode is changed to 605. STC below.


$ touch /tmp/tmpfile0
$ ls -l /tmp/tmpfile0
-rw-r--r-- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
$ getfacl /tmp/tmpfile0
# file: /tmp/tmpfile0
# owner: myUser
# group: myGroup
user::rw-
group::r--
other:r--
$ chmod 600
$ ls -l /tmp/tmpfile0
-rw--- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
$ getfacl /tmp/tmpfile0
# file: /tmp/tmpfile0
# owner: myUser
# group: myGroup
user::rw-
group::---
other:---
$ chmod 605
$ ls -l /tmp/tmpfile0
-rwr-x+ 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
$ getfacl /tmp/tmpfile0
# file: /tmp/tmpfile0
# owner: myUser
# group: myGroup
user::rw-
group::---
other:r-x
user:myUser:---


gettext loops through a number of modes and fortunately one of those had
an owner and other without the group. Anytime the other is set without
the owner or group having permission we get an ACL for the user which is
wrong.  A `setfacl -b /tmp/tmpfile0` doesn't correct the information
from getfacl.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: memory reported in /proc/pid/status is wrongly scaled

2018-08-21 Thread Corinna Vinschen 
On Aug 21 16:53, Livio Bertacco wrote:
> Thanks Corinna, I tried the developer snapshot and the VmSize line from
> "status" file looks good now.
> 
> What do you think about adding the VmPeak line too? (I can create the patch
> myself).
> 
> >  On second thought there's more wrong than just that.
> > Just dividing by page_size or allocation_granularity results in too small
> values.
> 
> Yes, now that you mention it, this rounding up is actually still missing
> for the vmrss and vmmaxrss values in the "stat" file (which just divides by
> page_size):
> 1150
> 
> vmrss = vmc.WorkingSetSize / page_size;
> 1151
> 
> vmmaxrss = ql.MaximumWorkingSetSize / page_size;
> and, by the way, is it correct that these two are reported in 4k pages
> instead of 64k pages?
> "statm" reports e.g. VmRss (that's the second value in the statm line) in
> 64k pages so that value doesn't match the same Rss amount (24th value) from
> "stat".

I'd actually be happy to get patches here.  Just have a look at
https://cygwin.com/contrib.html for the 2-clause BSD statement.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: memory reported in /proc/pid/status is wrongly scaled

2018-08-21 Thread Livio Bertacco 
Thanks Corinna, I tried the developer snapshot and the VmSize line from
"status" file looks good now.

What do you think about adding the VmPeak line too? (I can create the patch
myself).

>  On second thought there's more wrong than just that.
> Just dividing by page_size or allocation_granularity results in too small
values.

Yes, now that you mention it, this rounding up is actually still missing
for the vmrss and vmmaxrss values in the "stat" file (which just divides by
page_size):
1150

vmrss = vmc.WorkingSetSize / page_size;
1151

vmmaxrss = ql.MaximumWorkingSetSize / page_size;
and, by the way, is it correct that these two are reported in 4k pages
instead of 64k pages?
"statm" reports e.g. VmRss (that's the second value in the statm line) in
64k pages so that value doesn't match the same Rss amount (24th value) from
"stat".

Livio


> -- Forwarded message --
> From: Corinna Vinschen 
> To: cygwin@cygwin.com
> Cc:
> Bcc:
> Date: Fri, 17 Aug 2018 20:44:02 +0200
> Subject: Re: memory reported in /proc/pid/status is wrongly scaled
> On Aug 17 19:14, Corinna Vinschen wrote:
> > On Aug 17 16:05, Livio Bertacco wrote:
> > >  Hi,
> > > While playing with reading process memory usage in Linux and cygwin, I
> > > found that cygwin reports too large values in /proc/self/status (in
> 2.10.0
> > > and earlier).
> > > Whenever I was allocating a few kB in my test program, the VmSize line
> in
> > > /proc/self/status was growing several times faster.
> > >
> > > Small bash script to show the issue:
> > > #!/bin/bash
> > > pid=$$
> > > vmsizesplit=($(grep VmSize /proc/$pid/status))
> > > vmsize1="${vmsizesplit[1]}"
> > > echo Initial memory reported in status: $vmsize1 kB
> > > echo Allocating a 1000 kB string (bash can use more memory)
> > > eat=$(printf '%1024000s')
> > > vmsizesplit=($(grep VmSize /proc/$pid/status))
> > > vmsize2="${vmsizesplit[1]}"
> > > echo Current memory reported in status: $vmsize2 kB
> > > echo Difference is $[$vmsize2-$vmsize1] kB
> > >
> > > Running this in cygwin on my laptop I get:
> > > Initial memory reported in status: 84928 kB
> > > Allocating a 1000 kB string (bash can use more memory)
> > > Current memory reported in status: 106880 kB
> > > Difference is 21952 kB
> > >
> > > While bash may use quite more than 1000 kb in this case, 22x times
> larger
> > > doesn't seem right.
> > >
> > > Checking source file fhandler_process.cc, the
> > > function format_process_status which writes the "status" proc file
> > > retrieves memory usage via get_mem_values. Get_mem_values obtains that
> info
> > > from NtQueryInformationProcess/PagefileUsage which is in bytes, then
> it
> > > scales it to pages dividing by wincap.page_size:
> > > 1515: *vmsize = vmc.PagefileUsage / wincap.page_size ();
> > >
> > > Then format_process_status scales it back, in theory to bytes, and
> shifts
> > > it by 10 bits in order to print it out in kB:
> > > 1219:  unsigned page_size = wincap.allocation_granularity ();
> >
> > Looks like this is the bug.  get_mem_values returns all values
> > in multiple of OS page_size (4K), but format_process_status multiplies
> > with allocation_granularity (64K), leading to 16 times overallocation
> > value.  The other caller of get_mem_values, format_process_statm,
> > returns number of pages.  This must be expressed in multiples of
> > allocation_granularity since that's the virtual page_size in Cygwin.
> > But in case of format_process_status we're looking at KB values, so
> > patch 8a32c24a7bdb0, replaceing page_size with allocation_granularity,
> > was incorrect.
> >
> > Good catch!
> >
> > I'll revert patch 8a32c24a7bdb0 for 2.11.0.
>
> On second thought there's more wrong than just that.  Just dividing
> by page_size or allocation_granularity results in too small values.
> I applied patches to return more correct values and I made sure
> the values in status and statm are consistently rounded up to
> Cygwin's page size of 64K.
>
> I uploaded new developer snapshots to https://cygwin.com/snapshots
> for testing.  Please give them a try.
>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat
>
>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: libunistring 0.9.10-1

2018-08-21 Thread waterlan 

libunistring (source package)
libunistring2 (runtime library)
libunistring-devel (development library and include files)
libunistring-doc (documentation)


CHANGES:



New in 0.9.10:
* The functions
u8_casing_prefix_context, u8_casing_prefixes_context,
u8_casing_suffix_context, u8_casing_suffixes_context,
u16_casing_prefix_context, u16_casing_prefixes_context,
u16_casing_suffix_context, u16_casing_suffixes_context,
u32_casing_prefix_context, u32_casing_prefixes_context,
u32_casing_suffix_context, u32_casing_suffixes_context,
  that are documented since version 0.9.1, are now actually implemented.

New in 0.9.9:
* Fixed a multithread-safety bug.

http://git.savannah.gnu.org/cgit/libunistring.git/tree/NEWS


DESCRIPTION:



Text files are nowadays usually encoded in Unicode, and may consist of 
very different scripts – from Latin letters to Chinese Hanzi –, with 
many kinds of special characters – accents, right-to-left writing marks, 
hyphens, Roman numbers, and much more. But the POSIX platform APIs for 
text do not contain adequate functions for dealing with particular 
properties of many Unicode characters. In fact, the POSIX APIs for text 
have several assumptions at their base which don't hold for Unicode 
text.


This library provides functions for manipulating Unicode strings and for 
manipulating C strings according to the Unicode standard.


homepage: http://www.gnu.org/s/libunistring/
license: LGPL


DETAILS:



This library consists of the following parts:

 elementary string functions
 conversion from/to legacy encodings
 formatted output to strings
 character names
 character classification and properties
 string width when using nonproportional fonts
 word breaks
 line breaking algorithm
 normalization (composition and decomposition)
 case folding
 regular expressions (not yet implemented)
 grapheme cluster breaking



Who needs libunistring?
===


libunistring is for you if your application involves non-trivial text 
processing, such as upper/lower case conversions, line breaking, 
operations on words, or more advanced analysis of text. Text provided by 
the user can, in general, contain characters of all kinds of scripts. 
The text processing functions provided by this library handle all 
scripts and all languages.


libunistring is for you if your application already uses the ISO C / 
POSIX ,  functions and the text it operates on is 
provided by the user and can be in any language.


libunistring is also for you if your application uses Unicode strings as 
internal in-memory representation



--
Erwin Waterlander
http://waterlan.home.xs4all.nl/

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Updated: libunistring 0.9.10-1

2018-08-21 Thread waterlan 

libunistring (source package)
libunistring2 (runtime library)
libunistring-devel (development library and include files)
libunistring-doc (documentation)


CHANGES:



New in 0.9.10:
* The functions
u8_casing_prefix_context, u8_casing_prefixes_context,
u8_casing_suffix_context, u8_casing_suffixes_context,
u16_casing_prefix_context, u16_casing_prefixes_context,
u16_casing_suffix_context, u16_casing_suffixes_context,
u32_casing_prefix_context, u32_casing_prefixes_context,
u32_casing_suffix_context, u32_casing_suffixes_context,
  that are documented since version 0.9.1, are now actually implemented.

New in 0.9.9:
* Fixed a multithread-safety bug.

http://git.savannah.gnu.org/cgit/libunistring.git/tree/NEWS


DESCRIPTION:



Text files are nowadays usually encoded in Unicode, and may consist of 
very different scripts – from Latin letters to Chinese Hanzi –, with 
many kinds of special characters – accents, right-to-left writing marks, 
hyphens, Roman numbers, and much more. But the POSIX platform APIs for 
text do not contain adequate functions for dealing with particular 
properties of many Unicode characters. In fact, the POSIX APIs for text 
have several assumptions at their base which don't hold for Unicode 
text.


This library provides functions for manipulating Unicode strings and for 
manipulating C strings according to the Unicode standard.


homepage: http://www.gnu.org/s/libunistring/
license: LGPL


DETAILS:



This library consists of the following parts:

 elementary string functions
 conversion from/to legacy encodings
 formatted output to strings
 character names
 character classification and properties
 string width when using nonproportional fonts
 word breaks
 line breaking algorithm
 normalization (composition and decomposition)
 case folding
 regular expressions (not yet implemented)
 grapheme cluster breaking



Who needs libunistring?
===


libunistring is for you if your application involves non-trivial text 
processing, such as upper/lower case conversions, line breaking, 
operations on words, or more advanced analysis of text. Text provided by 
the user can, in general, contain characters of all kinds of scripts. 
The text processing functions provided by this library handle all 
scripts and all languages.


libunistring is for you if your application already uses the ISO C / 
POSIX ,  functions and the text it operates on is 
provided by the user and can be in any language.


libunistring is also for you if your application uses Unicode strings as 
internal in-memory representation



--
Erwin Waterlander
http://waterlan.home.xs4all.nl/