Re: [oi-dev] clamav update

[Bradley's Auto Service via oi-dev]

please remove me from this list


|  | 
| 
 |
| | Bradley's Auto Service | |
| T:  833.292.3344 |
| P:  732.842.4353 |
| E:  bradleysa...@verizon.net |
| F:  732.842.2481335 Shrewsbury Avenue, Red Bank NJ 07701 |
| www.bradleysauto.com |
| 
|  |  |  |

 |

 |


|  |


|  |
| 
 |


|   |




-Original Message-
From: Friedrich Kink via oi-dev 
To: oi-dev@openindiana.org
Cc: Friedrich Kink 
Sent: Tue, Jan 11, 2022 4:17 pm
Subject: Re: [oi-dev] clamav update

 Hi Tim, many, many kudo's. You were right, after installing 
system/library/iconv/unicode all tests passed +Test project $(@D)
 +    Start 1: libclamav
 +1/5 Test #1: libclamav    Passed   19.76 sec
 +    Start 2: clamscan
 +2/5 Test #2: clamscan .   Passed    4.83 sec
 +    Start 3: clamd
 +3/5 Test #3: clamd    Passed   21.79 sec
 +    Start 4: freshclam
 +4/5 Test #4: freshclam    Passed    2.07 sec
 +    Start 5: sigtool
 +5/5 Test #5: sigtool ..   Passed    0.63 sec
 +
 +100% tests passed, 0 tests failed out of 5 
  and even 
  builduser@userland:~$ iconv -f PCK -t UTF-8 "/tmp/ja"
 縺薙ｓ縺ｫ縺｡縺ｯ縺薙ｓ縺ｫ縺｡縺ｯ now delivers a reasonable result. Another question. Jim 
Klimov initially created this package. He also prepared a README stating: It is 
expected that ultimate deployments might not want to run all of
 the components in the same operating environment. In particular, the
 maintenance of a local copy of the virus definitions database adds a
 considerable storage and internet-traffic overhead which would be not
 needed on systems that do not run `clamd` or other implementations of
 the scanning engine directly.
  So, he created several packages to allow distinct installations. Currently 
I've created only one package, but for update reasons should I stick to the 
original packages (I think storage shouldn't be a problem nowadays, despite I'm 
an educated engineer trying to be as efficient to environment as possible, 
basically it is a  consideration of minimum space requirements and kind of 
convenience, also without updating databases a virus scanner on a regular basis 
is kind of useless, right)? kind regards,   Fritz
  
  Am 11.01.2022 um 21:15 schrieb Tim Mooney via oi-dev:
  
In regard to: Re: [oi-dev] clamav update, Friedrich Kink via oi-dev said...: 
 
 
But maybe this code page is simply not supported by openindiana because I tried 
to play around with iconv, too (it seems there is nothing similar to 
JAPANESE_SHIFT_JIS) : 
 
 
 I just ran into this a couple weeks ago with a different test suite. 
 Based on how I read iconv_unicode(5) (and iconv(5), for non unicode), 
 OI's iconv has a limited set of supported conversions. 
 
 The tables in iconv_unicode(5) list "SJIS", though, which is the alias 
 OI uses, so in theory it should be possible to go from UTF-8 to SJIS. 
 
 That it's not showing up in the output from iconv -l has me wondering if 
 it's the case of a missing package.  My guess is there should be a module 
 somewhere in /usr/lib/iconv/ that has "SJIS" (or perhaps some variant of 
 Kanji, since that's listed as the name, and SJIS is apparently the alias?) 
 somewhere in its name. 
 
 Note the 'eucJP' does show up in the iconv output, and that is an 
 alternate (incompatible) pre-Unicode encoding. 
 
 This page has a lot of good info on the various encodings for Japan: 
 
 https://www.sljfaq.org/afaq/encodings.html 
 
 Tim 
 
 ___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] clamav update

[Friedrich Kink via oi-dev]

Hi Tim,

many, many kudo's. You were right, after installing 
system/library/iconv/unicode 
 
all tests passed


+Test project $(@D)
+    Start 1: libclamav
+1/5 Test #1: libclamav    Passed 19.76 sec
+    Start 2: clamscan
+2/5 Test #2: clamscan .   Passed 4.83 sec
+    Start 3: clamd
+3/5 Test #3: clamd    Passed 21.79 sec
+    Start 4: freshclam
+4/5 Test #4: freshclam    Passed 2.07 sec
+    Start 5: sigtool
+5/5 Test #5: sigtool ..   Passed 0.63 sec
+
+100% tests passed, 0 tests failed out of 5

and even

builduser@userland:~$ iconv -f PCK -t UTF-8 "/tmp/ja"
縺薙ｓ縺ｫ縺｡縺ｯ縺薙ｓ縺ｫ縺｡縺ｯ

now delivers a reasonable result.

Another question. Jim Klimov initially created this package. He also 
prepared a README stating:


/It is expected that ultimate deployments might not want to run all of//
//the components in the same operating environment. In particular, the//
//maintenance of a local copy of the virus definitions database adds a//
//considerable storage and internet-traffic overhead which would be not//
//needed on systems that do not run `clamd` or other implementations of//
//the scanning engine directly.//
/

So, he created several packages to allow distinct installations. 
Currently I've created only one package, but for update reasons should I 
stick to the original packages (I think storage shouldn't be a problem 
nowadays, despite I'm an educated engineer trying to be as efficient to 
environment as possible, basically it is a consideration of minimum 
space requirements and kind of convenience, also without updating 
databases a virus scanner on a regular basis is kind of useless, right)?


kind regards,

  Fritz


Am 11.01.2022 um 21:15 schrieb Tim Mooney via oi-dev:
In regard to: Re: [oi-dev] clamav update, Friedrich Kink via oi-dev 
said...:


But maybe this code page is simply not supported by openindiana 
because I tried to play around with iconv, too (it seems there is 
nothing similar to JAPANESE_SHIFT_JIS) :


I just ran into this a couple weeks ago with a different test suite.
Based on how I read iconv_unicode(5) (and iconv(5), for non unicode),
OI's iconv has a limited set of supported conversions.

The tables in iconv_unicode(5) list "SJIS", though, which is the alias
OI uses, so in theory it should be possible to go from UTF-8 to SJIS.

That it's not showing up in the output from iconv -l has me wondering if
it's the case of a missing package.  My guess is there should be a module
somewhere in /usr/lib/iconv/ that has "SJIS" (or perhaps some variant of
Kanji, since that's listed as the name, and SJIS is apparently the 
alias?)

somewhere in its name.

Note the 'eucJP' does show up in the iconv output, and that is an
alternate (incompatible) pre-Unicode encoding.

This page has a lot of good info on the various encodings for Japan:

https://www.sljfaq.org/afaq/encodings.html

Tim___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] rrdtool update questions

[Friedrich Kink via oi-dev]

Hi Andreas,

thank you very much, WORKS!! Your solution is not intrusive therefor I 
prefer.


Will check it in tomorrow once I figured out how to deal with failed tests.

kind regards,

  Fritz

Am 11.01.2022 um 21:16 schrieb Andreas Wacknitz:

Am 11.01.22 um 20:51 schrieb Klaus Ziegler:

Hi Fritz,

this publish error can be fixed in:
.../oi-userland/tools/python/pkglint:

@@ -333,8 +333,6 @@

 if bits == 32 and path64:
 result = _("32-bit object '%s' in 64-bit path")
-    elif bits == 64 and not path64:
-    result = _("64-bit object '%s' in 32-bit path")
 return result

 def file_action(self, action, manifest, engine, 
pkglint_id="001"):


@Andreas,
perhaps we should make this the default, as we anyway move forward
to migrate more and more apps/libs/tool  to be only 64bit, what di 
you think?
There are other things possible: Either add a "pkg.linted=true" column 
if only a single action is affected or add a transform rule in the 
manifest, eg.
 default 
pkg.linted.userland.action001.2 true>


This way you can deliberately turn the error off.




Many Regards
Klaus



On 1/11/22 18:10, Friedrich Kink via oi-dev wrote:


Hi all,

based on Andreas' comment I rebuild rrdtool exclusively 2for 64-bit. 
This added also support for all bindings lua, tcl, perl, ruby (v2.6) 
and pyhton (v3.7). Though python created some headache. It build 
needs an ugly tweak of the configure script to find the right header 
files. The issue is cause by /usr/include/pyhton3.7*m. *Both version 
python3.7 and pyhton3.7m reports back PYTHON_VERSION 3.7. Based on 
this return the PYTHON_INCLUDES is always created as 
/usr/include/pyhton3.7 which does not exist. Is this intentional 
(the real path is /usr/include/pyhton3.7m, just a warmup question 
;-). But the real problem I have with this python binding is this 
error when publishing:


/usr/bin/python3.5 /usr/bin/pkglint  \
    -f /usr/share/src/myoi-userland/tools/pkglintrc 
/usr/src/myoi-userland/components/image/rrdtool/build/manifest-i386-rrdtool.depend.res

Lint engine setup...
Starting lint run...
ERROR userland.action001.2    64-bit object 
'usr/lib/python3.7/site-packages/rrdtool.cpython-37m.so' in 32-bit path
WARNING pkglint.action005.1   obsolete dependency check skipped: 
unable to find dependency 
pkg:/image/library/libpng16@1.6.37-2020.0.1.0 for 
pkg:/image/rrdtool@1.7.2,5.11-2022.0.0.0


Is there a way to overcome this problem or should i just remove the 
python3.7 binding (basically all pathon3.x versions)? BTW phyton2.7 
would work without problem including publishing but I didn't want to 
create a dependency to this soon to be deprecated/removed version.


kind regards,

  Fritz

PS: What about failing tests? Are they just to be reported or should 
I try to fix them?


It would be good to fix failing tests. Alas it's not always possible 
and sometimes it would take more time than reasonable.
So you should decide whether it's worth the efforts to fix a test. In 
my opinion it depends on the importance and severity of the failure.
In this case it's only marginally as we probably don't have many 
rrdtool users with japanese locale settings.


Regards,
Andreas

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] rrdtool update questions

[Andreas Wacknitz]

Am 11.01.22 um 20:51 schrieb Klaus Ziegler:

Hi Fritz,

this publish error can be fixed in:
.../oi-userland/tools/python/pkglint:

@@ -333,8 +333,6 @@

 if bits == 32 and path64:
 result = _("32-bit object '%s' in 64-bit path")
-    elif bits == 64 and not path64:
-    result = _("64-bit object '%s' in 32-bit path")
 return result

 def file_action(self, action, manifest, engine,
pkglint_id="001"):

@Andreas,
perhaps we should make this the default, as we anyway move forward
to migrate more and more apps/libs/tool  to be only 64bit, what di you
think?

There are other things possible: Either add a "pkg.linted=true" column
if only a single action is affected or add a transform rule in the
manifest, eg.
 default
pkg.linted.userland.action001.2 true>

This way you can deliberately turn the error off.




Many Regards
Klaus



On 1/11/22 18:10, Friedrich Kink via oi-dev wrote:


Hi all,

based on Andreas' comment I rebuild rrdtool exclusively 2for 64-bit.
This added also support for all bindings lua, tcl, perl, ruby (v2.6)
and pyhton (v3.7). Though python created some headache. It build
needs an ugly tweak of the configure script to find the right header
files. The issue is cause by /usr/include/pyhton3.7*m. *Both version
python3.7 and pyhton3.7m reports back PYTHON_VERSION 3.7. Based on
this return the PYTHON_INCLUDES is always created as
/usr/include/pyhton3.7 which does not exist. Is this intentional (the
real path is /usr/include/pyhton3.7m, just a warmup question ;-). But
the real problem I have with this python binding is this error when
publishing:

/usr/bin/python3.5 /usr/bin/pkglint  \
    -f /usr/share/src/myoi-userland/tools/pkglintrc
/usr/src/myoi-userland/components/image/rrdtool/build/manifest-i386-rrdtool.depend.res
Lint engine setup...
Starting lint run...
ERROR userland.action001.2    64-bit object
'usr/lib/python3.7/site-packages/rrdtool.cpython-37m.so' in 32-bit path
WARNING pkglint.action005.1   obsolete dependency check skipped:
unable to find dependency
pkg:/image/library/libpng16@1.6.37-2020.0.1.0 for
pkg:/image/rrdtool@1.7.2,5.11-2022.0.0.0

Is there a way to overcome this problem or should i just remove the
python3.7 binding (basically all pathon3.x versions)? BTW phyton2.7
would work without problem including publishing but I didn't want to
create a dependency to this soon to be deprecated/removed version.

kind regards,

  Fritz

PS: What about failing tests? Are they just to be reported or should
I try to fix them?


It would be good to fix failing tests. Alas it's not always possible and
sometimes it would take more time than reasonable.
So you should decide whether it's worth the efforts to fix a test. In my
opinion it depends on the importance and severity of the failure.
In this case it's only marginally as we probably don't have many rrdtool
users with japanese locale settings.

Regards,
Andreas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] rrdtool update questions

[Klaus Ziegler]

Hi Fritz,

this publish error can be fixed in:
.../oi-userland/tools/python/pkglint:

@@ -333,8 +333,6 @@

 if bits == 32 and path64:
 result = _("32-bit object '%s' in 64-bit path")
-    elif bits == 64 and not path64:
-    result = _("64-bit object '%s' in 32-bit path")
 return result

 def file_action(self, action, manifest, engine, pkglint_id="001"):

@Andreas,
perhaps we should make this the default, as we anyway move forward
to migrate more and more apps/libs/tool  to be only 64bit, what di you 
think?


Many Regards
Klaus



On 1/11/22 18:10, Friedrich Kink via oi-dev wrote:


Hi all,

based on Andreas' comment I rebuild rrdtool exclusively 2for 64-bit. 
This added also support for all bindings lua, tcl, perl, ruby (v2.6) 
and pyhton (v3.7). Though python created some headache. It build needs 
an ugly tweak of the configure script to find the right header files. 
The issue is cause by /usr/include/pyhton3.7*m. *Both version 
python3.7 and pyhton3.7m reports back PYTHON_VERSION 3.7. Based on 
this return the PYTHON_INCLUDES is always created as 
/usr/include/pyhton3.7 which does not exist. Is this intentional (the 
real path is /usr/include/pyhton3.7m, just a warmup question ;-). But 
the real problem I have with this python binding is this error when 
publishing:


/usr/bin/python3.5 /usr/bin/pkglint  \
    -f /usr/share/src/myoi-userland/tools/pkglintrc 
/usr/src/myoi-userland/components/image/rrdtool/build/manifest-i386-rrdtool.depend.res

Lint engine setup...
Starting lint run...
ERROR userland.action001.2    64-bit object 
'usr/lib/python3.7/site-packages/rrdtool.cpython-37m.so' in 32-bit path
WARNING pkglint.action005.1   obsolete dependency check skipped: 
unable to find dependency 
pkg:/image/library/libpng16@1.6.37-2020.0.1.0 for 
pkg:/image/rrdtool@1.7.2,5.11-2022.0.0.0


Is there a way to overcome this problem or should i just remove the 
python3.7 binding (basically all pathon3.x versions)? BTW phyton2.7 
would work without problem including publishing but I didn't want to 
create a dependency to this soon to be deprecated/removed version.


kind regards,

  Fritz

PS: What about failing tests? Are they just to be reported or should I 
try to fix them?



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


--
Klaus Ziegler   Tel: (++49 6105) 968846
Zeppelinstrasse 3   Mobil: (++49 172) 3064445
D-64546 Walldorf-Moerfeldenmailto:kla...@haus-gisela.de

\\\
(.. )
=o00=(_)=00o=
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] clamav update

[Friedrich Kink via oi-dev]

Thanks for your answer. I'm not experienced at all with this kind of 
programming. I tried to change utf8 to utf16 but still no luck. 
ck_assert_msg is provided by the check pkg.


This is the code in question:

START_TEST(test_cli_codepage_to_utf8_jis)
{
    cl_error_t ret;
    char *utf8   = NULL;
    size_t utf8_size = 0;

    ret = 
cli_codepage_to_utf8("\x82\xB1\x82\xF1\x82\xC9\x82\xBF\x82\xCD", 10, 
CODEPAGE_JAPANESE_SHIFT_JIS, , _size);
    ck_assert_msg(CL_SUCCESS == ret, "test_cli_codepage_to_utf8: Failed 
to convert CODEPAGE_JAPANESE_SHIFT_JIS to UTF8: ret != SUCCESS!");
    ck_assert_msg(NULL != utf8, "sanitize_path: Failed to convert 
CODEPAGE_JAPANESE_SHIFT_JIS to UTF8: utf8 pointer is NULL!");
    ck_assert_msg(0 == strcmp(utf8, "▒~A~S▒~B~S▒~A▒▒~A▒▒~A▒"), 
"sanitize_path: '%s' doesn't match '%s'", utf8, "▒~A~S▒~B~S▒~A▒▒~A▒▒~A▒");


    if (NULL != utf8) {
    free(utf8);
    utf8 = NULL;
    }
}
END_TEST

But maybe this code page is simply not supported by openindiana because 
I tried to play around with iconv, too (it seems there is nothing 
similar to JAPANESE_SHIFT_JIS) :


v$ iconv -l
The following are all supported code set names.  All combinations
of those names are not necessarily available for the pair of the
fromcode-tocode.  Some of those code set names have aliases, which
are case-insensitive and described in parentheses following the
canonical name:

    646 (ASCII, US-ASCII, US_ASCII, USASCII),
    646da,
    646de,
    646en,
    646es,
    646fr,
    646it,
    646sv,
    8859,
    8859-1 (ISO8859-1, ISO-8859-1, ISO8859_1, ISO_8859_1),
    8859-10 (ISO8859-10, ISO8859_10, ISO-8859-10, ISO_8859_10),
    8859-13 (ISO8859-13, ISO8859_13, ISO-8859-13, ISO_8859_13),
    8859-14 (ISO8859-14, ISO8859_14, ISO-8859-14, ISO_8859_14),
    8859-15 (ISO8859-15, ISO-8859-15, ISO8859_15, ISO_8859_15),
    8859-16 (ISO8859-16, ISO8859_16, ISO-8859-16, ISO_8859_16),
    8859-2 (ISO8859-2, ISO8859_2, ISO-8859-2, ISO_8859_2, iso2),
    8859-3 (ISO8859-3, ISO8859_3, ISO-8859-3, ISO_8859_3),
    8859-4 (ISO8859-4, ISO8859_4, ISO-8859-4, ISO_8859_4),
    8859-5 (ISO8859-5, ISO8859_5, ISO-8859-5, ISO_8859_5, iso5),
    8859-6 (ISO8859-6, ISO8859_6, ISO-8859-6, ISO_8859_6),
    8859-7 (ISO8859-7, ISO8859_7, ISO-8859-7, ISO_8859_7),
    8859-8 (ISO8859-8, ISO8859_8, ISO-8859-8, ISO_8859_8),
    8859-9 (ISO8859-9, ISO8859_9, ISO-8859-9, ISO_8859_9),
    ACE (ACE),
    ACE-ALLOW-UNASSIGNED (ACE-ALLOW-UNASSIGNED, ACE_ALLOW_UNASSIGNED, 
ACEALLOWUNASSIGNED),

    BIG5,
    CP1250 (CP1250, CP-1250, CP_1250, WINDOWS-1250, ANSI-1250, 
ANSI1250, 1250, win2),
    CP1251 (CP1251, CP-1251, CP_1251, WINDOWS-1251, ANSI-1251, 
ANSI1251, 1251, win5),
    CP1252 (CP1252, CP-1252, CP_1252, WINDOWS-1252, ANSI-1252, 
ANSI1252, 1252),
    CP1253 (CP1253, CP-1253, CP_1253, WINDOWS-1253, ANSI-1253, 
ANSI1253, 1253),
    CP1254 (CP1254, CP-1254, CP_1254, WINDOWS-1254, ANSI-1254, 
ANSI1254, 1254),
    CP1255 (CP1255, CP-1255, CP_1255, WINDOWS-1255, ANSI-1255, 
ANSI1255, 1255),
    CP1256 (CP1256, CP-1256, CP_1256, WINDOWS-1256, ANSI-1256, 
ANSI1256, 1256),
    CP1257 (CP1257, CP-1257, CP_1257, WINDOWS-1257, ANSI-1257, 
ANSI1257, 1257),
    CP1258 (CP1258, CP-1258, CP_1258, WINDOWS-1258, ANSI-1258, 
ANSI1258, 1258),

    CP437 (CP437, CP-437, CP_437, 437),
    CP720 (CP720, CP-720, CP_720, 720),
    CP737 (CP737, CP-737, CP_737, 737),
    CP775 (CP775, CP-775, CP_775, 775),
    CP850 (CP850, CP-850, CP_850, 850),
    CP852 (CP852, CP-852, CP_852, 852, dos2),
    CP855 (CP855, CP-855, CP_855, 855),
    CP857 (CP857, CP-857, CP_857, 857),
    CP860 (CP860, CP-860, CP_860, 860),
    CP861 (CP861, CP-861, CP_861, 861),
    CP862 (CP862, CP-862, CP_862, 862),
    CP863 (CP863, CP-863, CP_863, 863),
    CP864 (CP864, CP-864, CP_864, 864),
    CP865 (CP865, CP-865, CP_865, 865),
    CP866 (CP866, CP-866, CP_866, 866),
    CP869 (CP869, CP-869, CP_869, 869),
    CP874 (CP874, CP-874, CP_874, 874),
    GB18030,
    GBK,
    IBM-037,
    IBM-1025,
    IBM-1026,
    IBM-1112,
    IBM-1122,
    IBM-1140,
    IBM-1141,
    IBM-1142,
    IBM-1143,
    IBM-1144,
    IBM-1145,
    IBM-1146,
    IBM-1147,
    IBM-1148,
    IBM-1149,
    IBM-273,
    IBM-277,
    IBM-278,
    IBM-280,
    IBM-284,
    IBM-285,
    IBM-297,
    IBM-420,
    IBM-424,
    IBM-500,
    IBM-850 (IBM-850, IBM850),
    IBM-852,
    IBM-855,
    IBM-856,
    IBM-857,
    IBM-862,
    IBM-864,
    IBM-866,
    IBM-869,
    IBM-870,
    IBM-871,
    IBM-875,
    IBM-921,
    IBM-922,
    ISO646,
    ISO8859-1,
    KOI8-R (KOI8-R, KOI8_R, KOI8R, KOI8),
    KOI8-U (KOI8-U, KOI8_U, KOI8U),
    PTCP154 (PTCP154),
    UCS-2 (UCS-2, UCS_2, UCS2),
    UCS-2BE (UCS-2BE, UCS_2BE, UCS2BE),
    UCS-2LE (UCS-2LE, UCS_2LE, UCS2LE),
    UCS-4 (UCS-4, UCS_4, UCS4),
    UCS-4BE (UCS-4BE, UCS_4BE, UCS4BE),
    UCS-4LE (UCS-4LE, UCS_4LE, UCS4LE),
    UTF-16 (UTF-16, UTF16, UTF_16),
    UTF-16BE (UTF-16BE, UTF16BE, UTF_16BE),
    UTF-16LE (UTF-16LE, UTF16LE, UTF_16LE),
    

Re: [oi-dev] clamav update

[Chris]

On 2022-01-11 10:02, Chris wrote:

On 2022-01-11 09:16, Friedrich Kink via oi-dev wrote:

Hi all,

I prepared the clamav update to the latest version and everything works 
fine as

expected. But one of out of all tests is failing with this error:

99%: Checks: 1175, Failures: 1, Errors: 0
/usr/src/oi-userland/components/sysutils/clamav/clamav-0.104.1/unit_tests/check_clamav.c:1707:F:assorted
functions:test_cli_codepage_to_utf8_jis:0: test_cli_codepage_to_utf8: 
Failed to

convert CODEPAGE_JAPANESE_SHIFT_JIS to UTF8: ret != SUCCESS!
NOTICE: Use the 'T' environment variable to adjust testcase timeout

 Does anyone have experience Japanese code pages? Is this something which 
needs

more detailed investigation?
Just a hunch here; but don't Japanese characters use joiners to combine 2 
utf8 symbols?

IOW shouldn't that be uft16?

Ahem... I meant utf16, not uft.

Sorry. :-/


HTH

-- Chris


kind regards,

  Fritz

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

0xBDE49540.asc
Description: application/pgp-keys
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] clamav update

[Chris]

On 2022-01-11 09:16, Friedrich Kink via oi-dev wrote:

Hi all,

I prepared the clamav update to the latest version and everything works fine 
as

expected. But one of out of all tests is failing with this error:

99%: Checks: 1175, Failures: 1, Errors: 0
/usr/src/oi-userland/components/sysutils/clamav/clamav-0.104.1/unit_tests/check_clamav.c:1707:F:assorted
functions:test_cli_codepage_to_utf8_jis:0: test_cli_codepage_to_utf8: Failed 
to

convert CODEPAGE_JAPANESE_SHIFT_JIS to UTF8: ret != SUCCESS!
NOTICE: Use the 'T' environment variable to adjust testcase timeout

 Does anyone have experience Japanese code pages? Is this something which 
needs

more detailed investigation?
Just a hunch here; but don't Japanese characters use joiners to combine 2 
utf8 symbols?

IOW shouldn't that be uft16?

HTH

-- Chris


kind regards,

  Fritz

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

0xBDE49540.asc
Description: application/pgp-keys
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] clamav update

[Friedrich Kink via oi-dev]

Hi all,

I prepared the clamav update to the latest version and everything works 
fine as expected. But one of out of all tests is failing with this error:


99%: Checks: 1175, Failures: 1, Errors: 0
/usr/src/oi-userland/components/sysutils/clamav/clamav-0.104.1/unit_tests/check_clamav.c:1707:F:assorted 
functions:test_cli_codepage_to_utf8_jis:0: test_cli_codepage_to_utf8: 
Failed to convert CODEPAGE_JAPANESE_SHIFT_JIS to UTF8: ret != SUCCESS!

NOTICE: Use the 'T' environment variable to adjust testcase timeout

 Does anyone have experience Japanese code pages? Is this something 
which needs more detailed investigation?


kind regards,

  Fritz
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] rrdtool update questions

[Friedrich Kink via oi-dev]

Hi all,

based on Andreas' comment I rebuild rrdtool exclusively 2for 64-bit. 
This added also support for all bindings lua, tcl, perl, ruby (v2.6) and 
pyhton (v3.7). Though python created some headache. It build needs an 
ugly tweak of the configure script to find the right header files. The 
issue is cause by /usr/include/pyhton3.7*m. *Both version python3.7 and 
pyhton3.7m reports back PYTHON_VERSION 3.7. Based on this return the 
PYTHON_INCLUDES is always created as /usr/include/pyhton3.7 which does 
not exist. Is this intentional (the real path is 
/usr/include/pyhton3.7m, just a warmup question ;-). But the real 
problem I have with this python binding is this error when publishing:


/usr/bin/python3.5 /usr/bin/pkglint  \
    -f /usr/share/src/myoi-userland/tools/pkglintrc 
/usr/src/myoi-userland/components/image/rrdtool/build/manifest-i386-rrdtool.depend.res

Lint engine setup...
Starting lint run...
ERROR userland.action001.2    64-bit object 
'usr/lib/python3.7/site-packages/rrdtool.cpython-37m.so' in 32-bit path
WARNING pkglint.action005.1   obsolete dependency check skipped: 
unable to find dependency pkg:/image/library/libpng16@1.6.37-2020.0.1.0 
for pkg:/image/rrdtool@1.7.2,5.11-2022.0.0.0


Is there a way to overcome this problem or should i just remove the 
python3.7 binding (basically all pathon3.x versions)? BTW phyton2.7 
would work without problem including publishing but I didn't want to 
create a dependency to this soon to be deprecated/removed version.


kind regards,

  Fritz

PS: What about failing tests? Are they just to be reported or should I 
try to fix them?
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev