Re: [oi-dev] libssh2

[Andreas Wacknitz via oi-dev]

Am 04.06.24 um 17:57 schrieb Goetz T. Fischer:

On Tue, 4 Jun 2024 11:24:28 +0200, Till Wegmüller wrote:

Hi Goetz

No that can happen if somehow your local userland-incorporation is out
of date becasue it could not update some packages.

it updated fine. my local pkg update was fine. what was out of date is the repo 
website.

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

We don't have the latest libssh2 version yet. This is the complete log
information for libssh2 in our userland repository:
╰─➤  git log|grep libssh2
    libssh2: switch to openssl-3.1
    libssh2: Update to 1.10.0
    libssh2: update to 1.9.0
    libssh2: update to 1.8.2. This fixes CVE-2019-3855
    Update libssh2 to 1.8.0
    Merge pull request #2240 from xen0l/libssh2
    Bump libssh2 to 1.7.0
    Bump libssh2 to 1.7.0
    Add REQUIRED_PACKAGES to libssh2
    Merge pull request #1714 from pyhalov/libssh2
    libssh2: update to 1.4.3, add Debian patches for CVE-2015-1782, CVE-2…
    libssh2: update to 1.4.3, add Debian patches for CVE-2015-1782,
CVE-2016-0787
    PSARC 2012/341 libssh2 version 1.4.2
    15801027 SUNBT7180403 Include libssh2 for use by libcurl
    15801027 SUNBT7180403 Include libssh2 for use by libcurl (don't use
it yet)
    PSARC 2012/341 libssh2 version 1.4.2
    15801027 SUNBT7180403 Include libssh2 for use by libcurl


And
╰─➤  pkg list -af libssh2
NAME (PUBLISHER) VERSION    IFO
library/libssh2 1.10.0-2023.0.0.2  i--

shows that in our momentary package repository only one version is
available which is not 1.11.0.
So, both information match. The problem is on your side.

Andreas

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

Re: [oi-dev] pcs problems

[Andreas Wacknitz via oi-dev]

Am 23.05.24 um 16:10 schrieb Mark Konnov:

Hi all.

I'm trying to set up pacemaker on a node and encountered the following
error log:

    ruby: No such file or directory -- /usr/lib/pcsd/ssl.rb (LoadError)

After some investigation and contacting
 the pacemaker guys, I
tried to launch the pcsd without of "-- /usr/lib/pcsd/ssl.rb" param
(edited /lib/svc/method/svc-pcs) and I see another error message:
    /lib/svc/method/svc-pcs: line 33: kill: (9901) - No such process

So for some reason the pidfile is created but when pcsd tried to
launch "stop" method the according process doesn't shows up as existing.

Environment:
    vanilla oi-20240426

Steps to reproduce:
    # useradd -d /export/home/hacluster -m hacluster
    # passwd hacluster
    # pkg install pkg:/application/cluster/pcs@0.10.1-2023.0.0.2
    # vim /usr/lib/pcsd/env
        export PCSD_DEBUG=false
        export RACK_ENV=production
        export PCSD_BIND_ADDR=

    # svcadm enable svc:/application/pcs:default

What am I doing wrong ?

--
Mark Konnov

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

Hi Mark,

You didn't do anything wrong. Alas our pcs package is broken. The
missing file ssl.rb is only a minor problem. At the moment the package
uses ruby 2.3 which is 32 bit.
Pcs tries to dynamically load 32 bit libraries we don't provide anymore
because we try to get rid of 32 bit. This can only be detected by using pcs.
So I tried to update the package to the latest 0.10.x version (0.10.18)
which supports pacemaker 2.0 while switching to ruby 3.2 and 64 bit but
got stuck by the fact that
systemd is hard coded into its configure script. Obviously we cannot
(and will not) provide systemd. So this needs to be removed from the
sources.
The fact that nobody detected the problem before showed me that we don't
have pcs users and thus I am not sure whether the needed work is worth
to spend.

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

Re: [oi-dev] OI Mate clock-applet crashes

[Andreas Wacknitz via oi-dev]

Am 03.03.24 um 14:13 schrieb Stephan Althaus:

On 3/3/24 14:10, Stephan Althaus wrote:

Hello!

My clock-applet crashes regularily.

With the latest occurence, i started /usr/libexec/mate/clock-applet
before i pressed the reload button...

Now i have a core file:

https://duedinghausen.eu/OI/core.clock-applet.gz

Maybe this part of the pstack shows the reason (?)


- thread# 1391 / lwp# 1391 [pool-clock-appl] -
 7fffaf40aa6a _lwp_kill () + a
 7fffaf39b982 raise (6) + 22
 7fffaf375128 abort () + 58
 7fffaa1eb491 _ZN9__gnu_cxx27__verbose_terminate_handlerEv.cold
() + 65
 7fffaa1e8376 _ZN10__cxxabiv111__terminateEPFvvE () + 6
 7fffaa1e83d1  ()
 7fffaa1e864c  ()
 7fff9cc2f092
_ZN23envvar_config_extension10get_configERKN8libproxy3urlE () + 4b2
 7fff9cc252d3
_ZN8libproxy13proxy_factory10get_configERNS_3urlERSt6vectorIS1_SaIS1_EERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
() + 253
 7fff9cc255a7
_ZN8libproxy13proxy_factory11get_proxiesERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
() + f7
 7fff9cc25bd2 px_proxy_factory_get_proxies () + 92


What should i do now to narrow it down what the reason is (?)

BTW i don't use any proxy settings that i know of :-/


Regards,

Stephan





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


Hello!

i forgot, this is the console output of the command:

$ /usr/libexec/mate/clock-applet

** (clock-applet:9178): WARNING **: 13:29:39.524: Call can set time
zone dbus method:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.mate.SettingsDaemon.DateTimeMechanism was not provided by any
.service files

(clock-applet:9178): Gtk-WARNING **: 13:29:39.526: Negative content
width -9 (allocation 1, extents 5x5) while allocating gadget (node
button, owner GtkToggleButton)
terminate called after throwing an instance of 'std::runtime_error'
  what():  Unable to read configuration
Abort (core dumped)

Regards,

Stephan


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

Please create a fresh account and try with it whether you'll get similar
results. It may be you personal configuration forcing this error.

Andreas

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

Re: [oi-dev] couchdb-31 is broken

[Andreas Wacknitz via oi-dev]

Am 20.02.24 um 21:21 schrieb Bill Sommerfeld via oi-dev:

On 2/20/24 12:06, Andreas Wacknitz via oi-dev wrote:

Am 20.02.24 um 20:52 schrieb Bill Sommerfeld via oi-dev:

On 2/20/24 11:27, Andreas Wacknitz via oi-dev wrote:

Am 20.02.24 um 18:49 schrieb Marcel Telka:

BTW, the issue above should be fixable by replacing a file (or
two, or
so) from the backup.


I have tried pkgrecv but it skipped the couchdb-31 package because
it's
already there.
How can I find the necessary files to copy over?


Start with the manifest file itself - that's what I believe it's
failing the checksum for.

Look inside the repo directory, in:

publisher/openindiana.org/pkg/database%2Fcouchdb-31

For
pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z


there should be a file in that directory named

3.1.2%2C5.11-2023.0.0.0%3A20230609T222502Z

that contains the package manifest.

Once a manifest file is in place that has the right checksum it may or
may not complain about other missing files.

I have checked both manfests (actual and old repo). They don't differ
and seem to be complete and thus should be correct.


Then maybe the hash for the manifest file in the repo's catalog is
wrong.  Not sure what the best way to correct it is, though.

Perhaps removing the broken package from the repo with pkgrepo remove
and then using pkgrecv to restore it it in from the old repo?

Removing packages from the repo is a little bit tedious as the repo is
served on an old zone and remove is not supported by its pkgrepo.
So I have to copy several GB to another system, remove the package
there, and copy everything back.
Maybe I find the time for it at the weekend.

Andreas


    - Bill


___
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] couchdb-31 is broken

[Andreas Wacknitz via oi-dev]

Am 20.02.24 um 20:52 schrieb Bill Sommerfeld via oi-dev:

On 2/20/24 11:27, Andreas Wacknitz via oi-dev wrote:

Am 20.02.24 um 18:49 schrieb Marcel Telka:

BTW, the issue above should be fixable by replacing a file (or two, or
so) from the backup.


I have tried pkgrecv but it skipped the couchdb-31 package because it's
already there.
How can I find the necessary files to copy over?


Start with the manifest file itself - that's what I believe it's
failing the checksum for.

Look inside the repo directory, in:

publisher/openindiana.org/pkg/database%2Fcouchdb-31

For
pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z

there should be a file in that directory named

3.1.2%2C5.11-2023.0.0.0%3A20230609T222502Z

that contains the package manifest.

Once a manifest file is in place that has the right checksum it may or
may not complain about other missing files.

I have checked both manfests (actual and old repo). They don't differ
and seem to be complete and thus should be correct.


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

Re: [oi-dev] couchdb-31 is broken

[Andreas Wacknitz via oi-dev]

Am 20.02.24 um 18:49 schrieb Marcel Telka:

On Tue, Feb 20, 2024 at 09:31:03AM -0800, Bill Sommerfeld via oi-dev wrote:

On 2/20/24 00:58, Marcel Telka wrote:

the couchdb-31 package is broken at the ips server:

Errors were encountered while attempting to retrieve package or file data for
the requested operation.
Details follow:

pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z
Invalid content: manifest hash failure: fmri: 
pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z
expected: 28185b5f27c3c0ce9ea1d8f129e0e5763f53e8ae computed: 
b371cc90d6fd42c5bafa55f85afb183b59c23960. (happened 4 times)


I tried rebuilding but it fails because our Erlang is too new:

==> config (compile)
ERROR: OTP release 24 does not match required regex 19|20|21|22
ERROR: compile failed while processing
/z/ws/oi-userland-alt/components/database/couchdb-31/build/amd64/src/config:
rebar_abort
make: *** [Makefile:125: couch] Error 1
gmake: *** [/z/ws/oi-userland-alt/make-rules/justmake.mk:62:
/z/ws/oi-userland-alt/components/database/couchdb-31/build/amd64/.built]
Error 2

We apparently need newer couchdb, since couchdb 3.1 is no longer
supported.  OTOH, we do not have any consumer for couchdb-31 in OI so we
could simply just obsolete it and do not bother packaging newer one.

BTW, the issue above should be fixable by replacing a file (or two, or
so) from the backup.


I have tried pkgrecv but it skipped the couchdb-31 package because it's
already there.
How can I find the necessary files to copy over?

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

Re: [oi-dev] Avahi daemon not happy

[Andreas Wacknitz]

Am 21.11.23 um 10:48 schrieb Udo Grabowski (IMK):

Hi,

since a recent update I see these messages from the
avahi-daemon-bridge-dsd :

Nov 21 10:42:06 imkx avahi-daemon-bridge-dsd[1709]: [ID 702911
daemon.warning] WARNING:: No NSS support for mDNS detected, consider
installing nss-mdns!
Nov 21 10:42:06 imkx avahi-daemon-bridge-dsd[1709]: [ID 702911
daemon.warning] *** WARNING:: Detected another IPv4 mDNS stack running
on this host. This makes mDNS unreliable and is thus not recommended. ***

Of course, that "other stack" is the dns/multicast service, which is
a prerequisite for the avahi-bridge-dsd service.

That message didn't appear before, but there seems a lot ongoing
for the avahi stuff, and a couple of new programs there currently
don't work. So I suspect work in progress ?


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

I don't have these warnings but my formerly working avahi doesn't work
anymore, too.
My original plan was just to rebuild avahi with gcc-13 and to drop 32
bit. Obviously I failed to create a working avahi.
We need to investigate further.

Regards
Andreas

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

Re: [oi-dev] Emacs has a bad font

[Andreas Wacknitz]

Am 08.11.23 um 16:36 schrieb Gary Mills:

I recently did an OI upgrade, on one of my systems, from 20220928 to
20231107 (more than a year).  Everthing worked normally afterwards
except for emacs.  It has a peculiar font, compared to MATE-terminal.
The font appears to be too thin.  I'm using the same font size as
before, 10 point.  What could the matter be?



If you are using the gtk variant of emacs then it relies on pango for
font rendering and layout which in case has dropped support for older
font types a couple of months ago.
So your problem might be that you are trying to use an unsupported (by
pango) font type and thus rendering results look ugly.
You might solve this be choosing a font of a supported font type, eg. a
truetype font.

Regards,
Andreas

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

Re: [oi-dev] JDK builds and crypto

[Andreas Wacknitz]

Am 11.08.23 um 16:49 schrieb Peter Tribble:

As noted on IRC, there might be issues with JDK and crypto on OpenIndiana.

The issue is that on Solaris/illumos (and only there) the jdk can
offload crypto to
the OS using the SunPKCS11 provider. That doesn't always work
correctly, there's
a flag:

-Dsun.security.pkcs11.enable-solaris=false

that just disables it so you should get the same behaviour as other
platforms.

In Tribblix I disable (in .../conf/security/sunpkcs11-solaris.cfg) the
bits that I know
don't work:

https://github.com/tribblix/build/blob/master/patches/sunpkcs11-solaris.cfg.patch

In OmniOS I think they change the preference order:

https://github.com/omniosorg/omnios-build/blob/master/build/openjdk17/patches/security-pkcs11.patch

I suggest you'll need to do one of those for the OI jdk builds too.

--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

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

Thanks Peter,

I will see whether I can motivate someone to take care of it ;-)

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

Re: [oi-dev] GDL chokes on semaphore (GraphicsMagick)

[Andreas Wacknitz]

Am 06.02.23 um 12:05 schrieb Udo Grabowski (IMK):

On 05/02/2023 23:23, Andreas Wacknitz wrote:

Am 03.02.23 um 14:25 schrieb Udo Grabowski (IMK):

On 28/01/2023 15:40, Bob Friesenhahn wrote:

On Fri, 27 Jan 2023, Udo Grabowski (IMK) wrote:


pkg:/scientific/gdl@0.9.7-2020.0.1.4 (OI hipster illumos-aa33dce46b
and older)

for user and root:
/usr/bin/gdl stops on assertion test in GraphicsMagick (semaphore.c):


With almost 100% certainty this is because the dependent program has
not invoked
InitializeMagick() before using other GraphicsMagick APIs. It is
acceptable to
invoke this function any number of times and InitializeMagick(NULL)
is OK for
dynamically linked programs.

A very long time ago (since 1.3.8 in 2010) GraphicsMagick
initialization was
changed to require InitializeMagick() to be invoked first. Before it
was just
recommended.

OpenIndiana recently stepped forward from using a very old version of
GraphicsMagick, so that may be what provoked this issue.


Indeed, the problem seems to be exactly that and has been fixed in the
1.0.2
branch in 2019 with this commit:

<https://github.com/gnudatalanguage/gdl/commit/d4045d4469f3c8fae435a4bc6b182ac8417b8461#diff-fee07a0c71823f10358bdf47d478390d>


GNU Data Language moved from sourceforge to github:
<https://github.com/gnudatalanguage/gdl>


I have updated several packages related to gdl and this package itself
today.
We don't seem to have many interested people in scientific use anymore.
I recommend that someone interested will take care for these packages in
the future.
Eg. there hasn't been a release of plplot in several years, resulting in
the optional dependency on an outdated qhull version (2015).
But there seem to be many merged commits still for plplot. Maybe they
need some friendly works to create a new release that supports qhull as
of 2020.
Furthermore gdl could make use of several small packages we don't have
yet (I have added proj because turning it off for gdl didn't work).
We need someone with more interest in this area than me.



Thanks a lot, that works now. Unfortunately, I'm neither a C or C++
programmer, so I'm just hacking and googleing here or there until it
works,

You only need very little C or C++ knowledge in order to maintain OI
packages.
What you need is a build environment (running latest OI and a clone of
our userland repository).
And some knowledge about the packages you maintain so you can test
updates or fixes and will
be able to discusss problems with upstream projects. As I mentioned
before plplot would benefit
from a new release, GDL would benefit if more packages would be
"migrated". Look at what I have done
for proj as an example. It had nothing to do with programming in any
language but configuring the build.
If you start programming you would be most certainly on a wrong path.


I've just wrestled with an old GDL 0.9.8 and nearly got it just to the
final linker step (where  it failed by some namespace issues). As a
scientist, my daily work horses are (of course) Fortran 90, IDL
(here as GDL) for the plotting, and Perl for hacking all the ugly
management stuff. As Python for the younger staff seems to be important
(and I still don't know why...), I also got a Sun Studio CC compiled
numpy running under (old) Python, which seems to be currently missing
(and I guess
that the hurdles I stumbled over are still there...). So I can test stuff
and give some hints here or there, but have no capacity to take over
whole packages and their dependencies. As I'm currently updating all
our stuff to current Hipster, there may will be the one or other
package to build that can also be useful for OI. Maybe I should set up
my own package depot for that stuff, so that integration into OI
could be readily done from there.

If you clone the oi-userland repository and run "gmake setup" inside
you'll get your own repository.
You can always supplement this with your own pkg depot but that's not
necessary if you have file access to the repository clone.
http://docs.openindiana.org/dev/userland/ should provide you with all
the necessary information to get started.
And of course concrete questions are always welcome on our mailing lists.


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

Re: [oi-dev] GDL chokes on semaphore (GraphicsMagick)

[Andreas Wacknitz]

Am 05.02.23 um 23:23 schrieb Andreas Wacknitz:

Am 03.02.23 um 14:25 schrieb Udo Grabowski (IMK):

On 28/01/2023 15:40, Bob Friesenhahn wrote:

On Fri, 27 Jan 2023, Udo Grabowski (IMK) wrote:


pkg:/scientific/gdl@0.9.7-2020.0.1.4 (OI hipster illumos-aa33dce46b
and older)

for user and root:
/usr/bin/gdl stops on assertion test in GraphicsMagick (semaphore.c):


With almost 100% certainty this is because the dependent program has
not invoked
InitializeMagick() before using other GraphicsMagick APIs. It is
acceptable to
invoke this function any number of times and InitializeMagick(NULL)
is OK for
dynamically linked programs.

A very long time ago (since 1.3.8 in 2010) GraphicsMagick
initialization was
changed to require InitializeMagick() to be invoked first. Before it
was just
recommended.

OpenIndiana recently stepped forward from using a very old version of
GraphicsMagick, so that may be what provoked this issue.


Indeed, the problem seems to be exactly that and has been fixed in the
1.0.2
branch in 2019 with this commit:

<https://github.com/gnudatalanguage/gdl/commit/d4045d4469f3c8fae435a4bc6b182ac8417b8461#diff-fee07a0c71823f10358bdf47d478390d>



GNU Data Language moved from sourceforge to github:
<https://github.com/gnudatalanguage/gdl>

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

I have updated several packages related to gdl and this package itself
today.
We don't seem to have many interested people in scientific use anymore.
I recommend that someone interested will take care for these packages in
the future.
Eg. there hasn't been a release of plplot in several years, resulting in
the optional dependency on an outdated qhull version (2015).
But there seem to be many merged commits still for plplot. Maybe they
need some friendly works to create a new release that supports qhull as

s/works/words/


of 2020.
Furthermore gdl could make use of several small packages we don't have
yet (I have added proj because turning it off for gdl didn't work).
We need someone with more interest in this area than me.

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] $WS_TOOLS/python-integrate-project

[Andreas Wacknitz]

Am 28.11.22 um 17:16 schrieb Nona Hansel:

Hello,

I've seen in several Makefiles saying they have been automatically
generated using this command
$WS_TOOLS/python-integrate-project name_of_the_component

However, updating texttable, I ran
$WS_TOOLS/python-integrate-project texttable
in oi-userland/components/python/texttable directory or in
oi-userland/ and got this mesage:
-bash: /python-integrate-project: No such file or directory

You'll need to set WS_TOOLS appropriate for your environment. The tools
folder is named tools and is located below the repository's top level
folder.
Thus, in my environment I would need to set
WS_TOOLS=/export/home/andreas/oi-userland/tools; export WS_TOOLS
Because in your case WS_TOOLS is not yet set, you'll get this error message.

Regards,
Andreas

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

Re: [oi-dev] Error message after gmake test

[Andreas Wacknitz]

Am 07.11.22 um 15:33 schrieb Nona Hansel:

Hello,

it's been a while since I last contributed to OI (not counting
yesterday's straight forward sudo update). Today I'm trying to update
sed. When I run gmake test, I get this message:

make[1]: Leaving directory
'/export/home/nona/oi-userland/components/text/sed/build/amd64'
/usr/bin/touch
/export/home/nona/oi-userland/components/text/sed/build/amd64/.built
/bin/rm -f -rf
/export/home/nona/oi-userland/components/text/sed/build/test/amd64
/bin/mkdir -p
/export/home/nona/oi-userland/components/text/sed/build/test/amd64
(cd /export/home/nona/oi-userland/components/text/sed/build/amd64 ; \
    /usr/bin/env  \
    /usr/gnu/bin/make \
     check) \
    &>
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/test-64-results
print "#!/bin/sh" >
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/transform-64-results;
print '/bin/cat
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/test-64-results
| \\' >>
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/transform-64-results;
print '/usr/gnu/bin/sed ' '-e
"s|/export/home/nona/oi-userland/components/text/sed/build/amd64|\\$(@D)|g"
' '-e "s|/usr/perl5/5.36/bin/perl|\\$(PERL)|g" ' '-e
"s|/export/home/nona/oi-userland/components/text/sed/sed-4.9|\\$(SOURCE_DIR)|g"
' "-e 's|/usr/lib/python3.9|\$(PYTHON_DIR)|g'" '-n ' '-e "/TOTAL/p" '
'-e "/SKIP/p" ' '-e "/PASS/p" ' '-e "/FAIL/p" ' '-e "/ERROR/p" ' ' \\'
>>
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/transform-64-results;
print '>
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/results-64.snapshot'
>>
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/transform-64-results;

/bin/bash
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/transform-64-results;

[ -e
/export/home/nona/oi-userland/components/text/sed/test/results-all.master
] || exit 1; /usr/gnu/bin/diff -uNb
/export/home/nona/oi-userland/components/text/sed/test/results-all.master
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/results-64.snapshot
>
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/test-64-diffs;
print "Test results in
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/test-64-results";
if [ -s
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/test-64-diffs
]; then print "Differences found."; /bin/cat
/export/home/nona/oi-userland/components/text/sed/build/test/amd64/test-64-diffs;
exit 2; else print "No differences found."; fi
gmake: *** [/export/home/nona/oi-userland/make-rules/configure.mk:210:
/export/home/nona/oi-userland/components/text/sed/build/amd64/.tested-and-compared]
Error 1

It confuses me. From the files build/test/amd64/results-64.snapshot
and build/test/amd64/test-64-results I can see that the tests ran fine
and mostly passed with a few skipped.

I copied the contents of build/test/amd64/results-64.snapshot into
test/results-64.master because I thought that the build system would
compare those files, yet I get the above message.


We have a new default to results-all.master. You'll have to either
rename your results-64.master file to results-all.master or set
USE_COMMON_TEST_MASTER= no in the Makefile.

Regards,
Andreas


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

Re: [oi-dev] slim_source rebuild

[Andreas Wacknitz]

I have manually re-run gmake publish for it and after the next jenkins
build had finished (thunderbird update) the new packages should also be
available now.

Regards,
Andreas

Am 04.11.22 um 14:24 schrieb Marcel Telka:

Hi Andreas,

I noticed we do miss the slim_source rebuild after the PR #70 (Switch to Python
3.9) merge: https://github.com/OpenIndiana/slim_source/pull/70

It was merged on 2022-09-24, but the latest (re)build of slim_source is from
2022-09-17:

# pkg list -afv system/install
FMRI IFO
pkg://openindiana.org/system/install@0.5.11-2022.0.0.1061:20220917T092724Z   i--
#


Could you please look at it?  Is change in
components/openindiana/slim_source/Makefile needed to make the slim_source
automatically rebuilt by jenkins?


Thank you.



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

Re: [oi-dev] libstdc++.so version

[Andreas Wacknitz]

Am 14.09.22 um 17:34 schrieb Marcel Telka:

On Wed, Sep 14, 2022 at 05:17:05PM +0200, Andreas Wacknitz wrote:

Am 14.09.22 um 16:49 schrieb Alexander Jung:

Hello,

what version of libstdc++.so should be in current OI under
/usr/lib/amd64 ?


None. libstdc++.so are under /usr/gcc//lib/ (32 bit) and
/usr/gcc//lib/amd64/ (64 bit), eg.
/usr/gcc/10/lib/amd64/libstdc++.so.

... with one exception: system/library/g++-4-runtime

# pkg contents -r system/library/g++-4-runtime | grep libstdc++
usr/lib/amd64/libstdc++.so
usr/lib/amd64/libstdc++.so.6
usr/lib/amd64/libstdc++.so.6.0.20
usr/lib/libstdc++.so
usr/lib/libstdc++.so.6
usr/lib/libstdc++.so.6.0.20
#


Yes, I sometimes forget about this old version. I want to get rid of it
but alas rustup is using this version.

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

Re: [oi-dev] libstdc++.so version

[Andreas Wacknitz]

Am 14.09.22 um 16:49 schrieb Alexander Jung:


Hello,

what version of libstdc++.so should be in current OI under
/usr/lib/amd64 ?


None. libstdc++.so are under /usr/gcc//lib/ (32 bit) and
/usr/gcc//lib/amd64/ (64 bit), eg.
/usr/gcc/10/lib/amd64/libstdc++.so.

Andreas



Best regards,
Alex

--
*s c i ls e t*
Alexander Jung
Sohlberg 5
77883 Ottenhöfen

*MOBIL:* (0 17 6) 47 16 6195
*E-MAIL:* a.j...@scilset.de 
*INTERNET:* www.scilset.de 

___
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] Perl 5.34

[Andreas Wacknitz]

Am 30.06.22 um 16:14 schrieb Gordon Ross:

After a "pkg image-update" today I see complaints from intrd that it
can't find these perl modules:

Can't locate Sun/Solaris/Kstat.pm in @INC (you may need to install the
Sun::Solaris::Kstat module) (@INC contains:
/usr/perl5/site_perl/5.34/i86pc-solaris-thread-multi-64
/usr/perl5/site_perl/5.34
/usr/perl5/vendor_perl/5.34/i86pc-solaris-thread-multi-64
/usr/perl5/vendor_perl/5.34
/usr/perl5/5.34/lib/i86pc-solaris-thread-multi-64 /usr/perl5/5.34/lib)
at /usr/lib/intrd line 66.

Did I miss a step?  I looked for a "heads up" but don't see any
relevant instructions.

Thanks

On Sat, Mar 12, 2022 at 2:53 PM Tim Mooney via oi-dev
 wrote:

In regard to: [oi-dev] Perl 5.34, Klaus Ziegler said (at 11:36am on Mar 12,...:


Hi Team,

it's now quite some time ago, since Tim Mooney has provided the
new perl version 5.34 to oi-userland.
Unfortunately it is still not used for new projects/components, see
postgres-14 :-( , I'm nearly done removing perl versions: 5.22, 5.24
from oi-userland on SPARC. During this process I modified more than
50 components and noted the changes, I will do my best to get all
these #PRs submitted asap,

Those patches are welcome.

I had hoped that the right set of steps to just switch OI to perl 5.34
would be more straightforward, but they really haven't been.

It hasn't helped that I've been very busy with projects for the past
couple months.

One thing that would help would be if someone could confirm whether the
build errors I see for illumos-gate with

 https://github.com/OpenIndiana/oi-userland/pull/7733

occur for others too, or if it's something specific to my environment.
Considering how long it takes me to rebuild illumos-gate in my VM build
environment every time I test, it's been time-consuming to even get to
that point.

Note that the removal of 5.22 is also tied to the process to obsolete
32 bit end-user components, at least for things that link to perl.  As
we make progress on that project, removing 5.22 becomes a little easier.

Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure /
Division of Information Technology/701-231-1076 (Voice)
North Dakota State University, Fargo, ND 58105-5164

___
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

You didn't miss a step. The actual problems are due a failed
illumos-gate build tonight.
We need to fix it and rerun the jenkins job. This will pronably take
another 3 to 4 hours.

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

Re: [oi-dev] problems publishing rust

[Andreas Wacknitz]

Am 20.06.22 um 21:18 schrieb Friedrich Kink via oi-dev:

Hi Till,

thanks a lot this is indeed a very valuable hint. Unfortunately since
a couple of compile runs installation fails at the very end with the
following error:

...

Install analysis stage2 (Some(TargetSelection { triple:
"x86_64-unknown-illumos", file: None }))
install: creating uninstall script at
/usr/src/myoi-userland/components/developer/rust/build/prototype/i386/usr/lib/rustlib/uninstall.sh
install: installing component 'rust-analysis-x86_64-unknown-illumos'

    rust analysis installed.

Dist rust-src-1.61.0
Error: failed to generate installer

Caused by:
    0: failed to tar file
'/usr/share/src/myoi-userland/components/developer/rust/build/amd64/build/tmp/tarball/rust-src/rust-src-1.61.0/rust-src/lib/rustlib/src/rust/library/portable-simd/LICENSE-APACHE'
    1: provided value is too long when setting link name for

We already had another guy trying to build a newer rust failing with the
same problem.
He found out that this is a known problem and there should already be a
fix (as far as I understood) but it hadn't been integrated in the release.
It looks like the situation didn't change in the last weeks.




Stack backtrace:
   0: >::from
   1:
installer::tarballer::append_path::>>
   2:
::install::<::run::{closure#2},
core::result::Result<(), anyhow::Error>>::{closure#0}
   3:
 as rayon_core::job::Job>::execute::call,
::in_worker_cold<::install<::run::{closure#2},
core::result::Result<(), anyhow::Error>>::{closure#0},
core::result::Result<(),
anyhow::Error>>::{closure#0}::{closure#0}>::{closure#0}> as
core::ops::function::FnOnce<()>>::call_once
   4: ::in_worker_cold<::install<::run::{closure#2},
core::result::Result<(), anyhow::Error>>::{closure#0},
core::result::Result<(), anyhow::Error>>::{closure#0}::{closure#0},
core::result::Result<(), anyhow::Error>> as
rayon_core::job::Job>::execute
   5: ::wait_until_cold
   6: ::run
   7:
std::sys_common::backtrace::__rust_begin_short_backtrace::<::spawn::{closure#0}, ()>
   8:
<::spawn_unchecked_<::spawn::{closure#0},
()>::{closure#1} as
core::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
   9:  as
core::ops::function::FnOnce>::call_once
 at
/rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/alloc/src/boxed.rs:1861:9
  10:  as
core::ops::function::FnOnce>::call_once
 at
/rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/alloc/src/boxed.rs:1861:9
  11: std::sys::unix::thread::Thread::new::thread_start
 at
/rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys/unix/thread.rs:108:17
  12: _thrp_setup
  13: 
Build completed unsuccessfully in 0:26:51
make: *** [/usr/share/src/myoi-userland/make-rules/configure.mk:195:
/usr/src/myoi-userland/components/developer/rust/build/amd64/.installed]
Error 1

to me a the path length looks still ok (< 256). So any one any idea? I
don't know why it happens all of a sudden as I changed nothing basic
to the environment.

kind regards,

  Fritz

Am 20.06.2022 um 15:23 schrieb Till Wegmueller:

Hey Fritz

That must be a syntax error in the Makefile. The resolver logic is
built into OI-userland and should not get impacted by modifications
to Makefile of a component. However for some reason 'RESOLVE_DEPS='
leaks into the final filepath. That should not happen.

Looking at you Makefile I think the culprit are the lines after
'#COMPONENT_POST_INSTALL_ACTION= \' IIRC they need to be commented
out too as they have a backslash thus parsing weirdness starts to
happen.

Hope this helps
Greetings
Till

On 19/06/2022 06.05, Friedrich Kink via oi-dev wrote:

Thanks a lot for your response. Let me give some more information.
This patch helped me to over come your issue:

--- rustc-1.61.0-src/src/bootstrap/builder.rs   2022-05-18
03:29:36.0 +
+++ rustc-1.61.0-src/src/bootstrap/builder.rs.new 2022-06-06
21:25:45.179276851 +
@@ -1304,7 +1304,7 @@
  Some("-Wl,-rpath,@loader_path/../lib")
  } else if !target.contains("windows") {
  rustflags.arg("-Clink-args=-Wl,-z,origin");
-    Some("-Wl,-rpath,$ORIGIN/../lib")
+   Some("-Wl,-rpath,/usr/clang/13.0/lib")
  } else {
  None
  };

Also I already use rustup (as suggested by Joshua, too) and this is
my current Makefile (as metioned it gets compiled and installed but
make REQUIRED_PACKAGES|publish stops immediately):

BUILD_BITS= 64
USE_OPENSSL11=  yes

include ../../../make-rules/shared-macros.mk

COMPONENT_NAME= rustc
COMPONENT_VERSION=  1.61.0
COMPONENT_FMRI= developer/lang/rustc
COMPONENT_SUMMARY=  Rust - Safe, concurrent, practical language
COMPONENT_CLASSIFICATION=   Development/Other Languages
COMPONENT_PROJECT_URL=  http://www.rust-lang.org
COMPONENT_SRC= $(COMPONENT_NAME)-$(COMPONENT_VERSION)-src
COMPONENT_ARCHIVE=  $(COMPONENT_SRC).tar.gz
COMPONENT_ARCHIVE_HASH=

Re: [oi-dev] oi-dev Digest, Vol 141, Issue 7

[Andreas Wacknitz]

Am 29.05.22 um 14:47 schrieb Klaus Elsbernd:

If someone is out there:

since system/filesystem/usr:default "Completes a dependency cycle",
the internet gave me the hint to look at /var/adm/messages

I think, I've found the problem, but not the solution:

/var/adm/messages shows:

nfsv4cbd... I[D 867284 daemon.notice] nfsv4 cannot determine local
hostname binding for transport tcp6 . delegations will not be
available on this transport.

We disabled tcpv6 on the network. From /etc/hosts:

#::1 localhost

Am I on the right path?

Klaus


We have problems with our install media that run into a service
dependency circle after svc:/network/varpd:default has been provided by
illumos-gate.
You may check whether its enabled with "svcs varpd" and if so disable it.
This problem still prohibits the release of new install media.

Andreas

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

Re: [oi-dev] VLC maintainer ?

[Andreas Wacknitz]

Am 01.05.22 um 14:42 schrieb s...@pandora.be:

I'm a user of the VLC media player on OpenIndiana;

I've noticed that the videolan.org website lists 3.0.17.4 as the latest 
version, while OpenIndiana delivers 3.0.16.

Assuming that there is currently no OI maintainer for VLC, I'm creating a PR 
(pull request) to update to 3.0.17.4,
although obviously if the current VLC maintainer would like to continue work on 
this package,
that is not a problem of course.

Regards,
David Stes

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

Everybody is free (and welcomed) to create PR's for every package in
oi-userland.
You should at least test it in your environment and write about how you
tested it in the PR's.
You should also check whether other packages are effected by an upgrade
and provide one or more helper PR's with rebuilds if needed.
Note that we cannot have upgrades and rebuilds of effected packages in
the same PR because that's how our build server works.
An update is not available before the build and deployment succeeded.
Thus, we need separate PR's for the upgrade of one package and a second
PR for its dependent packages.

Andreas

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

Re: [oi-dev] What changed between glib versions?

[Andreas Wacknitz]

Am 4/1/22 um 19:42 schrieb s...@pandora.be:

In this case the '0.0.1' in "glib2@2.70.0,5.11-2022.0.0.1" is important.

I guess there are users who expect USB keyboard and mouse hotplug to work
or USB storage automount so for those users it be an unpleasant experience of 
OpenIndiana if that does not work.

 From that perspective it may make sense to stay on glib 2.62 as long as this 
complex issue is not further debugged or understood.


You are right, but we need people working on it.

At the moment I am fighting with many problems, like we cannot build
firefox or thunderbird anymore for unknown reasons (also on my build
systems).
More important, the build server is not able to successfully build
illiumos-gate packages anymore. It stopped recently. This is local to
our build server,
because I can successfully build the illumos-gate packages.

An finally the distribution constructor on the build server hasn't been
able to produce working media. I successfully build media in February,
but my March attempts all fail.




Regards
David Stes

- Op 1 apr 2022 om 19:34 schreef Andreas Wacknitz a.wackn...@gmx.de:


Am 01.04.22 um 19:31 schrieb s...@pandora.be:

So this new upgrade is again in fact a downgrade or regression to

https://download.gnome.org/sources/glib/2.62/glib-2.62.6.tar.xz

In any case now the rmvolmgr rmmount seems to work (again) for me ...

Yes, I downgraded it again after your report. Also my system didn't work
anymore as expected after the latest illumos-gate updates.
As I have stated in another mail, I also have problems with this
version, only less often.


Regards
David Stes


- Op 1 apr 2022 om 19:25 schreef Andreas Wacknitz a.wackn...@gmx.de:


Am 01.04.22 um 19:00 schrieb s...@pandora.be:

Good news ! I can update https://www.illumos.org/issues/14226 again ...

But this time to report success.

There was an update of "media-volume-manager" which now has glib2 2.70 as a
require.

# rmmount -l and # eject -l  report the removable media.

I just tried to insert a USB key in my system and it automounts immediately on
my OI workstation.

# pkg list media-volume-manager hal glib2 dbus
NAME (PUBLISHER)  VERSIONIFO
library/glib2 2.70.0-2022.0.0.1  i--

This is the fake glib-2.70.0 version. You can check it with pkg info
glib2. It will show you which sources have been used to create it...


service/hal   0.5.11-2022.0.0.21026  i--
service/storage/media-volume-manager  0.5.11-2022.0.0.21026  i--
system/library/dbus   1.12.20-2020.0.1.1 i--

# pkg contents -t depend media-volume-manager
TYPEFMRI
require pkg:/system/library/libdbus-glib@0.112-2022.0.0.0
require pkg:/shell/ksh93@93.21.1.20120801-2022.0.0.21026
require pkg:/library/glib2@2.70.0-2022.0.0.0
require pkg:/SUNWcs@0.5.11-2022.0.0.21026
require pkg:/service/hal@0.5.11-2022.0.0.21026
require pkg:/system/library/libdbus@1.12.20-2020.0.1.1
require pkg:/service/storage/removable-media@0.5.11-2022.0.0.21026
require pkg:/system/library@0.5.11-2022.0.0.21026
require pkg:/system/library/dbus@1.12.20-2020.0.1.1
require consolidation/osnet/osnet-incorporation


Perhaps some of the packages involved  (I suspect "media-volume-manager") was
not the right version.

When debugging this there seems to be a command :

  dbus-monitor --session

that can be used to follow what is going on.

Regards,
David Stes

___
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

___
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

___
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] What changed between glib versions?

[Andreas Wacknitz]

Am 01.04.22 um 19:31 schrieb s...@pandora.be:

So this new upgrade is again in fact a downgrade or regression to

https://download.gnome.org/sources/glib/2.62/glib-2.62.6.tar.xz

In any case now the rmvolmgr rmmount seems to work (again) for me ...

Yes, I downgraded it again after your report. Also my system didn't work
anymore as expected after the latest illumos-gate updates.
As I have stated in another mail, I also have problems with this
version, only less often.



Regards
David Stes


- Op 1 apr 2022 om 19:25 schreef Andreas Wacknitz a.wackn...@gmx.de:


Am 01.04.22 um 19:00 schrieb s...@pandora.be:

Good news ! I can update https://www.illumos.org/issues/14226 again ...

But this time to report success.

There was an update of "media-volume-manager" which now has glib2 2.70 as a
require.

# rmmount -l and # eject -l  report the removable media.

I just tried to insert a USB key in my system and it automounts immediately on
my OI workstation.

# pkg list media-volume-manager hal glib2 dbus
NAME (PUBLISHER)  VERSIONIFO
library/glib2 2.70.0-2022.0.0.1  i--

This is the fake glib-2.70.0 version. You can check it with pkg info
glib2. It will show you which sources have been used to create it...


service/hal   0.5.11-2022.0.0.21026  i--
service/storage/media-volume-manager  0.5.11-2022.0.0.21026  i--
system/library/dbus   1.12.20-2020.0.1.1 i--

# pkg contents -t depend media-volume-manager
TYPEFMRI
require pkg:/system/library/libdbus-glib@0.112-2022.0.0.0
require pkg:/shell/ksh93@93.21.1.20120801-2022.0.0.21026
require pkg:/library/glib2@2.70.0-2022.0.0.0
require pkg:/SUNWcs@0.5.11-2022.0.0.21026
require pkg:/service/hal@0.5.11-2022.0.0.21026
require pkg:/system/library/libdbus@1.12.20-2020.0.1.1
require pkg:/service/storage/removable-media@0.5.11-2022.0.0.21026
require pkg:/system/library@0.5.11-2022.0.0.21026
require pkg:/system/library/dbus@1.12.20-2020.0.1.1
require consolidation/osnet/osnet-incorporation


Perhaps some of the packages involved  (I suspect "media-volume-manager") was
not the right version.

When debugging this there seems to be a command :

 dbus-monitor --session

that can be used to follow what is going on.

Regards,
David Stes

___
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

___
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] What changed between glib versions?

[Andreas Wacknitz]

Am 01.04.22 um 19:00 schrieb s...@pandora.be:

Good news ! I can update https://www.illumos.org/issues/14226 again ...

But this time to report success.

There was an update of "media-volume-manager" which now has glib2 2.70 as a 
require.

# rmmount -l and # eject -l  report the removable media.

I just tried to insert a USB key in my system and it automounts immediately on 
my OI workstation.

# pkg list media-volume-manager hal glib2 dbus
NAME (PUBLISHER)  VERSIONIFO
library/glib2 2.70.0-2022.0.0.1  i--

This is the fake glib-2.70.0 version. You can check it with pkg info
glib2. It will show you which sources have been used to create it...


service/hal   0.5.11-2022.0.0.21026  i--
service/storage/media-volume-manager  0.5.11-2022.0.0.21026  i--
system/library/dbus   1.12.20-2020.0.1.1 i--

# pkg contents -t depend media-volume-manager
TYPEFMRI
require pkg:/system/library/libdbus-glib@0.112-2022.0.0.0
require pkg:/shell/ksh93@93.21.1.20120801-2022.0.0.21026
require pkg:/library/glib2@2.70.0-2022.0.0.0
require pkg:/SUNWcs@0.5.11-2022.0.0.21026
require pkg:/service/hal@0.5.11-2022.0.0.21026
require pkg:/system/library/libdbus@1.12.20-2020.0.1.1
require pkg:/service/storage/removable-media@0.5.11-2022.0.0.21026
require pkg:/system/library@0.5.11-2022.0.0.21026
require pkg:/system/library/dbus@1.12.20-2020.0.1.1
require consolidation/osnet/osnet-incorporation


Perhaps some of the packages involved  (I suspect "media-volume-manager") was 
not the right version.

When debugging this there seems to be a command :

dbus-monitor --session

that can be used to follow what is going on.

Regards,
David Stes

___
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] What changed between glib versions?

[Andreas Wacknitz]

Am 31.03.22 um 17:58 schrieb Gary Mills:

We now know which glib versions allow USB automounts and which fail
to do so.  The question is: what has changed between these versions?

In my experience this is not fully accurate. I have USB devices
(Logitech mouse and data sticks) that work sometimes.
Funnily, another keyboard/mouse combo from Logitech works reliably with
glib-2.62.6, but another mouse (Performance MX) can even be lost without
unplugging it by
just plugging in another USB device (data stick). My two sticks
sometimes work and sometimes not. This seems to be a timing problem.

My USB devices worked with glib-2.70.0 with illumos-gate from about
three or four days ago but with the latest versions they don't seem to
work anymore.
So, this might also be a subtle timing problem.


The bug itself is probably not in glib at all, but knowing what code
has changed would at least put us on the right track.

In the process of doing an automount, hal calls the function
g_io_channel_read_line() within glib.  That function in turn calls the
function g_io_channel_read_line_backend() to do the actual work.

The function g_io_channel_read_line_backend() in turn calls the
function g_io_channel_fill_buffer().

Any change in any of these functions is suspect.  As far as I can tell
by reading the code, these functions are behaving as documented.
However, they may no longer be compatible with the operation expected
by hal.  The compiler, or optimizer, may also be responsible.





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

Re: [oi-dev] The end of python-27

[Andreas Wacknitz]

Am 24.03.22 um 16:51 schrieb Gary Mills:

As some of you may know, Nona and I have been working through a list
of packages that depend on python-27 .  The list was originally
published by Aurlien Larcher, with a view to the removal of python-27
from OI.

With the integration of PR #7942, there are only two remaining
packages:

 developer/gnome/gnome-doc-utils
 image/editor/gimp

I don't consider removing gimp an option, even if only temporarily. It's
an important package.
We should keep python-2.7 for it and gnome-doc-utils but remove all
other python-2 relics and dependencies.


In both of these cases, python-2 is deeply embedded in the product,
and the upstream developers have not completed the conversion to
python-3 .  Unless the conversion happens very soon, we have little
choice but to obsolete these two packages, and revive them later when
the conversion is ready.  If anyone has a better alternative, please
let us know.





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

Re: [oi-dev] Mount of USB stick now succeeds

[Andreas Wacknitz]

Am 22.03.22 um 22:41 schrieb Gary Mills:

I'm pleased to report that automount of a USB stick now succeeds under
OI on one of my systems.  I upgraded from hipster-20210514 to
hipster-20220322, and after the reboot it started working.

I assume it was the backport of glib that fixed the problem, although
I still believe the bug is actually in hal .  My guess is that the the

Yes, I downgraded to glib-2.62.6 (as fake 2.66.8). Solaris-userland is
at glib-2.70 so they seem to have fixed either hal or glib.


version of hal in illumos is not compatible with the current version
of glib.





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

Re: [oi-dev] Telegram libtdjson.so.1.8.0

[Andreas Wacknitz]

Am 22.03.22 um 20:17 schrieb s...@pandora.be:

I tested a build of Telegram (the messaging and chat software) and tdlib seems 
to build using gcc-11 on the latest OI/Hipster.

I'm not sure what a good name for this package or component could be, but 
'library/libtdjson' is perhaps a good name;

I am not related or affiliated to Telegram in any way, I only built the 
open-source library.

for a Smalltalk Squeak project I tested , this requires an external library 
called tdlib to access the Telegram API,
and it seems to work.  The squeak project also uses a Smalltalk implementation 
of JSON (javascript object notation),
supporting JSON in Smalltalk-80.

This is just the library for the API, not the Telegram-desktop (the GUI).

The build that works for me is for version 1.8.0 (latest version)  
libtdjson.so.1.8.0

In fact the Smalltalk Squeak project is using the API to provide a GUI 
(graphical userinterface) in Squeak for Telegram messages, so it is a 
Smalltalk-80 graphical user interface for Telegram that uses this library.

Note that the files are big and the build runs out of memory for me using 
gcc-7.  Using gcc-11 (64bit?) the build completes.

This requires commenting out the GCC_VERSION=7 in the 
make-rules/shared-macros.mk and setting

Don't change make-rules/shared-macros.mk arbitrarily. For single
packages you can simply use
GCC_VERSION=11
in the package's Makefile overriding the default.




GCC_VERSION=11

in the Makefile.   I'm not sure whether any packages are accepted that are 
built with gcc-11 right now.

Regards,
David Stes

___
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] samba package needs a maintainer

[Andreas Wacknitz]

Am 15.03.22 um 14:51 schrieb Stephan Althaus:

On 3/15/22 14:23, Andreas Wacknitz wrote:

Hi all,

our samba package doesn't build at the moment. It fails in the 64-bit
part probably because of a missing flag.
Alas this prevents for fixing man page collisions that have been
introduced by an update of illumogs-gate (IPD4).

I have stopped our nightly illumos-gate builds at rhe moment because of
this but we need to find a solution for it soon.
When the jenkins job will be ra-activated before we have a solution
either everybody needs to uninstall samba or we need to obsolete the
samba package.

Short: We need to find a maintainer for the samba package otherwise it's
doomed for OI.

Regards,
Andreas


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


Hello!

I gave it a try. It seems some symbols are "lost" ;-)


[2687/3948] Linking bin/default/librpc/tools/ndrdump
Undefined            first referenced
 symbol              in file
__gmpn_sec_powm_itch    /usr/lib/amd64/libhogweed.so.5
__gmpn_sec_invert   /usr/lib/amd64/libhogweed.so.5
__gmpz_limbs_write  /usr/lib/amd64/libgnutls.so
__gmpn_sec_div_r_itch   /usr/lib/amd64/libhogweed.so.5
__gmpz_limbs_finish /usr/lib/amd64/libgnutls.so
__gmpn_sec_invert_itch  /usr/lib/amd64/libhogweed.so.5
__gmpz_limbs_modify /usr/lib/amd64/libgnutls.so
__gmpn_sec_powm /usr/lib/amd64/libhogweed.so.5
__gmpn_sec_add_1_itch   /usr/lib/amd64/libhogweed.so.5
__gmpn_sec_mul_itch /usr/lib/amd64/libhogweed.so.5
__gmpz_roinit_n /usr/lib/amd64/libgnutls.so
__gmpn_sec_mul  /usr/lib/amd64/libhogweed.so.5
__gmpn_sec_add_1    /usr/lib/amd64/libhogweed.so.5
__gmpn_sec_div_r    /usr/lib/amd64/libhogweed.so.5
__gmpn_cnd_sub_n    /usr/lib/amd64/libgnutls.so
__gmpn_cnd_add_n    /usr/lib/amd64/libgnutls.so
__gmpz_limbs_read   /usr/lib/amd64/libgnutls.so
ld: fatal: symbol referencing errors. No output written t


Anyone 'knows' some of these and has a hint ?

Greetings,

Stephan


That's not the problem I have on my build machine:
Undefined            first referenced
 symbol              in file
set_field_buffer source3/utils/regedit_dialog.c.39.o
set_form_win source3/utils/regedit_dialog.c.39.o
set_form_sub source3/utils/regedit_dialog.c.39.o
field_buffer source3/utils/regedit_dialog.c.39.o
set_current_field source3/utils/regedit_dialog.c.39.o
form_driver source3/utils/regedit_dialog.c.39.o
post_form source3/utils/regedit_dialog.c.39.o
unpost_form source3/utils/regedit_dialog.c.39.o
free_field source3/utils/regedit_dialog.c.39.o
free_form source3/utils/regedit_dialog.c.39.o
dynamic_field_info source3/utils/regedit_dialog.c.39.o
new_form source3/utils/regedit_dialog.c.39.o
pos_form_cursor source3/utils/regedit_dialog.c.39.o
new_field source3/utils/regedit_dialog.c.39.o
set_field_back source3/utils/regedit_dialog.c.39.o
set_field_opts source3/utils/regedit_dialog.c.39.o
ld: fatal: symbol referencing errors. No output written to
/export/home/andreas/oi-userland/components/network/samba/build/amd64/bin/default/source3/utils/samba-regedit
collect2: error: ld returned 1 exit status

This looks more like a missing -lcurses (or a misdetection of ncurses
vs. curses). Yours might be another problem or one that's just with your
configuration.

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

[oi-dev] samba package needs a maintainer

[Andreas Wacknitz]

Hi all,

our samba package doesn't build at the moment. It fails in the 64-bit
part probably because of a missing flag.
Alas this prevents for fixing man page collisions that have been
introduced by an update of illumogs-gate (IPD4).

I have stopped our nightly illumos-gate builds at rhe moment because of
this but we need to find a solution for it soon.
When the jenkins job will be ra-activated before we have a solution
either everybody needs to uninstall samba or we need to obsolete the
samba package.

Short: We need to find a maintainer for the samba package otherwise it's
doomed for OI.

Regards,
Andreas


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

[oi-dev] Future of PostgreSQL on OpenIndiana

[Andreas Wacknitz]

Hi all,

at the moment PostgreSQL 9.6 is our version that is being used for all
packages that need PostgreSQL. This version is not supported upstream
for some months now. The oldest supported version is 10 and this would
be the obvious new version to use for us.
Alas, obsoleting a PostgreSQL version in OpenIndiana means some work to
be done and it looks like nobody is interested enough to do this work
regularly.

So, my question is how we should proceed with PostgreSQL. Obsoleting 9.6
and using 10 as our default would mean that in less than 9 months
according to https://www.postgresql.org/support/versioning/ we will need
to touch PostgreSQL again. We will need a volunteer to do this or we
might think about skipping some versions of PostgreSQL now.

What is your opinion?

Andreas


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

Re: [oi-dev] problems dependency checks

[Andreas Wacknitz]

Am 22.02.22 um 22:13 schrieb Stephan Althaus:

On 12/30/21 23:33, Gary Mills wrote:

On Thu, Dec 30, 2021 at 09:08:31PM +0100, Friedrich Kink via oi-dev
wrote:

    I've some packages (clamav update to latest version and dovecot)
I'd
    like to commit but dependency check fails:


[...]

    mav-clamdtop.depend has unresolved dependency '
    depend type=require fmri=__TBD
pkg.debug.depend.file=libclamav.so.9
    \
    pkg.debug.depend.reason=usr/bin/clamdtop
    pkg.debug.depend.type=elf \
    pkg.debug.depend.path=lib \
    pkg.debug.depend.path=usr/gcc/7/lib \
    pkg.debug.depend.path=usr/lib'.

This error implies that libclamav.so.9 could not be found.  It's looking
in /lib, /usr/gcc/7/lib, and /usr/lib for the SO file.  The first and
last are default locations for the runtime linker.  The middle one is
unlikely.  Where is that SO file?



Hello!

Sorry to pick up this thread for a new topic.

I have an issue building wxwidgets-3 on my machine. Theres a comment
on leaving out a lib, but the dependency is still there somehow.

From the Makefile:

# We don't want to depend on packages from encumbered. Thus, make sure
gstreamer1/plugin/bad is not installed.
#REQUIRED_PACKAGES += library/audio/gstreamer1/plugin/bad


gmake publish error:

oi-userland/components/library/wxwidgets-3/build/manifest-i386-wxwidgets-3.depend
has unresolved dependency '
    depend type=require fmri=__TBD
pkg.debug.depend.file=libgstplayer-1.0.so.0 \
pkg.debug.depend.reason=usr/lib/amd64/libwx_gtk3u_media-3.1.so.5 \
    pkg.debug.depend.type=elf \
    pkg.debug.depend.path=lib/64 \
    pkg.debug.depend.path=usr/gcc/7/lib/amd64 \
    pkg.debug.depend.path=usr/lib/64'.
gmake: *** [oi-userland/make-rules/ips.mk:502:
oi-userland/components/library/wxwidgets-3/build/.resolved-i386] Error 1

The file is in /usr/lib/amd64

$ ls -l /usr/lib/amd64/libgstplayer-1.0.so*
lrwxrwxrwx   1 root root  21 Nov 12 22:21
/usr/lib/amd64/libgstplayer-1.0.so -> libgstplayer-1.0.so.0
lrwxrwxrwx   1 root root  28 Nov 12 22:21
/usr/lib/amd64/libgstplayer-1.0.so.0 -> libgstplayer-1.0.so.0.1805.0
-r-xr-xr-x   1 root bin 172K Feb  2 13:05
/usr/lib/amd64/libgstplayer-1.0.so.0.1805.0

Maybe the 32bit build is trying to find the lib that is non-existent
for i386 but only for amd64 ? I didn't find the piece where the
dependency to libgstplayer is triggered.

Any hints ?


The package doesn't publish when library/audio/gstreamer1/plugin/bad is
installed. If you build this package for your own use you can remove the
comment line and let it use the plugin. We don't want wxwidgets-3 to
stay in encumbered so we build it without this plugin. Alas it's
necessary to uninstall library/audio/gstreamer1/plugin/bad when building
it for official OI because I was too lazy to find configure settings
that prohibit its use.

Andreas




I had the idea of building codeblocks with OI's package wxwidgets, and
for that it seems i need -fPIC in wxwidgets...


Greetings,

Stephan



___
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] Where to put the history file?

[Andreas Wacknitz]

Am 13.02.22 um 17:09 schrieb Gary Mills:

I have four packages that I'd like to obsolete:

 library/python/logilab-astng
 library/python/logilab-astng-27
 library/python/logilab-common
 library/python/logilab-common-27

These packages were formerly dependents of pylint, but are now unused.
I'd also like to remove the containing directories, which are:

 components/python/logilab-astng
 components/python/logilab-common

Both of these directories contain a history file.  Where do I put
them now?  Where do I put the four new lines?



components/meta-packages/history/history is our global history file.
You'll need to merge the contents of the local history files into it.


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

Re: [oi-dev] Proposal to change documentation structure for some pages

[Andreas Wacknitz]

Am 16.01.22 um 11:02 schrieb benn:
Hi,

I have included the openindiana mailing list in this discussion as I
hope it will reach more interested people.

At the moment James is the only actual member of the documentation team
and thus naturally its head.
I would like to invite everybody to chime in with ideas and opinions
here, and of course after discussion formulate a plan and act upon.

Everybody is invited to enhance our documentation by creating pull
requests against our oi-docs repository at
https://github.com/OpenIndiana/oi-docs

Please keep in mind that James as the team lead of the documentation
team will have the final decision about what will be merged and what not.

Best regards,
Andreas


Hi James,
Yes. I've noticed some of the pages becoming unwieldy too so your
suggestion is an inevitability. Having such collosal themes such as
ZFS, Dtrace, virtualisatiion, services, ... and more, hopefully, much
more to come and placing this all in one file makes it cumbersome for
the document writer. Moreover, when I'm reading up on something, I
ususally end up exporting just that section to its own file and using
the -f option to produce an epub of that one section.

However, it might be wise to keep related sections somehow together in
a kind of namespace. For example, if you split up a file, all new files
deriving from the original file share the same name prefix; or you
place all files into the same sub-directory.


It might be possible to keep the same number of pages and instead
investigate changes to the layout/theme in MkDocs; so it is easier to
find subsections. Some content could maybe move between the sections
where appropriate.

Most certainly.  Furthermore, when we begin to add an index, we'll see
more duplication of material and repitions can be replaced by a
reference to elsewhere.

Benn



On Sat, 2022-01-15 at 11:05 +, James Madgwick wrote:

Hi,

I've added an issue
(https://github.com/OpenIndiana/oi-docs/issues/211)
which proposes splitting some of the docs content into separate
pages.

In particular I noticed it when formatting some content from the old
Wiki for transfer. There's quite a bit covering ZFS to migrate,
putting
it all into an existing page would increase the length significantly.

My concern is there's a lot of content packed into a single page in
some cases and this is not the easiest to navigate. It is not
entirely
clear which topics are covered by which page in the handbook - there
is
some overlap.

It might be possible to keep the same number of pages and instead
investigate changes to the layout/theme in MkDocs; so it is easier to
find subsections. Some content could maybe move between the sections
where appropriate.


Thanks,
James

___
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



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

Re: [oi-dev] TeX Live doc update

[Andreas Wacknitz]

Am 12.01.22 um 19:08 schrieb s...@pandora.be:

I'm submitting a documentation update Pull Request (PR) for TeX Live.

http://docs.openindiana.org/handbook/community/texlive/

The change is:

-There are various options, if you have Perl Tk installed, you can also run the 
GUI :
+If you wish to use the TeX Live GUI, install the OpenIndiana Perl Tk package 
(the tk-perl IPS package is available on OpenIndiana release 2022 or higher) :


We don't have releases because we are following a so called rolling
release model. You don't need to install from a newer medium but just
run an ordinary "pkg update" and reboot into the newer boot environment
to get the latest. After a reboot you can install newer packages like
tk-perl.



+
+```none
+# pkg install -v tk-perl
+```
+
+Then run the TeX Live installer GUI as follows :

  ```none
  # install-tl --gui

The TeX Live distribution is a very complete distribution of the TeX 
professional typesetting software.

TeX is not only used for math, it is popular in advanced, programmable, 
typesetting, so it's great that TeX Live runs on OpenIndiana;  I'm sure that 
there's many advanced TeX programmers out there that like the TeX Live 
distribution.

The "pkg install -v tk-perl" step is a simple and useful step to install the 
necessary support for the TeX Live GUI.

Hopefully when TeX Live 2022 is released (which probably is about to happen in 
the following weeks) it'll work fine as well.

Regards,
David Stes

___
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] manually specifying dependencies between scripting language modules

[Andreas Wacknitz]

Am 04.01.22 um 07:39 schrieb Tim Mooney via oi-dev:

In regard to: Re: [oi-dev] manually specifying dependencies between...:



Am 04.01.22 um 06:10 schrieb Tim Mooney via oi-dev:


All-

My basic question is what the best practice is for how packagers
should be
specifying dependencies between language modules/libraries for
scripting
languages?  Currently I'm specifically interested in perl modules, but
the same idea is relevant for python, ruby, etc.

As an example of one way to do it, there's
oi-userland/components/perl/libwww-perl/libwww-perl-PERLVER.p5m.
Alexander manually added all of the modules that are needed for
libwww-perl-###, using the most obvious, "friendly" syntax for depend:

depend fmri=library/perl-5/encode-locale-$(PLV) type=require
depend fmri=library/perl-5/file-listing-$(PLV) type=require
depend fmri=library/perl-5/html-parser-$(PLV) type=require

etc.

Doing it that way, though, those dependencies don't get added to
Makefile
when you do "gmake REQUIRED_PACKAGES", and they don't appear to be
added
to the "pkg5" metadata after a successful publish.


This is intended. The requirements modeled in the Makefile (and thus in
pkg5) are BUILD dependencies whereas depend actions in the manifest are
RUNTIME dependencies.


Thanks Andreas!  That's the clearest explanation I've seen of that, and
it does help to clear up some things.

So thinking not about scripting languages but instead a traditional
ELF binary that's linked against multiple libraries, when I do a

gmake install; gmake REQUIRED_PACKAGES

pkg is adding build-time dependencies to the Makefile, but a later

gmake publish

is also adding the same dependencies to the package automatically as
runtime dependencies, correct?  It must be, based on ELF linkage,
otherwise we would have a lot of packages that don't have correct runtime
dependencies because we're not (manually) specifying them in the
manifest.


I don't know. As it hasn't been a problem yet, I didn't care to look
into it.





Alas our tools are not good at detecting runtime
dependencies and sometimes fail on build dependencies (eg. for test
requirements). So we need to manually add missing dependencies. The
actual state of both, runtime and build dependencies is lacking. And
sometimes you'll be hit by this fact when you build or install packages
locally. This is also a reason why sometimes local builds are fine while
they fail on the build server (and vice versa).




The same is true if you want to make a language module depend upon the
version of the perl interpreter it was built for.  I first tried using
this syntax:

depend fmri=runtime/perl-$(PLV) type=require

or variants of it as outlined in the pkg guide, like:

depend fmri=pkg:/runtime/perl-$(PLV) type=require

Dependencies specified that way aren't output by REQUIRED_PACKAGES.

However, if you change the syntax to a "less obvious" method:

depend fmri=__TBD pkg.debug.depend.file=perl \
    pkg.debug.depend.path=usr/perl5/$(PERLVER)/bin type=require

then REQUIRED_PACKAGES *does* add the dependency to the Makefile and
the
pkg5 metadata.  That's a trick that Aurélien has used in some places.


When IPS is working (eg. by running pkg install) it does not have access
to the information in the Makefiles or pkg5.
From what I know pkg5 files aren't yet used at all. They are artifacts
from future enhancements of the build tools Aurélien has been working
on.


Oh, interesting, I wasn't aware that pkg5 wasn't really even being used.
I assumed that was some critical metadata that pkg used.


So what's the right thing to do here? Use the simple syntax in the .p5m
file and don't care that the dependency isn't listed in the Makefile or
pkg5?  Use the more complicated syntax, with "fmri=__TBD" and a file
and
path from the dependency?  Don't specify anything in the .p5m file and
instead manually add the dependency in the Makefile, as you might for
a build dependency?


It depends on what you want to model: build dependency, runtime
dependency or both.


In the case that prompted my question, it would be both.

For example the perl/File-Listing module has an unrecorded build-time
and runtime dependency on library/perl-5/http-date for the same version
of perl (i.e. library/perl-5/file-listing-524 needs
library/perl-5/http-date-524).

It's needed at build time to run the test suite.

It's also needed at runtime for the correct functioning of the module.

I want to correctly record that file-listing for one version of perl
needs http-date from the same version of perl.

In this case, am I correct in thinking I should be doing both of these
things:

1) manually add REQUIRED_PACKAGES += library/perl-5/http-date-###
to the Makefile for the build-time dependency.

2) add

depend fmri=library/perl-5/http-date-$(PLV) type=require

to the manifest as a runtime dependency?


Yes, to my knowledge. I am still learning myself.

Andreas

___
oi-dev mailing 

Re: [oi-dev] manually specifying dependencies between scripting language modules

[Andreas Wacknitz]

Am 04.01.22 um 06:10 schrieb Tim Mooney via oi-dev:


All-

My basic question is what the best practice is for how packagers
should be
specifying dependencies between language modules/libraries for scripting
languages?  Currently I'm specifically interested in perl modules, but
the same idea is relevant for python, ruby, etc.

As an example of one way to do it, there's
oi-userland/components/perl/libwww-perl/libwww-perl-PERLVER.p5m.
Alexander manually added all of the modules that are needed for
libwww-perl-###, using the most obvious, "friendly" syntax for depend:

depend fmri=library/perl-5/encode-locale-$(PLV) type=require
depend fmri=library/perl-5/file-listing-$(PLV) type=require
depend fmri=library/perl-5/html-parser-$(PLV) type=require

etc.

Doing it that way, though, those dependencies don't get added to Makefile
when you do "gmake REQUIRED_PACKAGES", and they don't appear to be added
to the "pkg5" metadata after a successful publish.


This is intended. The requirements modeled in the Makefile (and thus in
pkg5) are BUILD dependencies whereas depend actions in the manifest are
RUNTIME dependencies. Alas our tools are not good at detecting runtime
dependencies and sometimes fail on build dependencies (eg. for test
requirements). So we need to manually add missing dependencies. The
actual state of both, runtime and build dependencies is lacking. And
sometimes you'll be hit by this fact when you build or install packages
locally. This is also a reason why sometimes local builds are fine while
they fail on the build server (and vice versa).




The same is true if you want to make a language module depend upon the
version of the perl interpreter it was built for.  I first tried using
this syntax:

depend fmri=runtime/perl-$(PLV) type=require

or variants of it as outlined in the pkg guide, like:

depend fmri=pkg:/runtime/perl-$(PLV) type=require

Dependencies specified that way aren't output by REQUIRED_PACKAGES.

However, if you change the syntax to a "less obvious" method:

depend fmri=__TBD pkg.debug.depend.file=perl \
    pkg.debug.depend.path=usr/perl5/$(PERLVER)/bin type=require

then REQUIRED_PACKAGES *does* add the dependency to the Makefile and the
pkg5 metadata.  That's a trick that Aurélien has used in some places.


When IPS is working (eg. by running pkg install) it does not have access
to the information in the Makefiles or pkg5.
From what I know pkg5 files aren't yet used at all. They are artifacts
from future enhancements of the build tools Aurélien has been working on.



So what's the right thing to do here?  Use the simple syntax in the .p5m
file and don't care that the dependency isn't listed in the Makefile or
pkg5?  Use the more complicated syntax, with "fmri=__TBD" and a file and
path from the dependency?  Don't specify anything in the .p5m file and
instead manually add the dependency in the Makefile, as you might for
a build dependency?


It depends on what you want to model: build dependency, runtime
dependency or both.




I'm happy to fix up missing inter-module dependencies when I find them,
but I would like to follow whatever the best practice is for these types
of dependencies.

Thanks,

Tim


Andreas

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

Re: [oi-dev] Squeak and libjpeg8-turbo

[Andreas Wacknitz]

Am 02.01.22 um 13:37 schrieb s...@pandora.be:

- Op 1 jan 2022 om 19:16 schreef Andreas Wacknitz a.wackn...@gmx.de:


Some packages can be configured to use an explicit path, eg.
CONFIGURE_OPTIONS += --with-jpeg-dir=/usr/include/libjpeg8-turbo

There is currently no such option for Squeak.

My problem was that I built using the #include  pointing to 
libjpeg6-ijg,
while linking against libjpeg8-turbo or libjpeg9-ijg;  that does not display 
jpeg images,
although that the link editor links fine and produces an executable.

David Stes

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

image/library/libjpeg-ijg has the following dependent packages:
desktop/remote-desktop/freerdp
image/library/libjpeg
library/desktop/webkitgtk2
library/graphics/wxwidgets
library/graphics/wxwidgets-3
library/qt5
runtime/java/openjdk11

We should try to build and test these packages (despite
image/library/libjpeg which is a meta package) with libjpeg8-turbo and
see how far we come. Maybe we can get rid of libjpeg6.ijg.

Andreas


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

Re: [oi-dev] Squeak and libjpeg8-turbo

[Andreas Wacknitz]

Am 01.01.22 um 13:16 schrieb s...@pandora.be:

Sorry I meant /usr/include/jpeglib.h ...

Sorry, I was too quick with my answer to your original mail.


Anyway this file points to the libjpeg6-ijg implementation.

I'd recommend for anyone testing libjpeg8-turbo to temporarily remove 
/usr/include/jpeglib.h,
so to be 100% sure that somehow /usr/include/jpeglib.h is not included.

The sizeof of struct jpeg_decompress_struct and struct jpeg_compress_struct are 
different,
between the JPEG_IMPLEMEN leading to hard to track allocation failures.

In the case of Squeak there is a Smalltalk primitive that returns the sizeof 
the underlying C structs,
and this must be correct obviously when changing from e.g. libjpeg6-ijg to 
libjpeg9-ijg or libjpeg8-turbo.

Some packages can be configured to use an explicit path, eg.
CONFIGURE_OPTIONS += --with-jpeg-dir=/usr/include/libjpeg8-turbo

Andreas

David Stes

- Op 1 jan 2022 om 12:20 schreef stes s...@telenet.be:


I have meanwhile found out what the problem was with Squeak and libjpeg9-ijg and
libjpeg8-turbo.

Basically this is Squeak and OpenIndiana specific.

The header file

   /usr/include/libjpeg.h

is a link to libjpeg6-ijg and that is why it only worked with libjpeg6-ijg.

I have in my Makefile for Squeak , CPPFLAGS set to add -I flag for the correct
JPEG_IMPLEMEN include directory,
but the Squeak configure script ignores or does not respect the CPPFLAGS, and
setting the -I flag in the CFLAGS,
fixes the issue.

It's important to use the right libjpeg.h header file.

The C struct size is different for some structs's like jpegcompress or
jpegdecompress
and these sizes differ between libjpeg6-ijg, libjpeg8-turbo and libjpeg9-ijg.

As soon as the right #include is used, Squeak links and opens JPEG files using
libjpeg8-turbo and libjpeg9-ijg as well.

To debug this, it helped to

   rm /usr/include/libjpeg.h

Perhaps there could also be a IPS mediator to select which libjpeg
implementation is to be used.

Regards,
David Stes

___
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] Squeak and libjpeg8-turbo

[Andreas Wacknitz]

Am 01.01.22 um 12:20 schrieb s...@pandora.be:

I have meanwhile found out what the problem was with Squeak and libjpeg9-ijg 
and libjpeg8-turbo.

Basically this is Squeak and OpenIndiana specific.

The header file

/usr/include/libjpeg.h

is a link to libjpeg6-ijg and that is why it only worked with libjpeg6-ijg.

I don't have this link (or file) on my systems and "pkg search
/usr/include/libjpeg.h" didn't reveal anything.
Are you sure that your build system is clean?

Regards
Andreas


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

Re: [oi-dev] some Newbie questions

[Andreas Wacknitz]

Am 12/29/21 um 20:46 schrieb Friedrich Kink via oi-dev:


Hi David,

basically I prepared the package ;-) but I'm not able to push it as
described at the end at https://docs.openindiana.org/dev/userland/. I
get (I did |git checkout -b Tk before)
|

git push origin Tk
remote: Permission to OpenIndiana/oi-userland.git denied to fritzkink.

You'll need to check what origin is. "git remote -v" will tell you about
your configured remotes. You are only allowed to push to Github
repositories that you have sufficient rights for.

This is typically your own fork. When you push to your own fork (which
is usually but not necessarily named origin) you can then create a PR
(pull request) against the repository you have forked from on Github.



which is probably ok as it most likely has to be reviewed by
maintainers first. Otherwise I'm just struggling with my limited git
experience.

kind regards,

  Fritz

Am 28.12.2021 um 20:19 schrieb s...@pandora.be:

Personally I'd like to request a perl tk package.

This can be used for TeXLive on OpenIndiana.

Currently the pagehttps://tug.org/texlive/distro.html  lists:

 Debian: aptitude install perl-tk
 Ubuntu: apt-get install perl-tk
 Gentoo: emerge dev-perl/Tk # older: dev-perl/tk
 ...

but no OpenIndiana.  However I'm sure that if there were a perl-tk package, 
then it'd work for TexLive install-tl.

It would be nice if you could just do "pkg install perl-tk" in OpenIndiana.

This is a personal opinion, I do not know whether such a package would be 
hard/difficult to make,
and whether it would be accepted.   But TCL/Tk is in the OpenIndiana repo.  TCL 
version 8.6.12,
which should be fine for TexLive as this requests TCL 8.5 or higher.

In fact I am sure perl/tk works, I compile it manually for the tlmgr -gui:

http://docs.openindiana.org/handbook/community/texlive/

Anyway if you would have a look at the Perl packages, I guess that would be a 
most welcome contribution.

Regards,
David Stes

- Op 28 dec 2021 om 13:11 schreef oi-devoi-...@openindiana.org:


Hello Tim,

thank you for the warm welcome. And thank you for the very valuable
answers and hints. They helped already a lot. I guess I 'll need some
more time to get to the nitty-gritty details. But I hope to be able to
upload a first package soon.

Fritz

Am 27.12.2021 um 23:11 schrieb Tim Mooney via oi-dev:

In regard to: [oi-dev] some Newbie questions, Friedrich Kink via
oi-dev...:

Hello and welcom, Fritz!


reading silently for a couple of years this mailing list I decided
now to contribute to the community my extensions I made over the
years to my system (at least I'd like to try ;-)). The main purpose
of my system is to act as mail server supporting all modern security
features like DANE, SPF, DKIM, DMARC etc (which works btw for couple
of years already, basically I started with opensolaris). That's why
I'll focus on those packages. Of course I've some questions after
starting this endeavor. Especially when trying to build Spamassassin
which requires a lot of additional Perl modules. While start building
these modules it turned out that the provided 64bit Perl version 5.24
is pretty outdated. So I built the current stable version 5.34 based
on the existing 5.24 setup. Worked like a charm ;-). Now first
question: Is there a reason/dependency for not upgrading to a newer
version?

It's likely a combination of

- limited contributor time
- contributor interest
- complexity of the task

I do have an update to perl planned, but there are some details
to work out and I probably won't be back to looking at the perl modules
until I'm done with some MATE-related stuff.


Next question:  Some Perl modules have odd version like 1.04 which
makes publishing a package impossible because of the padding zero in
the number after the dot. What is the reason for bailing out on a
padding zero (just a question for me and my understanding ;-))?

That reason for that is probably documented in the documentation for pkg,

 http://docs.openindiana.org/dev/pdf/ips-dev-guide.pdf

though I would have to do some searching to find the exact section.  I
think it comes down to "design choice".

As much as I like perl and have done lots of programming with it over
the years, its module numbering system leaves a lot to be desired.  The
standardization on "semantic versioning" that most other software has
done would be a welcome change in the perl module community, IMHO.  That,
of course, will never happen, but it sure would be nice if it did.


Also, some packages will require a new user and/or group. Are
uids/gids managed centrally or can I just choose some numbers <100
not used to my best knowledge?

There is a file in oi-userland that documents the reserved IDs:

 
https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/doc/reserved_uids_and_gids.md


If you need to add to that list, starting with a PR for that file is
probably the way to go.


How to store test results (I haven't found the trick where the

Re: [oi-dev] some Newbie questions

[Andreas Wacknitz]

Am 27.12.21 um 21:19 schrieb Friedrich Kink via oi-dev:

Hi all,

Hi Friedrich,

welcome to OpenIndiana. I am happy that you will provide help for some
interesting areas where we miss specialists.


reading silently for a couple of years this mailing list I decided now
to contribute to the community my extensions I made over the years to
my system (at least I'd like to try ;-)). The main purpose of my
system is to act as mail server supporting all modern security
features like DANE, SPF, DKIM, DMARC etc (which works btw for couple
of years already, basically I started with opensolaris). That's why
I'll focus on those packages. Of course I've some questions after
starting this endeavor. Especially when trying to build Spamassassin
which requires a lot of additional Perl modules. While start building
these modules it turned out that the provided 64bit Perl version 5.24
is pretty outdated. So I built the current stable version 5.34 based
on the existing 5.24 setup. Worked like a charm ;-). Now first
question: Is there a reason/dependency for not upgrading to a newer
version? Next question:  Some Perl modules have odd version like 1.04
which makes publishing a package impossible because of the padding
zero in the number after the dot. What is the reason for bailing out
on a padding zero (just a

I recommend to clone our main repository: OpenIndiana/oi-userland
(https://github.com/OpenIndiana/oi-userland). Within this you'll find a
folder named "doc" that contains important information, eg.
reserved_uids_and_gids.md, which may answer your question regarding user
and group ids (hint: the file needs an update if you add something).
Start reading on our documentation server, eg. "Building with
oi-userland" (https://docs.openindiana.org/dev/userland/).

Regarding odd version numbers like 1.04 in your example. Alas we are
restricted to what FMRI gave us and the version numbers are just a part
of the package's FMRI. While we are stuck on this there are some helping
definitions possible, eg. by additionally use IPS_COMPONENT_VERSION
(this is the one that ends in the FMRI and is automatically set by
COMPONENT_VERSION if not explicitly set to another value) and
HUMAN_VERSION, which can additionally be used to add the "real" version
information for a package. See for an example what actual
components/sysutils/sudo does to provide the HUMAN_VERSION (hint: you'll
need to have a definition in the Makefile and also a reference in the
manifest). It is always a good idea to look for existing solutions for a
problem you encounter. Typically it has already been solved by other
packages.


question for me and my understanding ;-))? Also, some packages will
require a new user and/or group. Are uids/gids managed centrally or
can I just choose some numbers <100 not used to my best knowledge? How
to store test results (I haven't found the trick where the results get
stored in the test directory while comparing existing packages with
mine). And finally when I think I'm ready to release my package would
this list be the place to ask for integration?

thanks a lot for all the work already,

  Fritz

Regards,
Andreas

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

Re: [oi-dev] Fatal error executing "make download" in oi-userland/cpmponents

[Andreas Wacknitz]

Am 16.12.21 um 17:11 schrieb clark k weeks:

Greetings,


Welcome to OpenIndiana!




I am brand new to OpenIndiana (and solaris of any kind) so my
nomenclature may not be completely correct. I will accept any help.

Reading from https://github.com/OpenIndiana/oi-userland#readme: The
very beginning is titled "Getting started with the Userland
Consolidation”
and if I'm reading it correctly it suggests to


The readme seems to be outdated. In fact I haven't noticed it yet.
Please follow our documentation at http://docs.openindiana.org/dev/userland/



git clone https://github.com/OpenIndiana/oi-userland.git/scratch/clone

I actually cloned it to /usr/src instead of /scratch/clone.  (I hope
that was not an error.)


No, this wasn't the cause of the error. You just decided to name your
local clone to have a different name than the readme proposes.




The next thing the README file suggests is to cd to the components
directory in the clone, then run, “make download”. When I executed
that command it trudged on for hours and ended with the following:

This is in my opinion a bad suggestion. It advises the system to
download all sources for all package definitions which probably will
talk a lot of time and space. Plus, it's not necessary at all because
when you run "gmake build" (or one of the other possible make targets)
it will do whatever is necessary to get there. So, in fact the first
step you should do after the initial cloning is to run "gmake setup" in
the main folder and probably also in components/encumbered.
To be successful you'll need to have sufficient rights and have
installed at least the "build-essential" package (pfexec pkg install -v
build-essential). It is also recommended to have your build system
up-to-date (pfexec pkg update -v) and if necessary rebooted after the
update.
It is necessary to reboot if a new boot environment has been created by
running pkg update.

I recommend to try to build existing packages before trying to update
any package sources or add new ones. You can enter a folder of an
interesting package, eg. by
    cd components/developer/git
    gmake build

This will automatically install missing packages needed for the build
and then download git's source packages and starts to build everything.
When this ends successfully you have a good starting point :)
"gmake publish" will create a package and puts it into your local
package repository (this is created by the aforementioned "gmake setup).
The oi-userland repository contains additional documentation in its doc
folder. You should start reading there, too.




Source /usr/share/src/oi-userland/archives/splix-315.tar.bz2...
validating signature... skipping (no signature URL)
validating hash... corruption detected
expected:
sha256:43f61ec33006a77b508c65765cf9295bc7d6258fbf3ef37ff3d23dc4e7df0375
actual:
sha256:ce5d148b7966c9844311d1c2ece2a8ef386e87778a8a2bedf2c2d8355cb9d08a
payload:
sha256:0eba76cd8d9af67992233da1ae1eda773a306d5578ad8b5e9e99f1b15dcecccd

WARN: Removing the corrupt downloaded file
Source SVN... not found, skipping file copy
Source
http://dlc.openindiana.org/oi-userland/source-archives/splix-315.tar.bz2...

downloading...
validating signature... skipping (no signature URL)
validating hash... corruption detected
expected:
sha256:43f61ec33006a77b508c65765cf9295bc7d6258fbf3ef37ff3d23dc4e7df0375
actual:
sha256:ce5d148b7966c9844311d1c2ece2a8ef386e87778a8a2bedf2c2d8355cb9d08a
payload:
sha256:0eba76cd8d9af67992233da1ae1eda773a306d5578ad8b5e9e99f1b15dcecccd


Downloading from dlc.openindiana.org is a bad sign. It's our last resort
if the original package source isn't available.
A sha256 mismatch is another problem and can have several reasons, one
of them the archive being hijacked. Typically this happens when the
package have been changed after we have calculated its checksum.
But splix is one of the very special source packages: it will be
dynamically built by downloading its contents from a subversion
repository. If your workstation is set up properly it should have
subversion installed and immediately starts downloading the sources by
means of svn.
In your case I expect that installing the build-essential package will
cure this problem.


WARN: Removing the corrupt downloaded file
/bin/bash: line 1: /usr/bin/svn: No such file or directory
gmake[1]: ***
[/usr/share/src/oi-userland/make-rules/prep-svn.mk:81:
/usr/share/src/oi-userland/archives/splix-315.tar.bz2] Error 127
gmake: *** [Makefile:183:
/usr/share/src/oi-userland/components/print/splix.nosetup] Error 2

It occurred that the download of the file may not have completed
properly, so, from the line, "Source
http://dlc.openindiana.org/oi-userland/source-archives/splix-315.tar.bz2…”,
I abstracted the full URL,
"http://dlc.openindiana.org/oi-userland/source-archives/splix-315.tar.bz2”,
cd’d to "/usr/share/src/oi-userland/archives” (which is where 

Re: [oi-dev] Porting an exFAT driver

[Andreas Wacknitz]

Am 14.12.21 um 11:58 schrieb Jean-Pierre André:

I have been trying to package for OpenIndiana a driver and utilities
developed by Andrew Nayenko and licensed as GPL2 for the exFAT file
system promoted by Microsoft as a replacement for FAT.

The packaging went fine locally (by gmake publish), but the pull
request check fails on :

aclocal: error: aclocal: file '/usr/share/aclocal/wxwin.m4' does not
exist
(see https://github.com/OpenIndiana/oi-userland/pull/7389)

You can ignore this error. It's from our new build server which isn't
yet updated automatically and runs with old versions of wxwidgets and
wxwidgets-3.
This has been fixed but the test server needs to be updated manually
again and probably updates itself regularly like our main build server does.



I have no idea of what triggers this, and as this does not occur
locally, I cannot make my own tries. I suspect having a difference of
versions in my autotools (fully updated). I also suspected the use of
the deprecated macro AC_PROG_CC_C99 had something do do with that,
but removing it does not bring any change.

I am at a loss over what else I could try, so I am giving up until
somebody points me at what I am doing wrong.


You aren't doing anything wrong.

Andreas

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

Re: [oi-dev] How to handle an unresolved dependency?

[Andreas Wacknitz]

Am 24.11.21 um 15:55 schrieb Gary Mills:

I'm working on the upgrade of an OI package called "fio".  Here's
part of an error message I got:

   $ gmake REQUIRED_PACKAGES
   ...
   .../components/sysutils/fio/build/manifest-i386-fio.depend has unresolved 
dependency '
   depend type=require fmri=__TBD pkg.debug.depend.file=six/__init__.py \
   pkg.debug.depend.reason=usr/bin/fio2gnuplot \
   pkg.debug.depend.type=python \
   pkg.debug.depend.path=usr/bin \
   pkg.debug.depend.path=usr/lib/python3.9 \
   pkg.debug.depend.path=usr/lib/python3.9/lib-dynload \
   pkg.debug.depend.path=usr/lib/python3.9/site-packages \
   pkg.debug.depend.path=usr/lib/python3.9/vendor-packages \
   pkg.debug.depend.path=usr/lib/python39.zip'.

Indeed, the file usr/lib/python3.9/vendor-packages/six/__init__.py
does not exist.  That's because the entire python module is contained
in the file usr/lib/python3.9/vendor-packages/six.py .  How do I fix
the manifest so that this dependency is accepted?



In many cases it's just needed to update the dependencies by running
"gmake REQUIRED_PACKAGES".
This will update the Makefile and you can check the new entries against
the old ones.
If Python is involved you sometime also need to
- either add new packages (typically we don't want that)
- or add a bypass-generate entry in the manifest


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

Re: [oi-dev] Does OI use gtk+ or gtk+3, or both?

[Andreas Wacknitz]

Am 11/8/21 um 00:43 schrieb Gary Mills:

I've been working my way through Aurlien Larcher's list of all OI
packages that are dependent on Python 2.7, upgrading as I went.
Apparently Python 3.5 is to be deprecated as well.  Now, I've come

Our Python 3.5 is the last one that has 32-bit support. If we drop it,
we'll need to drop many (if not all) 32-bit binaries.


to "nmap".  That package indeed depends on python 2.7 but also on
two other python libraries: pygobject-27 and pygtk2-27 .  Both of
those libraries do not have python 3.7 or 3.9 versions.

In fact, the web page for the new version of "pygtk2" says "For GTK+ 3
or Python 3 use PyGObject instead".  I see that the OI source has two
names for this package: pygobject and pygobject-3 .  Both packages are
obsolete, according to Aurlien's criteria above.  The latest version
of pygobject will require yet another new name, at least for the short
term.  What should this be?  Note that the version major number is
still 3, but that number has already been used.

As far as I can tell, OI uses both gtk+ and gtk+3 libraries.  Is this
correct?  As well, OI has two sets of python bindings: pygtk2 for
gtk+, and pygobject for gtk+3 .  Am I correct here too?  I notice that
only pygobject-27 is installed on my system now.  Will we switch to a
a new binding sometime?



The use of gtk+ and gtk+3 is probably because of pragmatism and history.
We should discuss in what direction we want OI to move regarding its
desktop environment,
considering the number of helping hands (in my opinion a lower single
digit number).

Andreas

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

Re: [oi-dev] libxml2 mapfile and symbol removal

[Andreas Wacknitz]

Hi Tim,

Am 11/14/21 um 05:25 schrieb Tim Mooney via oi-dev:


All-

I'm investigating how difficult it might be to update libxml2 and libxslt
to current latest versions.

Unfortunately, libxml2 removed a bunch of formerly public symbols at
version 2.9.10:

# emptyExp; removed in 2.9.10
# forbiddenExp; removed in 2.9.10
# xmlExpCtxtNbCons; removed in 2.9.10
# xmlExpCtxtNbNodes; removed in 2.9.10
# xmlExpDump; removed in 2.9.10
# xmlExpExpDerive; removed in 2.9.10
# xmlExpFreeCtxt; removed in 2.9.10
# xmlExpFree; removed in 2.9.10
# xmlExpGetLanguage; removed in 2.9.10
# xmlExpGetStart; removed in 2.9.10
# xmlExpIsNillable; removed in 2.9.10
# xmlExpMaxToken; removed in 2.9.10
# xmlExpNewAtom; removed in 2.9.10
# xmlExpNewCtxt; removed in 2.9.10
# xmlExpNewOr; removed in 2.9.10
# xmlExpNewRange; removed in 2.9.10
# xmlExpNewSeq; removed in 2.9.10
# xmlExpParse; removed in 2.9.10
# xmlExpRef; removed in 2.9.10
# xmlExpStringDerive; removed in 2.9.10
# xmlExpSubsume; removed in 2.9.10

At a minimum, that likely means that nearly everything that depends
upon libxml2 will need a rebuild.

Yes, if we are lucky all the existing packages will build with the newer
versions. But in our world you should expect breakages.
We have similar situations with other libraries, too. In my experience
you'll need to start the endeavor and find out what really breaks.
With that information we can decide whether it's worth to update. You'll
need to be prepared that it might take some time and efforts, though.



My question is about what should be done to the mapfile we use with
libxml2.  Most of these symbols are marked "global" at

SYMBOL_VERSION SUNW_1.6 {

Do I just comment them out of that block, or is there some other better
way to handle these now-removed symbols?


Sorry, I am not experienced enough to answer this question. The Solaris
"Linker and Libraries Guide" might have an answer for you.

Andreas



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

Re: [oi-dev] Does OI use gtk+ or gtk+3, or both?

[Andreas Wacknitz]

Am 11/9/21 um 17:56 schrieb Gary Mills:

On Sun, Nov 07, 2021 at 06:19:27PM -0800, Alan Coopersmith wrote:

On 11/7/21 3:43 PM, Gary Mills wrote:


Now, I've come to "nmap".  That package indeed depends on python 2.7

That's an upstream limitation:
https://github.com/nmap/nmap/issues/1176
https://github.com/nmap/nmap/pulls?q=is%3Apr+python3+is%3Aopen

Well, that solves that problem.  OI must remove nmap at the same time
as it obsoletes python 2.7 .  Nmap can return once it's able to be
built with python 3.7 or 3.9 .


Or, being pragmatic instead of dogmatic, we update whatever is possible
to python3 and keep python2 for packages that cannot be updated. Nmap
ist probably an important package for some users.

Cheers,
Andreas


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

Re: [oi-dev] what target creates $(WS_TOP)/archives ?

[Andreas Wacknitz]

Am 23.10.21 um 10:17 schrieb Tim Mooney via oi-dev:


All-

On a freshly-cloned oi-userland, which target is responsible for creating
$(WS_TOP)/archives ?  I would have expected 'setup' or 'env-prep' to
do it, but that doesn't seem to be it.  'download' within a component
directory also isn't doing it (and is failing, because $(WS_TOP_/archives
is missing).

Tim

Hi,

I don't think there is a special tool for creating $(WS_TOP)/archives.
It's just the default if you don't set a path by means of eg.
USERLAND_ARCHIVES=/projects/OI/source-archives
What you simply need to do if you want to stick with the default is to
create the folder manually.

Andreas

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

Re: [oi-dev] More on USB failure to automount

[Andreas Wacknitz]

> Am 10.10.2021 um 21:43 schrieb Gary Mills :
>
> On Sun, Oct 10, 2021 at 10:33:07AM +0200, Andreas Wacknitz wrote:
>>
>> Hi, are there any news about this bug and its fix?
>
> That patch didn't work.  Neither did the next dozen or so.  However, I
> did learn a great deal about glib.  I know what the cause is.  I just
> don't have the solution yet.
>
> One of the causes is the nature of the EAGAIN error.  In the context
> of hald and glib on OI, the read() system call within glib produces
> this error when the pipe is empty, but the other end of the pipe is
> still open for write.  Every subsequent read() will produce the same
> error until the process at the other end actually writes something to
> the pipe.  This error is converted to G_IO_STATUS_AGAIN by glib.  hald
> only processes lines when the status returned by
> g_io_channel_read_line() is G_IO_STATUS_NORMAL .  It ignores any
> others, including G_IO_STATUS_AGAIN .
>
> The other cause is that lines written by hald (with the write() system
> call) to the pipe all end with "\n\0".  Yes, the trailing null is
> written to and read back from the pipe.  However, hald does not set
> the line terminator as glib expects, instead relying on glib's
> automatic line ending determination.  In this case, that appears not
> to work.  Instead, glib does a second read, which always sets the
> status to G_IO_STATUS_AGAIN .  Once set, this status replaces any
> previous status.
>
> As you can see, hald writes lines to the pipe with write() but reads
> them back with g_io_channel_read_line().  That design may be a third
> cause.
>
> I'm going to do a bit more testing with hald and glib, and then return
> to what I was doing with OI.
>
>

Thank your for your update and good luck on your way of fixing this issue.

Andreas

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

Re: [oi-dev] More on USB failure to automount

[Andreas Wacknitz]

Am 9/2/21 um 9:58 PM schrieb Gary Mills:

On Thu, Sep 02, 2021 at 09:32:16PM +0200, s...@pandora.be wrote:

First of all it seems there are again OpenIndiana packages being updated;
thanks a lot for the work on this.

[...]

Unfortunately the USB problem is still there and it got worse for me.

I'm testing a patch for glib that might fix the USB problem on OI.


Hi, are there any news about this bug and its fix?

Regards,
Andreas

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

Re: [oi-dev] virtualbox 6.1.26 ?

[Andreas Wacknitz]

Am 9/12/21 um 11:51 AM schrieb s...@pandora.be:

Are there plans to update the OI virtualbox package ?

OI Hipster is a community project. Anybody can update packages locally
and create PR's to get it integrated into OI.

Yes correct of course.

VirtualBox 6.1.22 is working fine ...

I am using it with "vagrant" (with VirtualBox as "vagrant provider") and ruby 
2.7.3

$  vagrant --version
Vagrant 2.2.19.dev

$ ruby --version
ruby 2.7.4p191 (2021-07-07 revision a21a3b7d23) [i386-solaris2.11]

The ruby is compiled from source as Hashicorp recommends (they  recommend not 
to use system provided ruby).

An IPS vagrant package for OI would be nice (has anyone already made one ?)

For ruby upgrade to 2.7.4 is also possible. But ruby 3.0.2 seems not to compile 
on OpenIndiana for the moment.

David Stes

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



As I have stated before: We need more people helping with OI Hipster. We
lack contributions in almost every area:
creating/updating packages, testing and documentation. Things don't
happen magically. Efforts and engagement by volunteers is needed.
The companies involved in illumos seem only be interested in its server
use. So, the complex part of creating a desktop is up to the community...

Andreas


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

Re: [oi-dev] virtualbox 6.1.26 ?

[Andreas Wacknitz]

Am 9/12/21 um 10:56 AM schrieb s...@pandora.be:

Hi,

I just updated succesfully to the latest OpenIndiana/Hipster on my system

$ pkg list userland-incorporation
NAME (PUBLISHER)  VERSIONIFO
consolidation/userland/userland-incorporation 0.5.11-2020.0.1.14424  i--

This is the userland package from :

Packaging Date: Sat Sep 11 16:42:38 2021

It has the Smalltalk-80 language package that I maintain :

$ pkg list cog-spur
NAME (PUBLISHER)  VERSIONIFO
runtime/smalltalk/cog-spur5.0.3066-2020.0.1.0i--

However it still has VirtualBox 6.1.22 :

$ pkg list virtualbox
NAME (PUBLISHER)  VERSIONIFO
system/virtualbox 6.1.22-2020.0.1.2  i--

The virtualbox package is provided by and part of userland-incorporation:

$ pkg contents -m userland-incorporation | grep virtualbox
depend facet.version-lock.system/virtualbox=true 
fmri=system/virtualbox@6.1.22-2020.0.1.2 type=incorporate
depend facet.version-lock.system/virtualbox/virtualbox-additions=true 
fmri=system/virtualbox/virtualbox-additions@6.1.22-2020.0.1.2 type=incorporate

The current version since July is 6.1.26

https://www.virtualbox.org/wiki/Downloads

which is VirtualBox-6.1.26-145957-Solaris.p5p

(from Innotek/Oracle)

Are there plans to update the OI virtualbox package ?


OI Hipster is a community project. Anybody can update packages locally
and create PR's to get it integrated into OI.

Regards,
Andreas

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

Re: [oi-dev] Status of OpenIndiana Wiki (Atlassian Confluence)

[Andreas Wacknitz]

Am 9/11/21 um 7:39 PM schrieb Till Wegmueller:

Hi James

It's not Offline just because the Vulnerability. It crashes on an
ongoing basis. I know Wacki has been starting it whenever somebody
asked. But not recently.

Ist there a good way to get a HTML export of the WIKI for migration
purposes? If so we could make one and then just dump that to a
Webserver and continue to migrate to docs.

-Till


Hi,

I have restarted the confluence service. I would be happy if we can
migrate the pages that haven't been migrated yet and then turn it off.

Regards,
Andreas


On 11.09.21 14:08, James Madgwick wrote:

Hi,

I notice the old Wiki (https://wiki.openindiana.org) is giving "503
Service Unavailable". Recently a major vulnerability in old versions of
Confluence, including the version used on the Wiki, has been in the
news. I'm wondering if this is why the Wiki is down?

In any case, I had been making a list of the pages in the Wiki and what
content needed to be migrated. The eventual goal being to decommission
the Wiki once everything useful had been migrated. The majority of the
Wiki's content was already migrated to the Docs website in the last few
years.

If the Wiki has been forced offline, it would probably be easiest to
restore it only briefly to perform a full HTML export and use that in
the interim. Patching the Confluence vulnerability probably wouldn't be
worth it.


James

Vulnerability details:
https://us-cert.cisa.gov/ncas/current-activity/2021/09/03/atlassian-releases-security-updates-confluence-server-and-data

https://confluence.atlassian.com/doc/confluence-security-advisory-2021-08-25-1077906215.html

https://www.zdnet.com/article/us-cybercom-says-mass-exploitation-of-atlassian-confluence-vulnerability-ongoing-and-expected-to-accelerate/


___
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


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

[oi-dev] our build server is offline

[Andreas Wacknitz]

Hi all,

Since last week our build server has problems which ended in an
unbootable system last Saturday.
At the moment we cannot build any packages (including nightly
illumos-gate builds) and thus it doesn't make sense to merge PR's.

Regards,
Andreas


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

Re: [oi-dev] [OpenIndiana-discuss] warning - don't update OI

[Andreas Wacknitz]

Hi all,

It is now safe again to update.

I had to revert the binutils-2.37 update and instead created a fake 2.37
package version that delivers the older 2.36.1 version.
With that I have re-published the latest illumos-gate packages and
successfully installed them on my machines.
Thanks to Toomas Soome for helping me and analyzing the problem.

Andreas

Am 7/24/21 um 9:55 AM schrieb Andreas Wacknitz:

Hi all,

something bad has happened with the last updates and rendered two of my
build servers unbootable. They are both stuck in the boot loader ("start
not found") such that
booting with an old BE won't fix that!

SO DON'T UPDATE YOUR SYSTEMS FOR NOW!

I fear that my update of binutils-2.37 may be the culprit.

Regards
Andreas

___
openindiana-discuss mailing list
openindiana-disc...@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


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

[oi-dev] warning - don't update OI

[Andreas Wacknitz]

Hi all,

something bad has happened with the last updates and rendered two of my
build servers unbootable. They are both stuck in the boot loader ("start
not found") such that
booting with an old BE won't fix that!

SO DON'T UPDATE YOUR SYSTEMS FOR NOW!

I fear that my update of binutils-2.37 may be the culprit.

Regards
Andreas

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

Re: [oi-dev] I've given up on gnome-doc-utils

[Andreas Wacknitz]

Am 05.07.21 um 23:20 schrieb Gary Mills:

In an attempt to eliminate dependancies on python-27, I came
eventually to the gnome-doc-utils package.  Reluctantly, I had to give
up my attempt.  The product was last updated in 2012 and has no
python-3 support.  Most of the work is conversion of the python code
from 2 to 3, using the python bindings for libxml2.  Somebody who
knows more about python than I do may be able to accomplish this.  The
alternative is to abandon the package and perhaps any packages that
require this one.  I'm moving on to other packages.


The question is with what it has been replaced upstream. Maybe we should
follow...

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

Re: [oi-dev] OI no longer automounts USB sticks

[Andreas Wacknitz]

Am 27.06.21 um 11:50 schrieb s...@pandora.be:

- Op 27 jun 2021 om 10:55 schreef Andreas Wacknitz a.wackn...@gmx.de:


And I am only able to do limited
manual tests, because I have lots of other things I want to do.
I only use USB sticks very rarely and while I do change my mouse or
keyboard from time to time, it hasn't been on my test scenarios in the past.
So problems like this will only be detected long after they have been
introduced.

I'd appreciate if we could find some volunteers for tests and would even
more appreciate if you could find somebody starting to create automatic
tests.


The best testing is desktop users of OpenIndiana.

I like the 2021.04 release of OI, this is a great piece of work, and this 
release works well on my PC
(thanks for the work on it).

Regarding the USB automount, I can personally live with the workaround of 
manual mount.
Automount would be nice so if it gets fixed all the better.

David Stes


While I understand your point of view you should be aware that if I
continue to update things without proper testing more and more things
will break.
At some point in time I will break things you rely on and then your
unhappiness will begin.

We are a very small community and if I cannot convince more people to
help out, OI will either become outdated in more and more areas
or it will be more and more buggy. And probably both.

I didn't find the problem earlier because of how I use OI. I don't use
many things that I have been working on in the past. I will probably
stop that,
because I am running out of time. If I have to care for everything I
will not be able to do anything in the end.

Regards

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

Re: [oi-dev] OI no longer automounts USB sticks

[Andreas Wacknitz]

Am 27.06.21 um 10:00 schrieb Joshua M. Clulow via oi-dev:

On Fri, 25 Jun 2021 at 18:52, Gary Mills  wrote:

On Fri, Jun 25, 2021 at 12:24:52PM -0700, Joshua M. Clulow via oi-dev wrote:

It seems like it would be good to figure out, on the systems that _do_
work, what exactly is performing the mount.  Then we can work
backwards to why that is no longer happening.

Good idea.  I have a system running an older BE where the automount
does work.  I did exactly what you suggested.
 # dtrace -w -n '
 > syscall::*mount*:entry {
 > raise(SIGSTOP);
 > system("pargs %d; ptree %d; prun %d", pid, pid, pid);
 > }'
 dtrace: description '
 syscall::*mount*:entry ' matched 2 probes
 dtrace: allowing destructive actions
 CPU IDFUNCTION:NAME
  10   8968umount2:entry 3951:   
/usr/lib/hal/hald-addon-storage
 argv[0]: /usr/lib/hal/hald-addon-storage
 1994   /usr/lib/hal/hald --daemon=yes
   1995   hald-runner
 3951   /usr/lib/hal/hald-addon-storage

  11   8532  mount:entry 3955:   mount -o nosuid 
/dev/dsk/c4t0d0p0:1 /media/STORE N GO
 argv[0]: pcfs_mount
 argv[1]: -o
 argv[2]: nosuid
 argv[3]: /dev/dsk/c4t0d0p0:1
 argv[4]: /media/STORE N GO
 1994   /usr/lib/hal/hald --daemon=yes
   1995   hald-runner
 3954   /usr/lib/hal/hal-storage-mount
   3955   mount -o nosuid /dev/dsk/c4t0d0p0:1 /media/STORE N GO

   2   8532  mount:entry 3951:   
/usr/lib/hal/hald-addon-storage
 argv[0]: /usr/lib/hal/hald-addon-storage
 1994   /usr/lib/hal/hald --daemon=yes
   1995   hald-runner
 3951   /usr/lib/hal/hald-addon-storage

Thanks for that!

OK, so I have looked into this a little bit.  It seems like there is a
bug in the HAL code we ship, or in the glib that OI is now using, or
somewhere inbetween.

With DTrace, I am able to see (in the "hald --daemon=yes" process at
the top of the HAL process tree) that it receives the appropriate
sysevents from the kernel when a USB disk is plugged in or removed.
We get as far as the sysevent_dev_handler() routine:

 
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L157-L191

In particular, on my system, I see three write(2) calls that look like this:

EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2

EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2/disk@0,0

EC_dev_add disk /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
/dev/rdsk/c4t0d0 0

This seems about right.  These writes are into a self-pipe (i.e., both
ends of the pipe are held open within this single hald process) that
is established in the sysevent_init() routine, and stored in the
"sysevent_pipe_fds" global where I was able to confirm with pfiles
that the pipe is still open.

Where things appear to fall down is once we get into the glib area.
The strings that are written into one end of the pipe by the sysevent
consumer, as described above, are meant to then be read through a glib
GIOChannel object in sysevent_iochannel_data():

 
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L244-L272

Though we do enter sysevent_iochannel_data() on schedule for each
sysevent, it seems like the call to g_io_channel_read_line() always
returns a value of 3 on my system -- which seems like an EOF?  Because
the value is not G_IO_STATUS_NORMAL, we don't even try to call
sscanf() to parse the lines we wrote above.  This means we never call
into sysevent_dev_add() and thus we never pass the hotplug event on to
the rest of HAL.

I have run out of steam on this for now, but I hope this is enough for
someone to keep digging.  In particular, it seems like it is worth
investigating whether glib has been updated in OI at some point
between when this was last working and now.  Perhaps there is a build
issue or a bug there.  It doesn't seem like there has been a lot of
change in the HAL daemon itself (which is in the gate, as linked
above).

One imagines this may also have an impact on the X11 keyboard/mouse
situation as those changes are presumably communicated via sysevents
to HAL, and HAL is similarly dropping the ball there.

Cheers.


Thanks a lot for your analysis, Josh.

In fact we had some minor glib updates in the past. Alas we have neither
automatic tests nor official testers at all.
So, the main test burden is left to me. And I am only able to do limited
manual tests, because I have lots of other things I want to do.
I only use USB sticks very rarely and while I do change my mouse or
keyboard from time to time, it hasn't been on my test scenarios in the past.
So problems like this will only be detected long after they have been
introduced.

I'd appreciate if we could find some volunteers for tests and would even
more appreciate if you could find somebody starting to create automatic
tests.

Regards

Re: [oi-dev] DDU HCL submission - Dell Precision 3640 Intel(R) Core(TM) i3-10100 CPU

[Andreas Wacknitz]

Am 24.06.21 um 20:14 schrieb s...@pandora.be:

Last update on

https://wiki.openindiana.org/oi/Servers+and+Workstations

says: last modified by Michal Nowak on May 13, 2018

That's from 2018, there is a need to update the Hardware Compatibility Guide !!

The HCL seems to have moved to 
http://docs.openindiana.org/community-hcl/systems/

OpenIndiana 2020.04 and 2021.04 seems to install and work on the Dell Precision 
3640 workstation.

See screenshot oi-dell-precision-3640 in attach.

The text install 2020.04 worked fine (UEFI boot since this is a EFI system),
and installation went fine on a SATA boot disk from physical CD-ROM.

I didn't try a SSD boot disk.

Audio seems to work fine as well
(onboard audio Comet Lake PCH cAWS or Nvidia, not sure 2 cards are listed in 
DDU)

Video (MATE lightdm as well) on NVidia as well - but not on the onboard Intel 
UHD 630.

The intel onboard UHD 630 card works in vgatext for booting multi-user or 
console.

On the Nvidia card, openindiana MATE runs fine in X11 with the nvidia driver 
and config/settings tool.

I ran diagnostics/ddu and it finds a few unknown devices for which it installed 
one package

  Intel Corporation Comet Lake PCH Termal Controller

ddu installed a driver for the above

Should I worry about the remaining 4 unknown devices ?

 Intel Corporation Comet Lake PCH Serial IO I2C Controller #0
 Intel Corporation Comet Lake PCH Serial IO I2C Controller #1
 Intel Corporation Comet Lake HECI Controller
 Intel Corporation Comet Lake PCH SPI Controller

I'm unable to submit an entry for this system.

When I click Submit I get : " OpenIndiana HCL server is not active. "

Also the DDU is not recognizing the i3-10100 CPU.  It just prints CPU : 1X
instead of something like 1X Intel(R) Core(TM) i3-10100 CPU

However psrinfo and prtdiag seem ok and the system seems to run fine.

Is the feedback address hcl-feedb...@openindiana.org still active ?

Possibly this system could be added to the OpenIndiana HCL as a new submission,
or I'll try to see whether I can add it to the docs ...

Regards,
David Stes


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

The wiki isn't updated for quite some time. The former documentation
team started efforts to create new documentation located under
docs.openindiana.org.
Part of their work was to move/recreate wiki contents. Alas the old team
vanished a few years ago (for me it happened like overnight).
We had a few volunteers popping up in the mailing list and some work has
been started to update the tool chain. I haven't seen much new contents,
though.
So, I would appreciate if more people get involved into updating and
enhancing the documentation.

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

Re: [oi-dev] OI no longer automounts USB sticks

[Andreas Wacknitz]

On 6/6/21 9:43 PM, Gary Mills wrote:

On Sun, Jun 06, 2021 at 11:06:06AM -0700, Alan Coopersmith wrote:

hal monitors the devices and uses dbus to send messages to other programs
on certain events - like notifying the GNOME/Mate file manager when a new
removable media device is inserted or removed so they can show/hide it.

So, I got it backwards.  dbus is only a message bus or a rendevous
point.  It's hal that's likely responsible for ignoring changes to
USB devices.  I've already got ideas how to debug this problem.



service/hal is delivered by illumos-gate

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

Re: [oi-dev] OI no longer automounts USB sticks

[Andreas Wacknitz]

On 6/5/21 3:43 PM, Gary Mills wrote:

On Sat, Jun 05, 2021 at 11:07:46AM +0200, Andreas Wacknitz wrote:

I don't use USB sticks with OI but I noticed something probably related
on my desktop: For some time now newly plugged mice or keyboards cannot
be used in X11. Even logout and re-login doesn't help. It looks as if
USB device need to be plugged during boot in order to be usable.

I noticed that too.  I thought at first that it was an illumos
problem, but now I believe that it's another manifestation of the same
OI problem.  I'm assuming now that dbus is not noticing changes in USB
devices, but I want to confirm that theory with more testing on OI.
The next step is to determine why this is happening.



The last dbus change was

commit d6ee7970120f4fc2201e33f2bcdcb318235ab0c3
Author: Andreas Wacknitz 
Date:   Sat Oct 3 18:56:09 2020 +0200

    libdbus, dbus, dbus-x11: update to 1.12.20


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

Re: [oi-dev] OI no longer automounts USB sticks

[Andreas Wacknitz]

On 6/4/21 10:11 PM, Gary Mills wrote:

On Fri, Jun 04, 2021 at 07:31:20AM -0500, Gary Mills wrote:

I found a document that might help.  It describes:

 lshal --monitor
 dbus-monitor --system

Ah, I tried the first command on an OI system running the 2020-11-27
BE and did get some output while I inserted and removed a USB stick:

 # lshal --monitor

 Start monitoring devicelist:
 -
 pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 added
 pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 added
 pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 added
 pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 
added
 
pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 
added
 
pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1
 added
 
pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1
 property volume.mount_point = '/media/STORE N GO'
 
pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1
 property volume.is_mounted_read_only = false (new)
 
pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1
 property volume.is_mounted = true
 
pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1
 property volume.mount_point = ''
 
pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1
 property volume.is_mounted = false
 
pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1
 removed
 
pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 
removed
 pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 
removed
 pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 removed
 pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 removed
 pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 removed

This system did automount the USB stick and did pop up a window
showing the contents of the stick.  Now we are getting somewhere.
Something is wrong with the OS upgrade.  All that's left is to figure
out what is missing or what is ignoring USB events.



I don't use USB sticks with OI but I noticed something probably related
on my desktop: For some time now newly plugged mice or keyboards cannot
be used in X11. Even logout and re-login doesn't help. It looks as if
USB device need to be plugged during boot in order to be usable.


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

Re: [oi-dev] Let's Encrypt support in 2021.04?

[Andreas Wacknitz]

On 5/24/21 5:58 PM, Klaus Elsbernd wrote:

Hello,

since this week, my old HP Gen7 server is up and running again and I
ported isfdb to it.

Now I would like to add letsencrypt certificate to it.

https://letsencrypt.org/getting-started/ suggested to use certbot.

Is there any support for letsencrypt in OpenIndiana currently. I tried
to run certbot installation, but it ruined my USB-Installation. (My
fault).

bis dann

Klaus


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

We are using https://github.com/srvrco/getssl

Regards,
Andreas


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

Re: [oi-dev] Moving on with postgresql

[Andreas Wacknitz]

Am 18.04.21 um 02:37 schrieb Austin Kim:

On Apr 17, 2021, at 7:22 PM, Till Wegmueller  wrote:

Hi Gary

I use Postgres and extensions for all Applications I develop professionally and 
privately.

We use mostly 12 and upwards 13 being the standard and I am waiting for 14 to 
hit. The last Bugfix release for 9.5 was on 2021-02-11 so quite recently.

I would love to have 13 and modern 12 packaged, especially as we have a build 
server for them sponsored by the Oi community. So we know it builds even on 
current develop.

My preference for the record is to have 13, 12 and 11. Older ones should only 
be used for people still needing them. AWS only offers those in their offerings 
as well, so not many people will want 10 or older.

-Till

On 17.04.21 18:46, Gary Mills wrote:

OI currently has postgresql versions: 95 96 10 11 12 .  The OI
default, in shared-macros.mk, is 95 .  However, the postgresql
developers report that 95 is unsupported, but 13 is available and
supported.  Something has to change in OI to move forward with
postgresql.
Here are some actions that could be taken with OI.  We could change
the default version to 10.  I, myself, would prefer 11.  We could
obsolete 95.  I'd prefer obsoleting 95 and 96.  We could add version
13, but only after 96 is obsoleted.  We should limit the number of
postgresql versions in OI, after all.  Finally, we could make no
obsoletions or additions, retaining even the unsupported 95.  Which
would you prefer?
I have not investigated two questions.  Perhaps you can tell me?  What
are the consequences of obsoleting 95?  What are the consequences of
the default change?

Hi,

Sorry for posting to this list as I’m only an OpenIndiana user, not a 
developer, but PostgreSQL is the DB I use most.

This is perfectly fine.
I just want to chime in here and say: You don't need to be a developer
in order to get involved in OpenIndiana!
Of course it is helpful to know some programming languages and build
systems. But many for aspects you don't need to be a professional
programmer.

At the moment we lack volunteers in almost all areas, even those not
related to updating packages. Eg. we need people to enhance or update
our documentation,
we need testers and of course people who care for some packages.

Nobody started as an expert in any of these areas. I am willing to help
people to get involved, eg. we can have video conferences where I can
demonstrate and teach how to update packages.

Of course you need to devote some resources (time, build or test
environment, ...). I can assure you that you will learn a lot about
OpenIndiana, Solaris and other operating systems.
And you will see some insanity related to software development,
especially open source software development where projects make heavy
changes (like change the build system) in minor or even micro releases.

Andreas

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

Re: [oi-dev] Moving on with postgresql

[Andreas Wacknitz]

Am 17.04.21 um 23:46 schrieb Gary Mills:

OI currently has postgresql versions: 95 96 10 11 12 .  The OI
default, in shared-macros.mk, is 95 .  However, the postgresql
developers report that 95 is unsupported, but 13 is available and
supported.  Something has to change in OI to move forward with
postgresql.

Here are some actions that could be taken with OI.  We could change
the default version to 10.  I, myself, would prefer 11.  We could
obsolete 95.  I'd prefer obsoleting 95 and 96.  We could add version
13, but only after 96 is obsoleted.  We should limit the number of
postgresql versions in OI, after all.  Finally, we could make no
obsoletions or additions, retaining even the unsupported 95.  Which
would you prefer?

I have not investigated two questions.  Perhaps you can tell me?  What
are the consequences of obsoleting 95?  What are the consequences of
the default change?



You are right, removing PostgreSQL-9.5 is overdue.
And yes, we should think about reducing the number of PostgreSQL
versions we support because of our limited man power.
Furthermore, we (at least I) don't know who is really using PostgreSQL
and what version is being used.

Changing the settings to a newer version and removing 9.5 (and whatever
else) is only the first step.
The 2nd step is to republish all depending packages with the new default
version. What versions can be obsoleted and removed
depend on this step: we might need to update/patch or remove dependant
packages if they don't build with the newer default version anymore.
To find out which packages depend on postgresql isn't hard, but it might
be a lot more work to find out what needs to be done to update all of them.
Both steps need to be prepared and then executed right after each other
(but serially).


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

Re: [oi-dev] Variable PATH in Makefile (tornado)

[Andreas Wacknitz]

Am 14.04.21 um 12:40 schrieb Nona Hansel:

Hello,

I'm having some problems updating tornado. Currently, the PATH
variable in Makefile is defined in the older mode like this:
PATH=/usr/bin:/usr/gnu/bin:/usr/sbin
Like this, tornado builds, installs and publishes fine.


The old settings prefer / priorize our own tools over the GNU ones
because /usr/bin comes before /usr/gnu/bin.

When you look in make-rules for the definitions of PATH.gnu and
PATH.illumos then you will see that PATH.illumos
does something similar. It priorizes our tools over the GNU tools, but
nevertheless it also includes the GNU binaries path.
So I would expect that the right thing to do would be to use
PATH=$(PATH.illumos)
here.

Andreas

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

Re: [oi-dev] valgrind and epoll(5) illumos issue

[Andreas Wacknitz]

Am 10.04.21 um 18:22 schrieb Bob Friesenhahn:

On Sat, 10 Apr 2021, s...@pandora.be wrote:


valgrind seems to work on the squeak VM runtime (which was a surprise
to me,
since the squeak VM runtime is not exactly simple).

It's a nice tool  - and a good/excellent package in the OI repository.


Probably the valgrind I have on my machine is out of date.  It
identifies itself as version 3.15.0 and the timestamp on the
executable is April 20, 2020.  It does not work at all for testing
GraphicsMagick and ends in a core dump.

It would be good to have Clang or GCC ASAN working as well.  One of
the main reasons why I continually turn to a Linux system is a working
valgrind and ASAN/UBSAN.

Bob

If almost nobody cares for packages on OI enough to update them then
sooner or later OI will be dead.
Eg. you state on your signature that you are a graphicsmagic maintainer,
yet our graphicsmagic version is 1.3.26 while the latest is 1.3.36
according to https://repology.org/project/graphicsmagick/versions

Andreas

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

Re: [oi-dev] valgrind and epoll(5) illumos issue

[Andreas Wacknitz]

Am 10.04.21 um 11:32 schrieb s...@pandora.be:

The original Squeak (Smalltalk-80) runtime (similar to squeak-4) uses signal 
driven,
non-blocking I/O using select(3c).

An interesting ongoing recent project in the world of Squeak,
is to add epoll(7) support to squeak-5;
so basically a developer added epoll(5) for event-driven I/O.

https://illumos.org/man/5/epoll

This is not really OpenIndiana specific but since I use squeak on OpenIndiana, 
I'm asking here.

The configure script detects that OI supports epoll (via 
/usr/include/sys/epoll.h),
and it enables the support which compiles fine, and it basically seems to work 
fine, I think.

However when I run the executable using the valgrind tool

# pkg info -r valgrind
   Name: developer/debug/valgrind
Summary: Valgrind: instrumentation framework and tools to detect memory
 and threading problems

Then I run into the following issue.

In illumos-gate/usr/src/uts/common/sys/devpoll.h the following is defined

$ grep DPIOC uts/common/sys/devpoll.h
#define DPIOC   (0xD0 << 8)
#define DP_POLL (DPIOC | 1) /* poll on fds cached via /dev/poll */
#define DP_ISPOLLED (DPIOC | 2) /* is this fd cached in /dev/poll */
#define DP_PPOLL(DPIOC | 3) /* ppoll on fds cached via /dev/poll */
#define DP_EPOLLCOMPAT  (DPIOC | 4) /* turn on epoll compatibility */

Now valgrind reports the following :

==8531== Warning: noted but unhandled ioctl 0xd004 with no size/direction hints.
==8531==This could cause spurious value errors to appear.
==8531==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper
  wrapper.
==8531== Syscall param write(buf) points to uninitialised byte(s)
==8531==at 0xFFFD5D8AA: __write (in /lib/amd64/libc.so.1)
==8531==by 0xFFFD30670: epoll_ctl (in /lib/amd64/libc.so.1)

Note that the unhandled ioctl is 0xd004 which is the DP_EPOLLCOMPAT I suspect.

So OpenIndiana valgrind has no 'wrapper' for DP_EPOLLCOMPAT.

Also valgrind complains about the uninitialized bytes in epoll_ctl,
which perhaps are due to :

illumos-gate/usr/src/lib/libc/port/sys/epoll.c

int
epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)
{
 dvpoll_epollfd_t epoll[2];

 res = write(epfd, epoll, sizeof (epoll[0]) * (i + 1));


I am not sure but valgrind may be complaining about passing epoll argument to 
write().

Perhaps this could be patched at the OpenIndiana level,
but ideally the Illumos contributors could contact valgrind.org to patch 
valgrind,
and/or the illumos sources (if required).

Also that would fix the issue for all Illumos based distributions, not just for 
OpenIndiana,
provided OpenIndiana would then incorporate/update its valgrind package.

I'm asking it here on OI-dev because OI is what I happen to use when observing 
this,
but has anyone perhaps seen this/or already fixed it perhaps ?

Thanks,
David Stes

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

We have an open PR for an update on valgrind:
https://github.com/OpenIndiana/oi-userland/pull/5765
Maybe you want to take over?

Regards,
Andreas

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

Re: [oi-dev] OI hipster text iso image

[Andreas Wacknitz]

Am 05.04.21 um 15:16 schrieb Gary Mills:

On Mon, Apr 05, 2021 at 11:28:05AM +0200, Andreas Wacknitz wrote:

The package freeze is necessary on the build server in order to protect
it from illumos-gate problems.
Otherwise the build server would be updated after each successful
jenkins run. It is doing that for most non illumos-gate packages, though.
I have created newer images on April 2nd, 2021 in order to check the new
NVIDIA drivers with the live media today. If there is enough interest I
could provide them on our
download server.

I was told by the illumos developers that OI tracks illumos quite
closely.  Is this no longer the case?

This is still true - every night an illumos-gate build is done by a
jenkins job. If changes had been merged into illumos-gate they will be
packaged by this job.



illumos updates are normally a good thing.  illumos-gate problems are
quite rare, and are fixed quickly when they do occur.  I watch illumos
changes every day.  There are many of them.  All are needed.  All of
them fix problems or add features.

Freezes on illumos-gate are a bad thing in general.  We need all those

The freeze on osnet-incorporation is JUST FOR THE BUILD SERVER!
The build server must be protected because it is run in the cloud. If it
fails we will need help by EveryCity (or its new owners).
So we don't want automatic updates and reboots (on the build server)!
Nevertheless, new packages are being build nightly for illumos-gate and
for every merge to oi-userland. The updates for
oi-userland are automatically installed on the build server as they
might be needed by other packages (remember, we need
a merge order if we have dependent packages). If something bad happens
here we can roll back easily by means of older boot environments.
But this is not possible if we update the build server with a newer
illumos-gate version that fails to boot - we don't have a console for it!

Andreas

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

Re: [oi-dev] OI hipster text iso image

[Andreas Wacknitz]

Am 05.04.21 um 11:18 schrieb s...@pandora.be:

Hi,  are there updated iso images for OI hipster ?

When using OI-hipster-text-20201031.iso

OI-hipster-text-20201031.iso.sha256sum
b4b40dbb2c69eef759e8e6fda5fa262d27ee4867a827c2d77de0f8d42c4f8a5e  
OI-hipster-text-20201031.iso

when I boot from that ISO it reports just before selecting keyboard layout

OpenIndiana Hipster 2020.04 Version

shouldn't that be 2020.10 instead of 2020.04 ?

Is there perhaps a prerelease 2021.04 iso available ?

Thanks,
David Stes

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

Yes, the wrong date is a known issue. When I run distro-const to create
the images I wasn't aware of the freeze of the osnet-incorporation
package on the build server.
Only later I found out that I need to unfreeze it in order to update to
the latest illumos-gate bits with pkg update. Since then I update the
build server regularly after
I have checked that the latest illumos-gate boots my local servers ok.
The package freeze is necessary on the build server in order to protect
it from illumos-gate problems.
Otherwise the build server would be updated after each successful
jenkins run. It is doing that for most non illumos-gate packages, though.
I have created newer images on April 2nd, 2021 in order to check the new
NVIDIA drivers with the live media today. If there is enough interest I
could provide them on our
download server.

Regards,
Andreas

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

Re: [oi-dev] shell/ksh93

[Andreas Wacknitz]

Am 31.03.21 um 08:22 schrieb Aurélien Larcher:



On Tue, Mar 30, 2021 at 11:44 PM Jim Klimov mailto:jimkli...@cos.ru>> wrote:

On March 30, 2021 5:57:11 PM UTC, Gary Mills
mailto:gary_mi...@fastmail.fm>> wrote:
>On Tue, Mar 30, 2021 at 05:53:00PM +0200, s...@pandora.be
 wrote:
>>
>> I think there is no need to do bulk conversion of OpenIndiana
>> packages, due to the change (the commit
>> c063eb990f530561e469b3c1e4bb64230456c0da in illumos-gate).
>
>> Older versions of packages that depend on SUNWcs (core solaris or
>> core system) continue to work fine.
>
>> New versions of packages can modify their manifest and Makefile and
>> require pkg:/shell/ksh93.


Probably just add

REQUIRED_PACKAGES += shell/ksh93

in shared-macros.mk 

If this is not enough then fix the script that generates
REQUIRED_PACKAGES to avoid re-adding in the Makefile dependencies that
have already been listed in the make-rules/*.mk files.



I have integrated this with #6638 after I have checked it locally.

Thanks to all who have contributed to the discussion.

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

Re: [oi-dev] Latest ksh93 changes in illumos-gate have impacts on REQUIRED_PACKAGES

[Andreas Wacknitz]

Am 27.03.21 um 20:04 schrieb s...@pandora.be:

It would help if Andreas clarified which "latest ksh93 changes in illumos-gate" 
are of interest.

Is there something in the latest ksh93 changes that is of interest to 
OpenIndiana ?

For example, security fixes in ksh93 (/bin/sh) could be very important.

As I stated in another message: We take every change that is
incorporated into illumos-gate by a jenkins job that runs during the nights.
There is no manual intervention in this process. OI does only little
patches on illumos-gate sources. You can check it as it is inside our
oi-userland repository under components/openindiana/illumos-gate. What
is inside there will be build nightly by a jenkins job.
That is a major difference from other illumos distributions like OmniOS
or SmartOS.


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

Re: [oi-dev] Latest ksh93 changes in illumos-gate have impacts on REQUIRED_PACKAGES

[Andreas Wacknitz]

Am 27.03.21 um 19:51 schrieb Tim Mooney via oi-dev:

In regard to: Re: [oi-dev] Latest ksh93 changes in illumos-gate have...:


On Sat, Mar 27, 2021 at 09:41:12AM +0100, Andreas Wacknitz wrote:


illumos-gate has recently merged the following changes
    2755 split ksh93 from core package
    13460 ksh93 tests should be moved out of usr/demo
    518 ksh documentation should be moved out of SUNWcsr

This has impacts on our REQUIRED_PACKAGES settings for many packages.
Most, if not all occurrences of
    REQUIRED_PACKAGES += SUNWcs
need to be replaced by
    REQUIRED_PACKAGES += shell/ksh93


Is that really true?  I would have thought that all products would
require SUNWcs, but only ones that included ksh scripts would require
shell/ksh93 .


+1, I was trying to make the same point in the email I just sent.

I don't think *any* SUNWcs should be replaced.  I think shell/ksh93
should be *added* in some places.

gmake REQUIRED_PACKAGES automatically detects most of the dependencies
automatically.
If we update the build server to an osnet version with split ksh93
publishing packages with missing ksh93 dependency will fail.
You can check this on your own system (if updated recently): try to
publish network/bind


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

Re: [oi-dev] Latest ksh93 changes in illumos-gate have impacts on REQUIRED_PACKAGES

[Andreas Wacknitz]

Am 27.03.21 um 19:48 schrieb s...@pandora.be:

The reason why I wrote "top priority" is because in my understanding 
osnet-incorporation
basically is kernel, network stack, filesystems, and device drivers, and
basic userland libraries and applications such as Bourne / Korn shell.

osnet-incorporation is intentionally frozen on the build server.
After every successfull jenkins run (either oi-userland or illumos-gate)
the build server
will be automatically update packages on it if necessary.
In order to prohibit automatic updates of osnet (and automatic reboots)
it is frozen.
Of course from time to time it also needs to be updated but I do that
only if the actual version
is tested on other systems by me. Typically I do that once a week.



So more than any programming language or application or user level library, I 
would think the above needs updating.

However I do not have experience with the implications and overall OpenIndiana 
release engineering.

I learned it the hard way when nobody else was left who was able and
willing to do it.



So I must add that if an update would somehow break OpenIndiana features such 
as the MATE desktop,
the OpenIndiana desktop, then osnet-incorporation cannot be updated,
and then in that case OpenIndiana is stuck with the 'frozen' 
osnet-incorporation.

We build illumos-gate nightly. If any changes have been merged into
illumos-gate you will get it
the next day when you run "pkg update" on your systems. Only the build
server is protected by
freezing osnet-incorporation. Of course, you can do the same but you
should know the implications...

Andreas

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

Re: [oi-dev] Latest ksh93 changes in illumos-gate have impacts on REQUIRED_PACKAGES

[Andreas Wacknitz]

Am 27.03.21 um 16:59 schrieb s...@pandora.be:

The shared-macros.mk in oi-userland/make-rules could do:

shared-macros.mk:REQUIRED_PACKAGES += shell/ksh93

where it is currently doing

shared-macros.mk:REQUIRED_PACKAGES += SUNWcs

Currently on an older OpenIndiana system I have:

$ pkg search /usr/bin/sh
INDEX  ACTION VALUE  PACKAGE
path   link   usr/bin/sh pkg:/SUNWcs@0.5.11-2020.0.1.20038
path   link   usr/bin/sh pkg:/shell/ksh93@93.21.1.20120801-2020.0.1.20424

$ ls -l /bin/sh
lrwxrwxrwx   1 root root   9 Sep 16  2020 /bin/sh -> i86/ksh93

So if a component provides a script with /bin/sh it requires either SUNWcs or 
shell/ksh93.

But the oi-userland/make-rules/shared-macros.mk modification could perhaps deal 
with most cases.

You are right. But probobly I wasn't explicit enough: The main question
is how to deal with
the situation. Changing so many packages would take some time and occupy
the build server for a while.
So maybe it would be better to update the build server to the latest
osnet-incorporation now
and change package dependencies when needed, eg. when we touch a package
anyways.
But that would also render some (all?) actual PR's buggy and they have
to be redone.



- Op 27 mar 2021 om 16:13 schreef gary mills gary_mi...@fastmail.fm:


On Sat, Mar 27, 2021 at 09:41:12AM +0100, Andreas Wacknitz wrote:


illumos-gate has recently merged the following changes
     2755 split ksh93 from core package
     13460 ksh93 tests should be moved out of usr/demo
     518 ksh documentation should be moved out of SUNWcsr

This has impacts on our REQUIRED_PACKAGES settings for many packages.
Most, if not all occurrences of
     REQUIRED_PACKAGES += SUNWcs
need to be replaced by
     REQUIRED_PACKAGES += shell/ksh93

Is that really true?  I would have thought that all products would
require SUNWcs, but only ones that included ksh scripts would require
shell/ksh93 .  The problem is that you can't tell which to change from
the REQUIRED_PACKAGES make variable.  Is there not a default for that
variable?  Maybe adding both packages would be a quick fix, although
it's incorrect in many cases.  Is there a way to determine which
products actually require the shell/ksh93 package?


--
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-

___
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



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

Re: [oi-dev] Latest ksh93 changes in illumos-gate have impacts on REQUIRED_PACKAGES

[Andreas Wacknitz]

Am 27.03.21 um 10:00 schrieb stephan.alth...@duedinghausen.eu:

Hello!
what about a script that recurses the tree and does sinlge small PRs
per package magically?
it is not that simple no?

Probably as I don't know if all occurrences of SUNWcs should/can be
replaced by shell/ksh93.
Still, one could imagine such a script but it would probably need to run
"gmake REQUIRED_PACKAGES" on every package that has SUNWcs as a requirement.
And then it has to make sure that other possible changes are correct
(some more changes might occur as some packages seem to have been
updated without
updating the REQUIRED_PACKAGE settings).

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

[oi-dev] Latest ksh93 changes in illumos-gate have impacts on REQUIRED_PACKAGES

[Andreas Wacknitz]

Hi all,

illumos-gate has recently merged the following changes
    2755 split ksh93 from core package
    13460 ksh93 tests should be moved out of usr/demo
    518 ksh documentation should be moved out of SUNWcsr

This has impacts on our REQUIRED_PACKAGES settings for many packages.
Most, if not all occurrences of
    REQUIRED_PACKAGES += SUNWcs
need to be replaced by
    REQUIRED_PACKAGES += shell/ksh93

This will automatically be done when you run "gmake REQUIRED_PACKAGES"
in an environment that has the changes from illumos-gate.
At the moment our build server has been frozen on an older
osnet-incorporation version:
FMRI:
pkg://openindiana.org/consolidation/osnet/osnet-incorporation@0.5.11-2020.0.1.20416:20210320T012008Z

As soon as this will be updated publishing packages on our build server
need the aforementioned changes for the REQUIRED_PACKAGES.

I am not sure how to handle this as I there are some PR's that will take
a little longer to finish.
Does anybody have an idea or opinion about this?

Regards,
Andreas

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

Re: [oi-dev] No module named 'pkg'

[Andreas Wacknitz]

Am 05.03.21 um 15:10 schrieb Klaus Ziegler:


Hi Stephan,

yes, indeed I haven't run gmake setup in the top-level oi-userland
directory,
what I have done now:
klausz@sunfire % gmake setup
setup components
make[1]: Entering directory '/ws/klausz/oi-userland/components'
/bin/mkdir -p /ws/klausz/oi-userland/sparc/logs
/usr/bin/pkgrepo create file:/ws/klausz/oi-userland/sparc/repo
/usr/bin/pkgrepo add-publisher -s
file:/ws/klausz/oi-userland/sparc/repo userland
/usr/bin/pkgrepo rebuild -s file:/ws/klausz/oi-userland/sparc/repo
Initiating repository rebuild.
building tools...

After that I've built the latest gawk and tried:
gmake sample-manifest <- okay
gmake pre-publish < STILL the SAME ERROR:
ImportError: No module named 'pkg'

My problem is that SPARC does not have a:
/usr/lib/python3.5/vendor-packages directory:
klausz@sunfire % cd /usr/lib/python2.7/vendor-packages/ < - is there :-)
klausz@sunfire % cd /usr/lib/python3.5/vendor-packages
-bash: cd: /usr/lib/python3.5/vendor-packages: No such file or directory

This simply means you are missing Python-3.5 version packages/modules.
We are far ahead with package updates
on i386 and are now working on adding 3.7 and 3.9 package versions.
Python-2.7 is out of support since beginning of this year
and many newer module versions don't support 2.7 anymore. So we have to
either remove Python-2.7 versions or keep the last supported
version for Python-2.7.



that's where I think the "pkg module" lives - right?
how do I build/get this directory - it's not worth symlinking the
python2.7 directory since that is 32bit and the python3.5 installation
is 64bit per default - what to do to migrate userland for SPARC
from python2.7 to python3.5 ?

You can look at our package history. Alexander has been merging many
parts of OmniOS's IPS version with the help of the OmniOS people last year.
When your IPS already tries to use python-3.5 modules you are in a bad
situation and need to find a way to bootstrap the missing modules.


All the SPARC packages (100) which I've already built are done via
a home-gown script which do all the steps by hand rather than
to use "gmake publish" - I allready had a valid repo, which is the
the step done by "gmake setup".

This sounds like a way to bootstrap the missing packages. You should be
aware that you'll also need to update some of your make include files
in oi-userland/make-rules and probably also some template files in
oi-userland/templates and transforms in oi-userland/transforms.

Best regards,
Andreas


Much Regards
Klaus

On 04.03.21 00:13, Stephan Althaus wrote:

On 03/03/21 08:48 PM, Till Wegmueller wrote:

Hi

IPS itself https://github.com/OpenIndiana/pkg5/ or the path in the
components directory

-Till

On 03.03.21 16:38, Klaus Ziegler wrote:

Hi,

I've been able to compile python3.5 on SPARC and wanted to decom
my workaround for building packages in oi-userland, unfortunately

gmake pre-publish still tells me:

Traceback (most recent call last):
   File "/ws/klausz/oi-userland/tools/userland-mangler", line 38,
in 
 import pkg.fmri
ImportError: No module named 'pkg'

can anybody tell me where and what module I have to build to be
able to use
python3.5 to build packages, I hope it's not in the illumos-gate :-(

Much Regards
Klaus

___



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

Re: [oi-dev] openssl and gmake REQUIRED_PACKAGES

[Andreas Wacknitz]

Am 22.02.21 um 22:05 schrieb Tim Mooney via oi-dev:

In regard to: [oi-dev] openssl and gmake REQUIRED_PACKAGES,
s...@pandora.be...:

There's one specific part of this I want to comment upon:


How were the upgrades of openssl done in the past ?

Isn't the easiest way to use the old strategy from the past to
upgrade openssl,
and then (without mediator I suppose) upgrade all packages to the new
openssl ?


No, the new strategy is (in my opinion) a huge improvement over the old
strategy.

Because of the huge list of packages that depend upon openssl, in the
past when there was a breaking ABI change in openssl, the only way to
upgrade was to undertake a massive effort to upgrade openssl + all
dependencies at once.  It was a huge barrier for all but the most
experienced packagers.  I looked at updating openssl last year and once
I saw what was involved, I gave up and went on to other tasks.

With the new mediator-based approach, it's much easier to upgrade
dependencies in smaller chunks.  It also puts us in a better place for
when OpenSSL 3.0 is released, as packages can be migrated to that slowly
over time while both 1.1.x and 3.0.x are supported.

I hope that a few other libraries with huge dependencies (I'm looking at
you, library/icu) can eventually be converted to the mediator approach.
It makes it possible to move dependencies to a new version in phases,
rather than having to do it all at once.

I'm very thankful that Aurélien made this improvement to our
openssl package.

Tim

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

Alas the situation is a little bit more complex. The mediator-approach
helps with it but we still have a lot of work.
- First, we have a few packages that adhere to what USE_OPENSSL11 and
openssl's pkgconfig files tell them.
These packages can be converted easily by incrementing the
COMPONENT_REVISION, setting USE_OPENSSL11=yes,
and run gmake publish to update the package's pkg5 file.
Some of these packages have already been merged.

- Then we have the majority of packages that also need the mediator
version of openssl set to 1.1 (on our build server AND on all client
machines) to work properly.
This happens when the package's configuration system ignores (partially)
openssl's pkgconfig settings, eg. for libcrypto pkgconfig looks like this:
prefix=/usr/openssl/1.1
exec_prefix=${prefix}
libdir=${exec_prefix}/lib/
includedir=${prefix}/include
enginesdir=${libdir}/engines-1.1

If libdir is being ignored the mediator version settings come into
place, which is the case for the majority of all packages.
(I have learned recently that the mediator approach is neither suitable
nor intended for mediating .so files the way we would need.)

- We also have some packages that don't like openssl-1.1 at all (most of
them are outdated) and need additional work.
- We also have some more packages with all kinds of different problems,
like linking against openssl version 1.1 and 1.0.0 simultaneously.

The bulk merge of most of the updated packages is necessary because we
have lots of packages with multiple indirect dependencies on openssl
(eg. other libraries).
Thus, we cannot (should not) update at different times because that will
likely create problems.

Andreas

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

Re: [oi-dev] gcc builds - no cc1objplus

[Andreas Wacknitz]

Am 22.02.21 um 13:38 schrieb Klaus Ziegler - owner of sunfreeware.de:

Hi,

is there any reason why we don't provide cc1objplus compiler in gcc
builds?

Most probably because nobody uses it and if we merge it into OI Hipster
we will have to support it.
Thus, additional work and not much gain.



--- Makefile.orig    2021-02-21 21:09:30.515646158 +
+++ Makefile    2021-02-21 21:17:44.199125768 +
@@ -47,7 +47,7 @@
 CONFIGURE_OPTIONS+= --enable-plugins
 CONFIGURE_OPTIONS+= --enable-objc-gc
 CONFIGURE_OPTIONS.i386+= --enable-initfini-array
-CONFIGURE_OPTIONS+= --enable-languages=c,c++,fortran,lto,objc
+CONFIGURE_OPTIONS+= --enable-languages=c,c++,fortran,lto,objc,obj-c++
 CONFIGURE_OPTIONS+= --disable-libitm
 CONFIGURE_OPTIONS+= enable_frame_pointer=yes

maybe just forgotten? however including it does not harm at all,
and the tests for it also work fine:

        === obj-c++ tests ===


Running target unix/-m64

        === obj-c++ Summary for unix/-m64 ===

# of expected passes        1451
# of expected failures        10
# of unsupported tests        77

Running target unix/-m64/-msave-args

        === obj-c++ Summary for unix/-m64/-msave-args ===

# of expected passes        1451
# of expected failures        10
# of unsupported tests        77

        === obj-c++ Summary ===

# of expected passes        2902
# of expected failures        20
# of unsupported tests        154

Much Regards
Klaus

___
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] openssl and gmake REQUIRED_PACKAGES

[Andreas Wacknitz]

There are quite some packages that need the mediator settings and don‘t adhere 
to what pkgconfig tells them. I only migrate unproblematic packages atm and 
collect the ones that need the mediator settings in a separate branch that will 
be merged after we set the mediator on the build server.

Regards,
Andreas

Von meinem iPhone gesendet

> Am 21.02.2021 um 18:44 schrieb s...@telenet.be:
> 
> 
> Hi,
> 
> As a test, I compiled Squeak (Smalltalk-80) with openssl-11.
> 
> For more info on Squeak also see the Hipster handbook:
> http://docs.openindiana.org/handbook/community/squeak/index.html
> 
> Squeak has a loadable and optional plugin for SSL;
> the core kernel package (called squeak-nodisplay) and then plugins
> (squeak plugins for SSL, for pulseaudio etc.)
> 
> The squeak-nodisplay works for a headless Smalltalk environment with 
> -nodisplay,
> and it has no dependency on OpenSSL.  But squeak itself (with all the 
> plugins) depends on OpenSSL.
> 
> Basically Squeak is already being built on some platforms with openssl 1.1,
> some of the Squeak developers use Linux with openssl 1.1, so I expected few 
> problems.
> 
> The good news is that when I set
> 
>  pkg set-mediator -V 1.1 openssl
> 
> I can compile squeak and it seems to use openssl 1.1.
> 
> But this is because I set the mediator, and maybe I misunderstood previous 
> postings here,
> but I think I read the plan is exactly that it should NOT be necessary to set 
> the mediator.
> 
> When I build in oi-userland the component and then type
> 
>   gmake REQUIRED_PACKAGES
> 
> it adds openssl-11 (because it discovers a dependency, I suppose).
> 
> Now this is a basic question, but I wonder whether it is now the goal
> to update the required dependency so that this package manifest
> (or manifest of any other packages), so that it has openssl-11 as dependency 
> or what is the plan ?
> 
> Also I wonder whether I should have 2 components :  squeak for openssl 1.0.2
> and squeak for openssl 1.1  or just make the transition and drop support for 
> openssl 1.0.2 ?
> 
> Also isn't this something where a GIT branch for oi-userland could be used ?
> 
> How were the upgrades of openssl done in the past ?
> 
> Isn't the easiest way to use the old strategy from the past to upgrade 
> openssl,
> and then (without mediator I suppose) upgrade all packages to the new openssl 
> ?
> 
> I'm posting this to this list as squeak is just an example,
> I suppose it's relevant to all packages.
> 
> Regards,
> David Stes


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

Re: [oi-dev] gcc/gmp assembler integration

[Andreas Wacknitz]

Am 19.02.21 um 09:36 schrieb Klaus Ziegler - owner of sunfreeware.de:

Hi,

I'm currently compiling gcc-7.5.0-il-0 on SPARC in oi-userland,
while this fact isn't SPARC only, I'm a little bit puzzled about it.
If you do a "make build" and watch the configure process in
the first gmp subdir you'll see the following:

configure: creating cache ./config.cache
checking build system type... i386-pc-solaris2.11
checking host system type... none-pc-solaris2.11 <--- ?

4 lines later:
configure: WARNING: using cross tools not prefixed with host triplet

again 6 lines later there happens a real mess:
configure: WARNING: the "none" host is obsolete, use --disable-assembly
checking ABI=standard

this "--disable-assembly" line shouldn't apear at all and it should say
checking ABI=32, or if you are compiling gcc-10 ABI=64.
To bring it to the point, all of this also happens on gcc-10!
It looks like that the whole thing gmp is about - "doing assembly
acceleration" isn't given trough to all of our oi-userland gcc builds!
If you have a look in directory: build/i86/gmp/mpn after configure
has finished it's work, you won't see any *.asm links into the gmp
sources, this of course proves that non of the assembler code will
be used in this gmp build.
The problem is the top-level Makefile.in in the gcc source tree,
I'm sure that the speed of modern x86 systems is the source
of the problem that nobody has seen this before, if you do work
on a 20 year old Ultra60 you have more of chance to see this :-)
I think, the reason that the top-level Makefile.in is designed this way,
is the fact that gcc can be cross-compiled, which we won't do at all
in any of gcc oi-userland builds.
I've written patches for gcc-7 and gcc-10 to remediate this, I'm
fairly new to OI processes, so I just don't know how to integrate
a change like this, while I did my best to get the brand10 bug fixed
in ticket #13562, shall I just open a new ticket for this and don't
assign it to myself? or what shall I do? - I just need someone to take

The best way to get things integrated is to create PR's (pull requests)
against oi-userland and wait for comments resp. requests for changes.
In the past people have fixed problems on SPARC by creating PR's that
have been merged by the oi-userland maintainers.
The only thing we request for SPARC related changes: either proof or
convince us that it doesn't harm the x64 builds.
If your changes also involve x64 we can check more easily (eg. albeit I
have old US-III SPARC machines, I only run x64 with OpenIndiana).

I can assure you that all kinds of PR's will be highly appreciated!

I assume that you already cloned our OpenIndiana/oi-userland github
repository into your own
and thus are familiar with the general PR process. If not, I can help
you with it (even in German if you prefer that).

For your concrete problem I would wait until alarcher finds some spare
cycles. He is our specialist in that area. He may have some comments.
Anyway, if you provide a PR it will be easier to discuss and understand
the issues you have detected.


me by the hand and guide me. If someone want's to try out the
patches I've done, please reply to me and I'm more than happy
to provide them, I just didn't attach them to bother anybody in
the community. BTW. the performace gain on such an old SPARC
is really sensible :-)

Please try to use the PR process (accompanied with bug tickets). As I
wrote above: if you need any help to get there, feel free to ask.
With PR's it's a lot easier (read: less work) for the maintainers.

Best regards,
Andreas

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

Re: [oi-dev] Fwd: Re: requests-37

[Andreas Wacknitz]

Am 17.02.21 um 19:17 schrieb Nona Hansel:

Hello again,

since I have installed new versions today, I get the same warning
every time I use pkg.

/usr/lib/python3.7/vendor-packages/requests/__init__.py:91:
RequestsDependencyWarning: urllib3 (1.25.1) or chardet (4.0.0) doesn't
match a supported version!
  RequestsDependencyWarning)

But it looks like the version 2.25.1 could work with chardet 4.0.0:
https://github.com/psf/requests/blame/master/setup.py#L44

Can I try to update requests to this version or was there a particular
reason why to have 2.22?

I don't know, alarcher may have an answer.

If you create a PR for a newer request version make sure that it support
Python 2.7 or else you'll need to split the package into one for Python
2.7 and another one for Python 3 versions.

Regards,
Andreas




Regards,
Nona

-- Původní e-mail --
Od: Nona Hansel 
Komu: OpenIndiana Developer mailing list 
Datum: 17. 2. 2021 10:22:26
Předmět: Re: [oi-dev] requests-37


I'm trying to fix it and the requests publishes and locally
installs fine, but when I try to use it in python3.7:

>>> import requests

I get this message:
/usr/lib/python3.7/vendor-packages/requests/__init__.py:91:
RequestsDependencyWarning: urllib3 (1.25.1) or chardet (4.0.0)
doesn't match a supported version!
  RequestsDependencyWarning)

When I ask pipdeptree, it gives me this:

requests==2.22.0
  - chardet [required: >=3.0.2,<3.1.0, installed: 4.0.0]
  - idna [required: >=2.5,<2.9, installed: 2.10]
  - urllib3 [required: >=1.21.1,<1.26,!=1.25.0, installed: 1.25.1]

It looks like the version of chardet and maybe idna are outside of
requests' scope of supported versions. Is there a way how to make
requests use the previous versions?
Thank you!

-- Původní e-mail --
Od: Aurélien Larcher 
Komu: OpenIndiana Developer mailing list 
Datum: 16. 2. 2021 18:57:38
Předmět: Re: [oi-dev] requests-37


Probably I messed up the rebase and -$(PYV) is missing from the
manifest in the fmri.

On 2/16/21, Nona Hansel  wrote:
>
> Hello,
>
>
>
>
> I'm trying to install requests-37 which according to it's
Makefile we
> should
> provide, but when I ask for it:
>
>
>
>
> $ pfexec pkg info -r library/python/requests*
>
>
>
>
> it doesn't show it nor it shows requests-39.
>
>
>
>
> It can't be found here:
> https://pkg.openindiana.org/hipster/en/search.shtml?
> action=Search=requests-37=1
>
> and when I try to find requests-35 in this website, it finds
the previous
> version.
>
>
>
>
> Isn't there something wrong with this component?
>
>
>
>
> Thank you,
>
> Nona
>


--
---
Praise the Caffeine embeddings

___
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


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

Re: [oi-dev] OpenSSL update process

[Andreas Wacknitz]

Am 07.02.21 um 14:09 schrieb Aurélien Larcher:



On Sun, Feb 7, 2021 at 1:21 PM Andreas Wacknitz mailto:a.wackn...@gmx.de>> wrote:

Am 06.02.21 um 21:56 schrieb Aurélien Larcher:


OpenSSL 1.1 is now merged:

1. The mediator is default set to 1.0 but can be safely set to 1.1.
2. illumos-gate is patched to accept library/security/openssl-11
as dependency so that it builds when the mediator version is 1.1.
3. oi-userland has now a switch USE_OPENSSL10=yes or
USE_OPENSSL11=yes which should be placed before shared-macros.mk
<http://shared-macros.mk> is included.
4. If 'gmake update' is executed in a component depending on
OpenSSL then the switch is made to OpenSSL 1.1 unless
USE_OPENSSL10=yes is set.

Now the fun begins:

3. Move all the components supporting OpenSSL 1.1 or update
them.
4. Deprecate possible rotting components which cannot be
updated and may cause security issues.


and... the more, the merrier!


Cheers


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

Hi,

do we have a problem with missing engine files in the openssl-11
package?

╰─➤  cat /usr/openssl/1.1/lib/pkgconfig/libcrypto.pc
prefix=/usr/openssl/1.1
exec_prefix=${prefix}
libdir=${exec_prefix}/lib/
includedir=${prefix}/include
enginesdir=${libdir}/engines-1.1

Name: OpenSSL-libcrypto
Description: OpenSSL cryptography library
Version: 1.1.1i
Libs: -L${libdir} -lcrypto
Libs.private: -lsocket -lnsl -ldl -pthread
Cflags: -I${includedir}

So, libcrypto.pc states that there shall be
/usr/openssl/1.1/lib/engine files but there aren't any (same for
64-bit):


It seems like they did not bother to remove the enginesdir variable
from the .pc file if engines are not built...

We could ship an empty directory or patch the .pc files but if you
think that it is better to ship the engines we can do that also.
I do not really know who consumes them...


I don't know, too. But letting a .pc file pointing to something
non-existing is the worst way imo.
Best would probably be to ship them where they are expected.

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

Re: [oi-dev] OpenSSL update process

[Andreas Wacknitz]

Am 07.02.21 um 14:17 schrieb Aurélien Larcher:



On Sun, Feb 7, 2021 at 1:21 PM Andreas Wacknitz mailto:a.wackn...@gmx.de>> wrote:

Am 06.02.21 um 21:56 schrieb Aurélien Larcher:


OpenSSL 1.1 is now merged:

1. The mediator is default set to 1.0 but can be safely set to 1.1.
2. illumos-gate is patched to accept library/security/openssl-11
as dependency so that it builds when the mediator version is 1.1.
3. oi-userland has now a switch USE_OPENSSL10=yes or
USE_OPENSSL11=yes which should be placed before shared-macros.mk
<http://shared-macros.mk> is included.
4. If 'gmake update' is executed in a component depending on
OpenSSL then the switch is made to OpenSSL 1.1 unless
USE_OPENSSL10=yes is set.

Now the fun begins:

3. Move all the components supporting OpenSSL 1.1 or update
them.
4. Deprecate possible rotting components which cannot be
updated and may cause security issues.


and... the more, the merrier!


Cheers


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

Hi,

do we have a problem with missing engine files in the openssl-11
package?

╰─➤  cat /usr/openssl/1.1/lib/pkgconfig/libcrypto.pc
prefix=/usr/openssl/1.1
exec_prefix=${prefix}
libdir=${exec_prefix}/lib/
includedir=${prefix}/include
enginesdir=${libdir}/engines-1.1

Name: OpenSSL-libcrypto
Description: OpenSSL cryptography library
Version: 1.1.1i
Libs: -L${libdir} -lcrypto
Libs.private: -lsocket -lnsl -ldl -pthread
Cflags: -I${includedir}

So, libcrypto.pc states that there shall be
/usr/openssl/1.1/lib/engine files but there aren't any (same for
64-bit):

╭─andreas@skoll /usr/openssl/1.1/lib/pkgconfig
╰─➤  ls -l /usr/openssl/1.1/lib
total 7445
lrwxrwxrwx   1 root root   1 Feb  6 11:17 32 -> ./
lrwxrwxrwx   1 root root   5 Feb  6 11:17 64 -> amd64/
lrwxrwxrwx   1 root root  12 Feb  6 11:17 CA.pl ->
../bin/CA.pl*
drwxr-xr-x   3 root sys    7 Feb  6 11:17 amd64/
lrwxrwxrwx   1 root root  16 Feb  6 11:17 libcrypto.so
-> libcrypto.so.1.1*
-r-xr-xr-x   1 root bin  2947532 Feb  6 11:17
libcrypto.so.1.1*
lrwxrwxrwx   1 root root  13 Feb  6 11:17 libssl.so ->
libssl.so.1.1*
-r-xr-xr-x   1 root bin   748144 Feb  6 11:17 libssl.so.1.1*
drwxr-xr-x   2 root sys    5 Feb  6 11:17 pkgconfig/

"pkg contents openssl-11" doesn't show any engine files in the
package.


Maybe unrelated to this: At the moment I try to build remmina with
openssl-1.1 but it fails to link:

[100%] Linking C executable remmina
Undefined            first referenced
 symbol                  in file
ERR_load_crypto_strings
CMakeFiles/remmina.dir/remmina_stats_sender.c.o
ERR_free_strings CMakeFiles/remmina.dir/remmina_stats_sender.c.o
ld: fatal: symbol referencing errors. No output written to remmina


Could it be that libcrypto and libssl are linked in the wrong order or
that you need to repeat one of the libs in the list?

I don't seem to have control over it. At least not obviously. I have to
investigate further.



Unlike GNU ld our ld does not try to be smart and reorder the libs (in
a possibly disastrous way).

I have heard of it before but wasn't thinking of that.

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

Re: [oi-dev] OpenSSL update process

[Andreas Wacknitz]

Am 06.02.21 um 21:56 schrieb Aurélien Larcher:


OpenSSL 1.1 is now merged:

1. The mediator is default set to 1.0 but can be safely set to 1.1.
2. illumos-gate is patched to accept library/security/openssl-11 as
dependency so that it builds when the mediator version is 1.1.
3. oi-userland has now a switch USE_OPENSSL10=yes or USE_OPENSSL11=yes
which should be placed before shared-macros.mk
 is included.
4. If 'gmake update' is executed in a component depending on OpenSSL
then the switch is made to OpenSSL 1.1 unless USE_OPENSSL10=yes is set.

Now the fun begins:

3. Move all the components supporting OpenSSL 1.1 or update them.
4. Deprecate possible rotting components which cannot be updated
and may cause security issues.


and... the more, the merrier!


Cheers


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

Hi,

do we have a problem with missing engine files in the openssl-11 package?

╰─➤  cat /usr/openssl/1.1/lib/pkgconfig/libcrypto.pc
prefix=/usr/openssl/1.1
exec_prefix=${prefix}
libdir=${exec_prefix}/lib/
includedir=${prefix}/include
enginesdir=${libdir}/engines-1.1

Name: OpenSSL-libcrypto
Description: OpenSSL cryptography library
Version: 1.1.1i
Libs: -L${libdir} -lcrypto
Libs.private: -lsocket -lnsl -ldl -pthread
Cflags: -I${includedir}

So, libcrypto.pc states that there shall be /usr/openssl/1.1/lib/engine
files but there aren't any (same for 64-bit):

╭─andreas@skoll /usr/openssl/1.1/lib/pkgconfig
╰─➤  ls -l /usr/openssl/1.1/lib
total 7445
lrwxrwxrwx   1 root root   1 Feb  6 11:17 32 -> ./
lrwxrwxrwx   1 root root   5 Feb  6 11:17 64 -> amd64/
lrwxrwxrwx   1 root root  12 Feb  6 11:17 CA.pl -> ../bin/CA.pl*
drwxr-xr-x   3 root sys    7 Feb  6 11:17 amd64/
lrwxrwxrwx   1 root root  16 Feb  6 11:17 libcrypto.so ->
libcrypto.so.1.1*
-r-xr-xr-x   1 root bin  2947532 Feb  6 11:17 libcrypto.so.1.1*
lrwxrwxrwx   1 root root  13 Feb  6 11:17 libssl.so ->
libssl.so.1.1*
-r-xr-xr-x   1 root bin   748144 Feb  6 11:17 libssl.so.1.1*
drwxr-xr-x   2 root sys    5 Feb  6 11:17 pkgconfig/

"pkg contents openssl-11" doesn't show any engine files in the package.


Maybe unrelated to this: At the moment I try to build remmina with
openssl-1.1 but it fails to link:

[100%] Linking C executable remmina
Undefined            first referenced
 symbol                  in file
ERR_load_crypto_strings CMakeFiles/remmina.dir/remmina_stats_sender.c.o
ERR_free_strings CMakeFiles/remmina.dir/remmina_stats_sender.c.o
ld: fatal: symbol referencing errors. No output written to remmina

Regards,
Andreas

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

Re: [oi-dev] OpenSSL update process

[Andreas Wacknitz]

Am 07.02.21 um 08:39 schrieb Tim Mooney via oi-dev:
In regard to: Re: [oi-dev] OpenSSL update process, Aurélien Larcher 
said...:



If /usr/include/openssl does not point anywhere probably the mediator is
not set to a right version or openssl-11 is not installed:

narval> pkg mediator openssl
MEDIATOR    VER. SRC. VERSION IMPL. SRC. IMPLEMENTATION
openssl local 1.1 local  openssl

narval> ls -lha /usr/include/openssl
lrwxrwxrwx 1 root staff 30 Feb  5 22:54 /usr/include/openssl ->
../openssl/1.1/include/openssl


I've just updated my build box again and something is still not correct
for me.

$ pfexec pkg verify -v openssl-11
PACKAGE STATUS
pkg://openindiana.org/library/security/openssl-11 OK

$ pkg info library/security/openssl-11
 Name: library/security/openssl-11
  Summary: OpenSSL - a Toolkit for Transport Layer (TLS v1+) 
protocols

   and general purpose cryptographic library
 Category: System/Security
    State: Installed
    Publisher: openindiana.org
  Version: 1.1.1.9
   Branch: 2020.0.1.0
   Packaging Date: February  6, 2021 at 03:06:14 AM
Last Install Time: February  6, 2021 at 10:56:16 PM
 Size: 10.75 MB
 FMRI: 
pkg://openindiana.org/library/security/openssl-11@1.1.1.9-2020.0.1.0:20210206T030614Z

   Source URL: http://www.openssl.org/source/openssl-1.1.1i.tar.gz
  Project URL: http://www.openssl.org/

$ pkg mediator openssl
MEDIATOR    VER. SRC. VERSION IMPL. SRC. IMPLEMENTATION
openssl local 1.1 local  system

$ ls -alh /usr/include/openssl
/usr/include/openssl: No such file or directory

$ pkg contents openssl-11 | egrep 'include' | egrep -v '\.h$'
usr/include/openssl

I'm not sure why I'm not getting /usr/include/openssl, but it's not
present.

I've been considering that it may be a good idea to rebuild my build box
anyway, I might try that in the next couple days.  I was part way through
building perl 5.30.1 and updating the perl modules when the pandemic
lockdown started, so my build box is in a bit of a weird state for perl.
I don't see how that would be causing problems for openssl, but a fresh
build box wouldn't hurt.

Tim

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

Hi,

I am not sure what is wrong on your machine, but here works everything 
as expected:


╭─andreas@skoll ~
╰─➤  gls -dl /usr/include/openssl
lrwxrwxrwx 1 root root 30 Feb  7 11:21 /usr/include/openssl -> 
../openssl/1.0/include/openssl

╭─andreas@skoll ~
╰─➤  pfexec pkg set-mediator -V 1.1 openssl
    Packages to change:   1
   Mediators to change:   1
   Create boot environment:  No
Create backup boot environment: Yes
PHASE  ITEMS
Updating modified actions  20/20
Updating package state database Done
Updating package cache   0/0
Updating image state    Done
Creating fast lookup database   Done
Updating package cache   2/2
╭─andreas@skoll ~
╰─➤  gls -dl /usr/include/openssl
lrwxrwxrwx 1 root root 30 Feb  7 11:26 /usr/include/openssl -> 
../openssl/1.1/include/openssl


Regards,
Andreas

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

Re: [oi-dev] texlive package

[Andreas Wacknitz]

Am 27.01.21 um 17:19 schrieb s...@pandora.be:

I have the impression that there is interest in a tex or texlive package,
in the OI repository.

Also there were already several IPS packages created apparently,
in the past, such as the OmniOS and/or many others,
and there's likely to be advanced TeX users reading this list.

This is not so strange, as TeX programming is quite advanced,
I think many users compile their own TeX from sources (as I do),
and TeX also has a "full set of tools" to "program" TeX,
and Perl programs to convert all sorts of formats into/from TeX.

I don't think it requires testing to see whether TeX or TeXlive builds,
compiles and/or works on OI.

The question is rather whether the OI repository has to offer it,
and whether someone who would work on it,
is not doing the work to then find out the pull request would be rejected.

Note that offering OpenIndiana tex or texlive is not obvious,
as then it requires storage (space) and,
someone to support TeX in the future, although the last issue,
is probably not that hard, since TeX is very mature, or very stable.

It may be a better choice to have an independent source or repository,
outside of OpenIndiana, offering the package

Such as https://www.opencsw.org/

In fact if OI would carry TeX in its repository, that version would likely
"compete" in some sense with the opencsw version,

To my knowledge opencsw provides packages for Solaris 10 and earlier.
Having our own TeXLive packages would be a big win. We already have a
package that
depends on libsynctex which we added separately.


as OI users would then have an easy way to install TeX from the OI repo.

Currently on the github page of OpenIndiana I see one project:

https://github.com/OpenIndiana/oi-userland/projects

there is one project called GCC

Would it be possible for someone who has the necessary permissions,
to open a project on github oi-userland called TeX ?

Done.
Now you have to fill it with (tex)life :D

Andreas

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

Re: [oi-dev] Plan for openssl update

[Andreas Wacknitz]

Am 14.01.21 um 22:09 schrieb Aurélien Larcher:



On Thu, Jan 14, 2021 at 10:02 PM Chris mailto:oi...@bsdos.info>> wrote:

On 2021-01-14 12:33, Aurélien Larcher wrote:
> Hello,
> I have just run the tool for creating a build plan for openssl.
>
> The stages, with each -- denoting a required intermediate
update, are:
>
> narval> gmake print-dependents-plan FMRI=library/security/openssl
> library/openssl/openssl-1.0.2
> --
> cluster/libesmtp
> database/freetds
> database/mariadb-101
> database/mariadb-103
> database/mongodb-34
> desktop/gftp
> desktop/hexchat
> desktop/pulseaudio
> desktop/synergy
> encumbered/rtmpdump
> library/botan
> library/gnome-vfs
> library/gsoap
> library/ldns
> library/libarchive
> library/libcouchbase
> library/libneon
> library/libp11
> library/libssh2
> library/libtorrent
> library/libvncserver
> library/trousers
> library/uwimap
> library/xmlsec
> mail/isync
> mail/mutt
> mail/postfix
> network/bind
> network/irssi
> network/lftp
> network/ntp
> network/openldap
> network/openssh
> network/openvpn
> network/proftpd
> network/rsync
> network/slrn
> network/socat
> network/vpnc
> openindiana/ca-certificates
> perl/net-ssleay
> print/cups
> python/python27
> python/python35
> python/python37
> python/python39
> ruby/ruby-23
> ruby/ruby-26
> runtime/erlang
> shell/mosh
> sysutils/borgbackup
> sysutils/ipmitool
> sysutils/snort
> sysutils/stunnel
> tcl/tcltls
> web/ejabberd
> web/elinks
> web/haproxy
> web/httping
> web/links
> web/lynx
> web/nginx
> web/php/php-7_0-ext-mongodb
> web/php/php-7_3-ext-mongodb
> web/w3m
> web/wget
> x11/mesa
> --
> database/postgresql-10
> database/postgresql-11
> database/postgresql-12
> database/postgresql-95
> database/postgresql-96
> desktop/e/efl
> desktop/freerdp
> encumbered/ffmpeg
> library/lasso
> library/libevent2
> library/libgit2
> library/serf
> mail/fetchmail
> mail/sendmail
> network/openconnect
> network/samba
> python/cryptography
> python/m2crypto
> python/pyopenssl
> runtime/squeak4
> runtime/squeak5
> runtime/squeak5c
> sysutils/net-snmp
> sysutils/nmap
> web/apache24
> web/curl
> web/lighttpd
> x11/x11vnc
> --
> database/couchdb-21
> database/mongodb-40
> database/percona-server-56
> database/percona-server-57
> database/pgadmin
> database/pgbouncer
> database/postgresql-11-citus
> database/postgresql-12-citus
> desktop/libreoffice
> desktop/remmina
> desktop/transmission
> developer/rust
> encumbered/gst-plugins-bad1
> library/libetpan
> network/asterisk
> network/pdns-recursor
> network/tor
> python/pycurl
> sysutils/bacula
> sysutils/clamav
> sysutils/nut
> sysutils/virtualbox
> web/apache2-modules/mod_auth_mellon
> web/php/php-7_0
> web/php/php-7_3
> --
> Required installation: []
>
> However do you see any package that we could happily deprecate
in the
> process? ;)
I'm not sure what IO's policy is. But, given python2x went EOL
upstream.
You could eliminate python/python27 from the list. Which, given
all the
packages that _depend_ on it, would make the list even smaller. ;-)


Indeed :) I wish the theory would apply here :)
There are a bunch of packages depending on python-27 and I'd be happy
to drop them if I knew nobody uses them :D


At least all our nodejs packages depend on python-27 (build dependency).
All newer python versions have problems with one tool that is used
during the build process.


>
> Kind regards,
>
> Aurélien
>
--Chris
--



--
---
Praise the Caffeine embeddings

___
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] Plan for openssl update

[Andreas Wacknitz]

Am 14.01.21 um 21:33 schrieb Aurélien Larcher:

Hello,
I have just run the tool for creating a build plan for openssl.

The stages, with each -- denoting a required intermediate update, are:

narval> gmake print-dependents-plan FMRI=library/security/openssl
library/openssl/openssl-1.0.2
--
cluster/libesmtp
database/freetds
database/mariadb-101
database/mariadb-103
database/mongodb-34
desktop/gftp
desktop/hexchat
desktop/pulseaudio
desktop/synergy
encumbered/rtmpdump
library/botan
library/gnome-vfs
library/gsoap
library/ldns
library/libarchive
library/libcouchbase
library/libneon
library/libp11
library/libssh2
library/libtorrent
library/libvncserver
library/trousers
library/uwimap
library/xmlsec
mail/isync
mail/mutt
mail/postfix
network/bind
network/irssi
network/lftp
network/ntp
network/openldap
network/openssh
network/openvpn
network/proftpd
network/rsync
network/slrn
network/socat
network/vpnc
openindiana/ca-certificates
perl/net-ssleay
print/cups
python/python27
python/python35
python/python37
python/python39
ruby/ruby-23
ruby/ruby-26
runtime/erlang
shell/mosh
sysutils/borgbackup
sysutils/ipmitool
sysutils/snort
sysutils/stunnel
tcl/tcltls
web/ejabberd
web/elinks
web/haproxy
web/httping
web/links
web/lynx
web/nginx
web/php/php-7_0-ext-mongodb
web/php/php-7_3-ext-mongodb
web/w3m
web/wget
x11/mesa
--
database/postgresql-10
database/postgresql-11
database/postgresql-12
database/postgresql-95
database/postgresql-96
desktop/e/efl
desktop/freerdp
encumbered/ffmpeg
library/lasso
library/libevent2
library/libgit2
library/serf
mail/fetchmail
mail/sendmail
network/openconnect
network/samba
python/cryptography
python/m2crypto
python/pyopenssl
runtime/squeak4
runtime/squeak5
runtime/squeak5c
sysutils/net-snmp
sysutils/nmap
web/apache24
web/curl
web/lighttpd
x11/x11vnc
--
database/couchdb-21
database/mongodb-40
database/percona-server-56
database/percona-server-57
database/pgadmin
database/pgbouncer
database/postgresql-11-citus
database/postgresql-12-citus
desktop/libreoffice
desktop/remmina
desktop/transmission
developer/rust
encumbered/gst-plugins-bad1
library/libetpan
network/asterisk
network/pdns-recursor
network/tor
python/pycurl
sysutils/bacula
sysutils/clamav
sysutils/nut
sysutils/virtualbox
web/apache2-modules/mod_auth_mellon
web/php/php-7_0
web/php/php-7_3
--
Required installation: []

However do you see any package that we could happily deprecate in the
process? ;)

Kind regards,

Aurélien

--
---
Praise the Caffeine embeddings

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

I have nothing to remove, but at least database/couchdb-21 and
library/libcouchbase don't build here.
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Missing locale zh_CN.GB18030

[Andreas Wacknitz]

Am 11.01.21 um 15:47 schrieb Nona Hansel:

Hi,

I'm trying to update findutils.  Some test are skipping because I
don't have zh_CN.GB18030 locale on my system. How can I get it?
pfexec pkg info -r doesn't work for me in this case.
Thank you in advance.
Nona

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

Hi,

it looks like locale/zh_cn-extra has the needed files:
╰─➤  pkg contents zh_cn-extra
PATH
usr
usr/lib
usr/lib/locale
usr/lib/locale/zh_CN.GB18030
usr/lib/locale/zh_CN.GB18030/LC_COLLATE
usr/lib/locale/zh_CN.GB18030/LC_COLLATE/LCL_DATA
usr/lib/locale/zh_CN.GB18030/LC_CTYPE
usr/lib/locale/zh_CN.GB18030/LC_CTYPE/LCL_DATA
usr/lib/locale/zh_CN.GB18030/LC_MESSAGES
usr/lib/locale/zh_CN.GB18030/LC_MESSAGES/LCL_DATA
usr/lib/locale/zh_CN.GB18030/LC_MONETARY
usr/lib/locale/zh_CN.GB18030/LC_MONETARY/LCL_DATA
usr/lib/locale/zh_CN.GB18030/LC_NUMERIC
usr/lib/locale/zh_CN.GB18030/LC_NUMERIC/LCL_DATA
usr/lib/locale/zh_CN.GB18030/LC_TIME
usr/lib/locale/zh_CN.GB18030/LC_TIME/LCL_DATA

What I did was
pkg list -a|grep locale\/zh_cn

and then grepping for GB18 in the contents of resulting packages. The
2nd grep found it
pkg contents locale/zh_cn | grep GB18
pkg contents locale/zh_cn-extra|grep GB18


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

Re: [oi-dev] How many CPUs does OI support?

[Andreas Wacknitz]

Am 08.01.21 um 17:15 schrieb Chris:

On 2021-01-08 01:17, Joshua M. Clulow via oi-dev wrote:

On Thu, 7 Jan 2021 at 23:53, Chris  wrote:

I'm looking to help building packages. Both current, as
well as newer versions. I have a large server farm. But
primarily BSD based. As such I'm looking into a new build
box, based on an Opteron or Xeon. So before I take the
plunge. I was hoping to add as many CPU/cores as possible.
Which begs the question: haw many CPUs does OI support?


I don't think you'll be able to buy a machine with more CPUs than we
support in illumos.  I've personally used older HP machines with 4 CPU
sockets and thus a lot of cores, and modern AMD systems which have a
still surprising number of cores in one or two packages.

In the unlikely event that you hit a problem based on core count, I am
sure it will just be a bug that can be fixed.

OK so 4 sockets @16 cores/ea, or 2 sockets @64 cores/ea won't be a
problem then.
Thanks for the reply! :-)
Time to go shopping.


--Chris



Cheers.



Tell us when your server exceeds 384 Cores / 3072 Threads. AFAIK that's
what actual Fujitsu/Oracle M12 provide at max. :D


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

Re: [oi-dev] NodeJS update

[Andreas Wacknitz]

Am 31.12.20 um 17:09 schrieb Carsten Grzemba via oi-dev:

any plans for update NodeJS? Firefox 78esr requires version 10.21 or
newer.
--
Carsten


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


╰─➤  pkg list -a|grep nodejs
runtime/nodejs (openindiana.org) 0.12.18-2020.0.1.3 --r
runtime/nodejs-10 (openindiana.org) 10.23.0-2020.0.1.0 ---
runtime/nodejs-12 (openindiana.org) 12.20.0-2020.0.1.0 ---
runtime/nodejs-14 (openindiana.org) 14.15.3-2020.0.1.0 i--
runtime/nodejs-6 (openindiana.org) 6.17.1-2020.0.1.1  --r
runtime/nodejs-7 (openindiana.org) 7.10.1-2018.0.0.2  --o
runtime/nodejs-8 (openindiana.org) 8.17.0-2020.0.1.1  --r

What are you missing? We provide nodejs-10.23.0, 12.20.0 and 14.15.3.
All of them the latest supported versions.

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

Re: [oi-dev] 3 versions of squeak-4 with slightly different timestamps

[Andreas Wacknitz]

Am 24.12.20 um 09:17 schrieb s...@pandora.be:

Hi,

It seems there is a problem with my squeak-4 package,
or perhaps with the package building scripts at OpenIndiana (jenkins?)

Squeak is a descendent of Smalltalk-80.

squeak-4 runs Squeak "V3" images (downloaded by the command 'inisqueak') and Cuis 
"V3" images.

For those interested, I'm also attaching a screenshot of a Test Runner in 
Squeak-4,
which succesfully runs 3721 Smalltalk tests ...

The problem is there are now 3 versions of the squeak-4 with slightly different 
timestamps:

http://pkg.openindiana.org/hipster/en/advanced_search.shtml?token=squeak-4=p=1=50==Advanced+Search

runtime/squeak-4@4.19.3,5.11-2020.0.1.0:20201223T174316Z Install
 Manifest
runtime/squeak-4@4.19.3,5.11-2020.0.1.0:20201223T183515Z Install
 Manifest
runtime/squeak-4@4.19.3,5.11-2020.0.1.0:20201223T184321Z Install
 Manifest

It is possible that I have introduced somehow an error in my manifest,
which causes or (accidentally) triggers this, but I don't see what ...

In my own oi-userland build (repository 'userland') I do not see this (and I do 
not have this problem).

Regards,
David Stes

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

That happened because the original jenkins run failed. I manually
published it on the build server and
when I merged the next PR it got published again by jenkins.
Sometimes there are build failures for no apparent reasons. A second run
typically succeeds.

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

Re: [oi-dev] Python components

[Andreas Wacknitz]

Am 18.11.20 um 17:59 schrieb Nona Hansel:

Hi,

I'm thinking about updating two Python packages - tqdm and colorama.
Currently, there is variable PYTHON_VERSIONS= 3.5 in both Makefiles
which means, if I understand it correctly, that the package is build
for Python 3.5.

I wonder if I should let this variable like this or should I increase
Python version. If so, to what version? Or should we have more
versions at the same time?
Thank you,
Nona


Hi Nona,

PYTHON_VERSIONS expects a space separated list of versions, eg.
PYTHON_VERSIONS= 3.5 3.7 3.8
For colorama this is accompanied by the special manifest file
colorama-PYVER.p5m. PYVER is replaced by any member of the
PYTHON_VERSIONS list.
BTW: In cases like this it is helpful to search for similar cases, eg. with
  find . -name Makefile | xargs grep PYTHON_VERSIONS
from within the components/python (or even from components) folder. It
can also be interesting to read the macros in the make-rules folder (eg.
grep there for PYTHON_VERSIONS to find references).

Hope this helps,
Andreas

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

Re: [oi-dev] I'm taking a break

[Andreas Wacknitz]

Am 08.09.20 um 17:36 schrieb Alexander Pyhalov via oi-dev:

Hi, guys.

I wasn't sure if this should be a public message, but when I understood that CC 
list reached > 5 persons, decided to send it here.

Briefly, I'm taking a break.
This doesn't mean that I'll not be able to answer your questions or that I will 
not commit anything to OI repos - I don't know. But for now I'm changing my job 
and likely will relocate to Moscow in near future. Given that's new position is 
a new area for me, I'll just have  no time for such time-consuming hobby as OI.

I'm still excited about OI and illumos. It was a wonderful experience, but for 
now our ways parted.
Good luck. You can always reach me via my gmail account.

Best regards,
Alexander Pyhalov,
(still) system administrator of Southern Federal University IT department

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

Hi Alexander,

sad to hear that, but understandable. Good luck for the next time,
especially for your new job.

Who is left with access to the build system? I "only" have commit rights
but nothing else...

Regards,
Andreas

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

Re: [oi-dev] couchdb-21 seems to need be rebuild, removed or upgraded

[Andreas Wacknitz]

Am 12.08.20 um 21:25 schrieb Alexander Pyhalov via oi-dev:

Hi.
The issue is with netaddr-27 module, have to check why it depends on ipython.

From what I understand netaddr has an interactive shell that's based on
ipython.


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

[oi-dev] couchdb-21 seems to need be rebuild, removed or upgraded

[Andreas Wacknitz]

Hi,

my build systems are stuck in the past because there seems to be a
problem with couchdb-21, eg. on my desktop machine:
╰─➤  pfexec pkg install -nv pkg://openindiana.org/database/couchdb-21 1 ↵
Creating Plan (Running solver): -
pkg install: No matching version of database/couchdb-21 can be installed:
  Reject:
pkg://openindiana.org/database/couchdb-21@2.1.1-2020.0.1.1:20200601T200510Z
  Reason:  No version matching 'require' dependency
library/python/netaddr-27 can be installed
    
    Reject:
pkg://openindiana.org/library/python/netaddr-27@0.7.10-2020.0.1.0:20200330T154852Z
    Reason:  All acceptable versions of 'require' dependency on
library/python/ipython-27@5.0.0-2020.0.1.2 are obsolete
    

Am I right?

Regards,
Andreas

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