Re: [oi-dev] perl and Symbol.3 manpage
Maybe I should add that on Illumos the files are: https://illumos.org/man/3/all and https://illumos.org/man/3PERL/all - Op 11 feb 2023 om 18:01 schreef s...@pandora.be s...@telenet.be: > I believe that the runtime/perl-534 and package runtime/perl-536 package a > file > > /usr/share/man/man3/Symbol.3 > > This can be verified with : pkg contents runtime/perl-534 | grep Symbol > > Should this file be in man3 ? > > There also exists a /usr/share/man/man3perl > > But that directory seems to be empty for me. > > I'm not sure what the OpenIndiana conventions are for putting files in man3/ > > Perhaps on older versions of OpenIndiana the file was only in > usr/perl5/5.xx/man/man3/Symbol.3 > > where 5.xx is the release like 5.34 and 5.36 without linking or copying into > /usr/share/man/man3 itself. > > > I'm asking because a different software is also trying to put a file Symbol.3 > in > /usr/share/man/man3, > and I've noticed that since a while it complains about the Perl file in man3. > > Regards, > David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] perl and Symbol.3 manpage
I believe that the runtime/perl-534 and package runtime/perl-536 package a file /usr/share/man/man3/Symbol.3 This can be verified with : pkg contents runtime/perl-534 | grep Symbol Should this file be in man3 ? There also exists a /usr/share/man/man3perl But that directory seems to be empty for me. I'm not sure what the OpenIndiana conventions are for putting files in man3/ Perhaps on older versions of OpenIndiana the file was only in usr/perl5/5.xx/man/man3/Symbol.3 where 5.xx is the release like 5.34 and 5.36 without linking or copying into /usr/share/man/man3 itself. I'm asking because a different software is also trying to put a file Symbol.3 in /usr/share/man/man3, and I've noticed that since a while it complains about the Perl file in man3. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] SUnit and gmake test on OpenIndiana
- Op 1 nov 2022 om 19:37 schreef Tim Mooney via oi-dev oi-dev@openindiana.org: > That's atypical, and not really desirable behavior. OK, then at least we seem to agree here that the oi-userland "design philosophy" is, that the tests should be ran from BUILD_DIR. That is, the idea seems to be that after 'gmake build' and *before* copying to the prototype area, the tests are supposed to be ran from the software that is still in the build directory, before it is copied to the prototype directories (with gmake install). The way I was looking at it I thought it was more logical to run it from the prototype area, but that is clarified now, and it is just a convention. > Is there an environment variable that can be overridden during the test, > to point squeak at the directory/directories that contain the > *uninstalled* plugins? Yes. I was already using SQUEAK_PLUGINS to point to the prototype area. Now that you have confirmed that the idea is to run the tests from BUILD_DIR, what I just did was: SQUEAK_PLUGINS=$BUILD_DIR/plugin1:$BUILD_DIR/plugin2:$BUILD_DIR/plugin3: fortunately SQUEAK_PLUGINS accepts a : separated path of directories like LD_LIBRARY_PATH. > Requiring that something be "installed" (even though in this case it's > being copied into a staging area for packaging) before it can be tested > is backwards. The vast majority of open source software does not do that, > and OI's targets are set up to assume the more common behavior of being > able to test before anything has been installed. So using that solution to set SQUEAK_PLUGINS to point to the various plugin directories in the build area, it works. I am just trying to understand what the "design philosophy" of gmake test is for OpenIndiana. With the solution to point SQUEAK_PLUGINS to the various plugin directories in the build directory, like that, I can run Smallltalk from the BUILD_DIR before it is fully 'installed' in the prototype area. Please note that SUnit the testing framework are thousands of tests, and it is also a framework that is extensible. http://sunit.sourceforge.net Most of the SUnit tests are higher level application level tests. So for example if additional plugins or applications under Smalltalk are loaded, the SUnit framework changes and gets extended with additional tests. Anyway, I had been hoping that the "gmake test" could be interfaced to "SUnit". And indeed this seems to 'kind of work'. Thanks anyway for clarifying how "gmake build" "gmake test" and "gmake install" relate. David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] SUnit and gmake test on OpenIndiana
Setting COMPONENT_TEST_CMD to a script which start squeak and runs the SUnit test suite seems to work. However the oi-userland framework seems to implicitely assume that gmake test triggers an automatic build (there is a dependency .tested : .built ) gmake build and then run the tests from the BUILD_DIR. For OpenSmalltalk this works, but for Squeak it cannot find its plugin directory when started from the build directory to load loadable plugin modules. So for Squeak as a workaround it is still necessary to run gmake install to stage the plugins to the prototype area from where they can be loaded. The test target in the oi-userland framework is not so well documented, and I find it somewhat hard to see how this is used. I think (and maybe should document this somewhere) that the usual approach is: gmake build gmake test then see whether there are any differences Then finally gmake install gmake publish However in the case of Squeak the 'gmake install' should be done before the 'gmake test'. That is not how the make-rules seem to be set up. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] SUnit and gmake test on OpenIndiana
After another look at the make-rules, I think what could work is setting COMPONENT_TEST_CMD to a script that runs the Squeak testrunner instead of something like "gmake" (which is the default COMPONENT_TEST_CMD). For the moment simply running: gmake build gmake install followed by "gmake test" will work but for me 'gmake test' fails if I don't first 'gmake install' the newly built VM binaries into the prototype directory. - Op 30 okt 2022 om 6:42 schreef Tim Mooney via oi-dev oi-dev@openindiana.org: > In regard to: Re: [oi-dev] SUnit and gmake test on OpenIndiana,...: > >> - Op 29 okt 2022 om 13:24 schreef Aurélien Larcher >> aurelien.larc...@gmail.com: >> >>> I think the target that does the diff is test-compare, but the test target >>> will >>> call it and do the comparison if a result file is present. >>> >>> Tests are not automatically run on the build server. >> >> I think the test target only calls the code to run 'diff' when using GNU >> autoconf configure style Makefiles. > > Many of the "build style" macro files define targets for > '.tested-and-compared' and '.tested'. You're correct that configure.mk > defaults to having rules for running a test suite, because projects that > use autoconf-generated configure scripts almost universally generate a > Makefile that has a 'test' target, even if it does nothing. > > It appears that "squeak" doesn't define any build style currently, so it's > using the base set of targets, with customization and addition directly in > squeak's Makefile. > > It's possible you could define a BUILD_STYLE (before the inclusion of > shared-macros.mk, see other components that do this) for something more > specific. Does squeak use Cmake? BUILD_STYLE=cmake. Does it just use > a Makefile, with no configure process? BUILD_STYLE=justmake. > > It all depends on how squeak is built, but using a more specific > BUILD_STYLE may get you the macro set that defines all of the > test-related setup you need. > > 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
Re: [oi-dev] SUnit and gmake test on OpenIndiana
Thanks for your feedback and advice regarding this issue. It's a good suggestion to try to set BUILD_STYLE=cmake, because Squeak uses cmake, but Squeak before switching to cmake, used to use GNU configure (autoconf). There is a 'configure' script which is used in my OpenIndiana component Makefile. So the build style is 'custom configure script'. Anyway I tried setting BUILD_STYLE and it does not change the fact that before running 'gmake test', I have to run 'gmake build' and 'gmake install'. This is not a big problem for me, and the nice thing is that the Sunit test results are ran and saved in test/result-32.master This convention to save the results in the result-.master file is already a big help to check test results. Thanks, David Stes - Op 30 okt 2022 om 6:42 schreef Tim Mooney via oi-dev oi-dev@openindiana.org: > In regard to: Re: [oi-dev] SUnit and gmake test on OpenIndiana,...: > >> - Op 29 okt 2022 om 13:24 schreef Aurélien Larcher >> aurelien.larc...@gmail.com: >> >>> I think the target that does the diff is test-compare, but the test target >>> will >>> call it and do the comparison if a result file is present. >>> >>> Tests are not automatically run on the build server. >> >> I think the test target only calls the code to run 'diff' when using GNU >> autoconf configure style Makefiles. > > Many of the "build style" macro files define targets for > '.tested-and-compared' and '.tested'. You're correct that configure.mk > defaults to having rules for running a test suite, because projects that > use autoconf-generated configure scripts almost universally generate a > Makefile that has a 'test' target, even if it does nothing. > > It appears that "squeak" doesn't define any build style currently, so it's > using the base set of targets, with customization and addition directly in > squeak's Makefile. > > It's possible you could define a BUILD_STYLE (before the inclusion of > shared-macros.mk, see other components that do this) for something more > specific. Does squeak use Cmake? BUILD_STYLE=cmake. Does it just use > a Makefile, with no configure process? BUILD_STYLE=justmake. > > It all depends on how squeak is built, but using a more specific > BUILD_STYLE may get you the macro set that defines all of the > test-related setup you need. > > 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
Re: [oi-dev] SUnit and gmake test on OpenIndiana
- Op 29 okt 2022 om 13:24 schreef Aurélien Larcher aurelien.larc...@gmail.com: > I think the target that does the diff is test-compare, but the test target > will > call it and do the comparison if a result file is present. > > Tests are not automatically run on the build server. I think the test target only calls the code to run 'diff' when using GNU autoconf configure style Makefiles. That is not the case for Squeak VM; which unfortunately also requires a little user input, you have to type in your code initials when running the Squeak VM classical VM tests after running 'gmake test'. In OpenSmalltalk 'gmake test' is fully automatic and requires no interactive input, but still, there is a significant risk I think that the Smalltalk environment requires some interactive input, when running thousands of tests. But if the tests are not automatically ran on the build server then it's not a problem. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] how to change local build repo prefix
There is a variable PUBLISHER and CONSOLIDATION in shared-macros.mk which is set to userland. I haven't tried setting PUBLISHER to something else, or maybe I once tried, I can't remember, perhaps setting PUBLISHER=squeak to publish in a repo specifically for squeak. However I wonder why you'd want to set PUBLISHER to openindiana.org. I suppose you could publish a custom package in userland and install it, or use a publisher name, which is different in any case from openindiana.org. If the package is 'locked' into openindiana.org consolidations you could try to change-facet as reported by pkg facet for example unlock squeak with version-lock.runtime.smalltalk.squeak=False - Op 29 okt 2022 om 12:59 schreef Stephan Althaus stephan.alth...@duedinghausen.eu: > Hello! > > > I can't remember how to change the local repo prefix from userland to > openindiana.org > > My goal is to build illumos-gate and install the packages to test a > patch for bug #15128 > > I've done that myself several years ago but it seems i can't find the > information :-/ > > Any hints are welcome :-) > > > 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
[oi-dev] SUnit and gmake test on OpenIndiana
I'm trying to add some modifications to my oi-userland component Makefile (for Squeak/Smalltalk) to run the SUnit tests. What I did was add some interface so that : gmake build gmake install gmake test in the component directory of OpenSmalltalk stack-spur runs the SUnit tests and saves the output in results-64.vm which can be compared to results-64.master However it is to me unclear when reading the oi-userland/make-rules/common.mk whether there exits a target gmake test-and-diff or whether gmake test is supposed to run the COMPONENT_TEST_DIFF_CMD itself. Also the configure.mk rules seem to automatically trigger a "gmake install" when running "gmake test" which would be useful. Finally if/when adding tests for the components, are those tests automatically ran on the build server itself please ? Thanks David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] COMPONENT_TEST_TRANSFORMS for PARI
http://docs.openindiana.org/dev/userland/ requires an update to first define "test" as a TARGET because test is not listed in the table after "To build a component you simply cd into the directory of the software, and type "gmake TARGET" (here we use gmake to call GNU make), where TARGET can be one of:" some targets are listed but "test" is not one of them. Further down there is just one paragraph as documentation about the whole process: "It's advised to put the expected test ouput in test/results-BITS.master (where BITS are either 32 or 64) and to ensure that the gmake test target generates reproducible results. You can use the COMPONENT_TEST_TRANSFORMS variable to set a list of sed directives to transform the test output and make it reproducible." This is not entirely correct as BITS can also be "all" instead of 32 or 64. Also from your reply I understand that there are 2 usages: 1) run "gmake test" to run a set of tests 2) run "gmake test" to run a test-and-compare if test/results-BITS.master already exists So basically "gmake sample-test" something like that could create an empty tests/results-BITS.master, just like "sample-manifest" is creating a sample manifest. - Op 14 okt 2022 om 1:53 schreef Tim Mooney via oi-dev oi-dev@openindiana.org: > In regard to: [oi-dev] COMPONENT_TEST_TRANSFORMS for PARI, s...@pandora.be...: > >> Because PARI/gp is using its own Configure do I have to define >> COMPONENT_TEST_TRANSFORMS to remove all compile/build output ?? > > Probably. Whenever I wanted to have comparable test results for > a component, I found it easiest to use a filter to delete everything > up to the start of the tests, and then additional filters to remove > anything that would be system-specific or variable within the tests > (e.g. timing for test runs, dates and times, system name, etc.). > >> I am not sure the documentation on oi-userland build is sufficient >> regarding to "gmake test". > > Especially for someone just starting out, the current documentation > alone is probably not enough. You're not a beginner, but even you > have run into questions. > > When I was starting out, I got good help from Alexander, Michal, Aurelien, > etc. Most of the time the help was pointing me at an existing example in > a different component, that did something similar to what I needed to do > for the component I was stuck on. > > What might be useful is for you to inventory the components that have > test output for comparison (under various possible names), and then check > the Makefile for these to find what COMPONENT_TEST_TRANSFORMS are in > place. That should give you a lot of examples to start with. I know that > for the perl components I worked on and any libraries, I tried to > make certain there was a comparison file for the test suite. > >> Any suggestions ? > > If I was updating a component that didn't have a test comparison file yet, > I would start by creating an empty one, via something like > > touch test/results-all.master > > (or a BITS-specific variant or alternate output name). > > I would generally then start running the test suite, tweaking the > COMPONENT_TEST_TRANSFORMS to filter out more of the output, and manually > updating the starting comparison file. Frequently this involved saving > "diff" output and adding it to the comparison file while stripping the > diff markers like "+" at the beginning of a line and line-number markers. > > As long as you're familiar with the "diff" format, it's pretty easy, and > if you have a bunch of components to update the repetition will get you > to the point where you're very comfortable with the process. > > 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
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
I think that the idea is to keep using "mkdocs 1.0.4' for the moment due to some Theme issue. According to the website https://www.mkdocs.org/about/release-notes/ the current release is mkdocs 1.4.0 which is not tested/required for OpenIndiana documentation. However the good news is that the release-notes state that mkdocs 1.0 supported python 3.7 It states "Officially support Python 3.7." for release 1.0 The version that is required is the one from 2018 : https://www.mkdocs.org/about/release-notes/#version-104-2018-09-07 My understanding that this version is required could be wrong, but it is due to the discussion about Themes. Also there was a PR (pull request) that was rejected in the past from somebody who tried to update mkdocs to version 1.2.3. But I think that there is actually no reason to use Python 2.7 for mkdocs 1.0.4. In fact the requirement for the "futures" package may be due to the fact that it can run on python 2.7 but requires the help from "futures" to do so ? Regards David Stes - Op 30 sep 2022 om 20:29 schreef Bob Friesenhahn bfrie...@simple.dallas.tx.us: > On Fri, 30 Sep 2022, s...@pandora.be wrote: > >> For example in my Vagrantfile I have a comment about a missing 2.7 'futures' >> component: >> >> https://github.com/OpenIndiana/vagrantfiles/blob/main/oi-docs/Vagrantfile >> >> # there used to be a futures package in the repo ... >> # library/python/futures seems to have a problem now >>pfexec pkg install -v \ >> git lynx links\ >> library/python/futures \ >> library/python/mkdocs \ >> developer/documentation-tool/mdl >> # as of 21/9/2021 futures IPS is missing so install by pip >> pfexec pip install futures >> >> Because such "pip install" actions print a clear warning by Python that we >> are >> using an unsupported Python 2.7, it is clear that something must be done. > > The "futures" package is intended to allow Python 2.7 code to be > "soft" ported to Python 3. It is a bridge to Python 3. As such, it > is important for any Python code yet to be ported to Python 3, or > might execute with either version. > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > > ___ > 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] FLAG-DAY: We started to obsolete python 2.7 and 3.5
Part of the problem is, I think, that there is no maintainer any longer, as far as I know, for the mkdocs component in oi-userland. If someone knows how to build mkdocs with python 3 (which is perhaps possible, I don't know, I have no experience with building python components) then this would solve most of the problem, I think ... Thanks for your work on this, because as I confirmed, there are indeed really issues with the mkdocs python2.7. Several people related to the oi-docs are aware that we have a Python 2.7 problem, but we are unsure how to fix it, I think. For example in my Vagrantfile I have a comment about a missing 2.7 'futures' component: https://github.com/OpenIndiana/vagrantfiles/blob/main/oi-docs/Vagrantfile # there used to be a futures package in the repo ... # library/python/futures seems to have a problem now pfexec pkg install -v \ git lynx links\ library/python/futures \ library/python/mkdocs \ developer/documentation-tool/mdl # as of 21/9/2021 futures IPS is missing so install by pip pfexec pip install futures Because such "pip install" actions print a clear warning by Python that we are using an unsupported Python 2.7, it is clear that something must be done. Such as the work on Python 3.9 now, which is now in OpenIndiana the default thanks to the latest work ... David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
I sometimes submit documentation updates but I don't know the exact background or history of mkdocs on OpenIndiana. See for the discussion on "what should happen with mkdocs": https://github.com/OpenIndiana/oi-docs/issues/226 There were several contributors who are in favor of using "pip install mkdocs", instead of 'pkg install mkdocs' so that obsoleting 'mkdocs' is not a bad solution. If the IPS package is added again, then I think based on the issue 226 it should remain mkdocs 1.0.4: "So I think it is possible to stay / stick with mkdocs 1.0.4 and simply adapt / rebuild for a newer python version." That is, there are apparently issues with upgrading mkdocs to a newer version at the documentation "Theme" level. Regards, David Stes - Op 30 sep 2022 om 10:00 schreef Marcel Telka mar...@telka.sk: > On Thu, Sep 29, 2022 at 06:46:40PM +0200, s...@pandora.be wrote: >> >> > Based on the rule above we already obsoleted following packages >> > recently: >> > >> ... >> > library/python/mkdocs >> ... >> >> see http://docs.openindiana.org/contrib/getting-started/ >> >> that page says for installing mkdocs: >> >> "For OpenIndiana Hipster, MKDocs and all of it's dependencies have been >> packaged >> and are available in the OI Hipster repository. So, if you're already running >> Hipster, installing MKDocs is as simple as: pkg install mkdocs" > > Okay, I'll add mkdocs back. > > -- > +---+ >| Marcel Telka e-mail: mar...@telka.sk | >|homepage: http://telka.sk/ | > +---+ > > ___ > 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] FLAG-DAY: We started to obsolete python 2.7 and 3.5
For the specific case of library/python/mkdocs which is now obsolete, changing/updating the docs.openindiana.org is a solution. The webpage for documenation specifically says that most operating systems use: "pip install mkdocs" So by removing the documentation on "pkg install mkdocs" this can be solved. - Op 29 sep 2022 om 18:46 schreef stes s...@telenet.be: >> Based on the rule above we already obsoleted following packages >> recently: >> > ... >> library/python/mkdocs > ... > > see http://docs.openindiana.org/contrib/getting-started/ > > that page says for installing mkdocs: > > "For OpenIndiana Hipster, MKDocs and all of it's dependencies have been > packaged > and are available in the OI Hipster repository. So, if you're already running > Hipster, installing MKDocs is as simple as: pkg install mkdocs" > > > also my vagrant image for oi-docs is using the IPS mkdocs package: > > https://github.com/OpenIndiana/vagrantfiles > > I can confirm that there's problems with the mkdocs IPS package as it is based > on the old 2.7 Python. > > 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] FLAG-DAY: We started to obsolete python 2.7 and 3.5
> Based on the rule above we already obsoleted following packages > recently: > ... > library/python/mkdocs ... see http://docs.openindiana.org/contrib/getting-started/ that page says for installing mkdocs: "For OpenIndiana Hipster, MKDocs and all of it's dependencies have been packaged and are available in the OI Hipster repository. So, if you're already running Hipster, installing MKDocs is as simple as: pkg install mkdocs" also my vagrant image for oi-docs is using the IPS mkdocs package: https://github.com/OpenIndiana/vagrantfiles I can confirm that there's problems with the mkdocs IPS package as it is based on the old 2.7 Python. David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG DAY: Default Perl in OpenIndiana is 5.36 now
Seems to work for me ... Updated to perl 5.36 Obviously I didn't have to change anything to pkg mediator system-perl, as I already did that before ... Regards, David Stes - Op 30 aug 2022 om 22:56 schreef Marcel Telka mar...@telka.sk: > Perl 5.36 is default now > > > The default Perl in OpenIndiana switched from version 5.34 to version > 5.36. Perl 5.36 is fully supported now and all additional Perl modules > were rebuilt to properly support Perl 5.36. OpenIndiana currently > provides over 210 additional Perl modules in the package repository. > > Perl 5.34 is still available in repository for your convenience to allow > smooth transition to Perl 5.36. > > All other Perl versions, namely 5.22 and 5.24, were obsoleted because > they reached End of life several years ago. > > > Perl is first class citizen now > --- > > Perl became first class citizen and commands like `man perl` or > `pod2man` now works by default without any additional tweaks with PATH > and/or MANPATH. > > This change affects additional Perl modules too but it will become > visible only after they are rebuilt. Please note that only handful of > additional Perl modules were rebuilt so far. Other modules will be > rebuilt either when they are upgraded, or when new major Perl version is > integrated to OpenIndiana. For example, `man Type::Tiny` already works, > but `man Mojo` does not (yet) and you still need to invoke something > like `MANPATH=/usr/perl5/5.36/man man Mojo` to read the man page. > > In addition, we introduced unversioned runtime/perl package. If you > need any Perl version installed, just install runtime/perl and you are > done. The runtime/perl package will always point to the default Perl > version. Currently it is 5.36. > > > system-perl mediator > > > Unless you really knows what you are doing your system-perl mediator > should be unset. Before update to latest bits your system-perl mediator > should look like this (if your system is recent): > ># pkg mediator system-perl >MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION >system-perl vendor5.34vendor ># > > or like this (if your system is older than ca 2 months): > ># pkg mediator system-perl >MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION >system-perl vendor5.22vendor ># > > If this is not the case and the output of the above command looks > differently, it is higly recommended to switch the system-perl mediator > back to its default state using this command: > ># pkg unset-mediator system-perl > > After you update your machine to latest bits, the system-perl > mediator should automatically switch to version 5.36: > ># pkg mediator system-perl >MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION >system-perl vendor5.36vendor ># > > > illumos-gate nightly > > > The change of default Perl version constitutes a flag-day for people > building illumos-gate on OpenIndiana. > > You should update your env file (illumos.sh) to contain following lines > so runtime/perl-536/module/sun-solaris package is properly built during > illumos-gate nightly: > >export PERL_VERSION="5.36" >export PERL_VARIANT="-thread-multi" >export PERL_PKGVERS="-536" >export BUILDPERL32="#" > > > Thanks. > > -- > +---+ >| Marcel Telka e-mail: mar...@telka.sk | >|homepage: http://telka.sk/ | > +---+ > > ___ > 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 mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Miscellaneous component fixes and migrations
Ah ... that explains it. I was thinking that I had to update the runtime/perl-524 dependency, to runtime/perl-534, now that perl is version 5.34 by default. But for some reason (which I suspect may be due to the ongoing fixes and migrations), "gmake REQUIRED_PACKAGES" is now producing a runtime/perl dependency, which is better than the runtime/perl-524 that it produced in the past. OpenIndiana also offers perl 5.36 optionally. According to perl.org, version 5.36 is the latest so OpenIndiana has excellent perl support. Thanks, David Stes - Op 7 aug 2022 om 16:30 schreef Marcel Telka mar...@telka.sk: > On Sun, Aug 07, 2022 at 03:50:44PM +0200, s...@pandora.be wrote: >> However I think that PARI does not require an update because the dependency >> is >> simply: >> >> depend fmri=pkg:/runtime/perl type=require >> >> which I believe will work automatically for any Perl version, including the >> new >> Perl 5.36. > > ... and this is since ca 2 days ago when I triggered the pari rebuild to > update the perl deps from runtime/perl-524 to runtime/perl: > > https://github.com/OpenIndiana/oi-userland/commit/ec4124604353044e317334b9b12533a9746d37fb > > :-) > > -- > +---+ >| Marcel Telka e-mail: mar...@telka.sk | >|homepage: http://telka.sk/ | > +---+ > > ___ > 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] Miscellaneous component fixes and migrations
I've ran # pkg unset-mediator perl and perl is now simply perl 5.34. With a modified make-rules/common.mk which is doing the include prep.mk as in the past, Squeak 4.19.15 builds fine with my old Makefile. Squeak has no dependency on Perl as far as I know, but I'm also maintaining a package called PARI which uses several Perl scripts. However I think that PARI does not require an update because the dependency is simply: depend fmri=pkg:/runtime/perl type=require which I believe will work automatically for any Perl version, including the new Perl 5.36. Regards, David Stes - Op 6 aug 2022 om 21:50 schreef Marcel Telka mar...@telka.sk: > On Sat, Aug 06, 2022 at 08:06:55PM +0200, s...@pandora.be wrote: >> I'm no Perl expert and I'm not sure whether I had to do this but I manually >> set >> the perl mediator to perl 5.34. >> So the "pkg mediator" for perl reports a "local" VER.SRC for version 5.34. > > This is basic rule of thumb: > > Your "pkg mediator" output should never show "local" unless you have > good reason to use non-default mediator setup. If you are unsure, or do > not know, then you should revert back to system/vendor defaults (using > "pkg unset-mediator ..."). This is true always and for all mediators. > Especially on machines that are used for oi-userland development and/or > building. > > In this particular case I recommend to run "pkg unset-mediator -v perl". > Your current perl setup (mediator manually set to perl 5.34) could cause > some unexpected results in future when we change the default perl to > 5.36, but your system will stay with perl 5.34 even after update. > >> I think that the last good changeset was 522d32b5 and the first bad changeset >> for me was de49ed8c. > > Thanks for this. I'll look at it and propose a fix. I apparently > missed something there. Sorry for that. > > > Regards. > > -- > +---+ >| Marcel Telka e-mail: mar...@telka.sk | >|homepage: http://telka.sk/ | > +---+ > > ___ > 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] Miscellaneous component fixes and migrations
Regarding the various fixes and migrations going on. First of all I should say that I was able to pkg update my system, and that perl-534 and perl-536 are installed. gmake setup of the oi-userland ran fine , and all of the recent PERL updates seem to work fine. I'm no Perl expert and I'm not sure whether I had to do this but I manually set the perl mediator to perl 5.34. So the "pkg mediator" for perl reports a "local" VER.SRC for version 5.34. When I type 'perl --version' obviously it reports 5.34. As gcc I use gcc 7.5 and cmake is at 3.23.3. As explained, Squeak uses nowadays a custom configure script which is not autoconf generated, and it uses cmake. The OpenSmalltalk fork of Squeak is using autoconf configure as Squeak itself used to do, before it abandonded GNU autoconf and started to use cmake. The OpenSmalltalk packages cog-spur and stack-spur build fine and do not have any problem. But the Makefile for Squeak itself continues to report an error. I think that the last good changeset was 522d32b5 and the first bad changeset for me was de49ed8c. There is a change there in the location of make-ruiles/common.mk The file common.mk has a line : include $(WS_MAKE_RULES)/prep.mk It used to be placed at line 31 and it is now moved a little bit further down towards line 56. When I put the include of prep.mk back at line 31 my Makefile (for Squeak) works again, after undoing the move of the include prep.mk statement (and only that). In fact I'd like to submit an update to the Squeak Makefile because there is now a new Squeak VM 4.19.15. I am not sure how to proceed and whether to change my Makefile or ask to review the common.mk change please ? Thanks David Stes - Op 5 aug 2022 om 21:25 schreef Marcel Telka mar...@telka.sk: > On Sun, Jul 31, 2022 at 06:36:49PM +0200, s...@pandora.be wrote: >> Unfortunately today when I ran 'gmake build' or 'gmake install' in the >> components/runtime/smalltalk/squeak directory, >> I get an error : >> >>No rule to make target ... squeak/build/i86/.configured needed by ... >>build/i86/.built >> >> I have tried to check some commits and when I go back in time and checkout >> older >> versions, I am able to build again. >> >> If I go back to 'git checkout a847fb267' it works again. > > I assume it will work with the next changeset (20542be0f) too. It > changed makemaker.mk only and squeak does not use makemaker build style. > > It would be great if you try to bi-sect to find the exact changeset that > caused the build problem. > > -- > +---+ >| Marcel Telka e-mail: mar...@telka.sk | >|homepage: http://telka.sk/ | > +---+ > > ___ > 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] Miscellaneous component fixes and migrations
I'll check again. Thanks, I'll try a new update. I'll try to investigate more what caused the "Squeak" build problem, but as indicated it used to work. The squeak classical VM uses "cmake" and a custom written configure script which is not autoconf generated. Thanks, David Stes - Op 5 aug 2022 om 21:25 schreef Marcel Telka mar...@telka.sk: >> >> If I go back to 'git checkout a847fb267' it works again. > > I assume it will work with the next changeset (20542be0f) too. It > changed makemaker.mk only and squeak does not use makemaker build style. > > It would be great if you try to bi-sect to find the exact changeset that > caused the build problem. > > -- > +---+ >| Marcel Telka e-mail: mar...@telka.sk | >|homepage: http://telka.sk/ | > +---+ > > ___ > 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] Miscellaneous component fixes and migrations
Hi, I'm maintaining a package 'Squeak' (Smalltalk-80 http://squeak.org) which is using 'subversion' (SVN). I think Squeak is one of the very few packages in oi-userland (still) using subversion because the old Smalltalk team had their sources in subversion and these still get occasional updates from time to time. Squeak builds in 32bit and 64bit. I have BUILD_BITS=32_and_64 In practice Squeak is mostly 32bit because many Smalltalk-80 images on the squeak website are 32bit (and I guess Smalltalk-80 dates from the 16bit time). The OpenIndiana 32bit build is important to me - perhaps more for Squeak than for other packages which have moved to 64bit; Squeak also supports 64bit by the way (which is why the build is for both 32 and 64 bit). Unfortunately today when I ran 'gmake build' or 'gmake install' in the components/runtime/smalltalk/squeak directory, I get an error : No rule to make target ... squeak/build/i86/.configured needed by ... build/i86/.built I have tried to check some commits and when I go back in time and checkout older versions, I am able to build again. If I go back to 'git checkout a847fb267' it works again. However I don't know enough of OpenIndiana's build framework to really be able to say whether this is related to the component fixes and migrations. In any case I'd appreciate support for 32bit builds ... Regards, David Stes - Op 23 jul 2022 om 0:33 schreef Aurélien Larcher aurelien.larc...@gmail.com: > Hi everyone, > due to some changes happening in the past 2 years some components needed to be > fixed (for most of them only a Makefile change or migration to newer > Python/Perl). > With Andreas we have worked to fix some of them in the past week as I could > help > a bit. > > However in the process I have found out that 32-bit versions had to be retired > due to missing dependencies (e.g. 32-bit gobject-introspection), or conversion > to 64-bit builds. > So far I have tried to follow dependencies and not to break anything but I > cannot ensure the absence of any side effects... > > Do not hesitate to point out any regression by replying in this thread. > > Kind regards, > > Aurélien > > -- > --- > 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] VLC maintainer ?
- Op 2 mei 2022 om 14:03 schreef Aurélien Larcher aurelien.larc...@gmail.com: > > Historically most multimedia apps were contributed by Alexander and me but > this > does not mean that we own the packages :) > > Feel free to update VLC and do not hesitate to ask for input and > clarification. The ffplay command from the ffmpeg 4.4.1 package works fine for me, on my OpenIndiana hipster system. The VLC package is also an option and VLC also works, there is an upcoming 3.0.18 which is going to be released, but for the moment I have submitted an update to 3.0.17.4. As soon as 3.0.18 is released I can create a new PR to update to VLC 3.0.18. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] VLC maintainer ?
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
[oi-dev] docs update on NWAM
I've submitted a PR (pull request) for some changes for the NetWork Configuration part of the OpenIndiana System Administration handbook. Rephrased some sentences about NWAM. For example NWAM was described as a new approach from OpenSolaris, and that may have been true in 2008, but nowadays it does not make sense to document NWAM as something new, or to refer to OpenSolaris. So removed that. Also documented new things about the "sysding" service and /etc/sysding.conf for changing from Automatic to Manual mode. I've left most of the documentation there "as it was" including the reference to nano /etc/defaultrouter, but I've also added an example using setup_route in the /etc/sysding.conf. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] PARI/GP and PERL_VERSION=5.34
Hi, I'm submitting an update of the (french) Computer Algebra system PARI/GP. https://pari.math.u-bordeaux.fr/ I could set PERL_VERSION=5.34 in the Makefile, but as far as I'm concerned I don't really care whether it uses 5.22, 5.24 or 5.34. My understanding of the comments in makerules/shared-macro.mk is that this will be dealt with at the system level 'globally'. And that there is still the issue https://github.com/OpenIndiana/oi-userland/pull/7733 Frankly I don't really care and I'm not asking for an update of perl. I'm not explicitely setting any PERL_VERSION in my Makefile ... Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Broken Links and outdated pages on OpenIndiana website
Hi, Thanks for looking at these issues with the docs, and with the main website. Perhaps if (or when) a new "release" 2022.04 is made this can be updated ? I put the word "release" between quotes as OpenIndiana is said to not have releases, and use a "rolling release" model but in my opinion the ISO images, for download, correspond roughly to a release, maybe the word "files" is better, indeed it needs some better terminology as you correctly use the words "2021 files". Regards, David Stes - Op 10 apr 2022 om 21:26 schreef James Madgwick ja...@madgwick.xyz: > Hi, > > I've been looking at making some updates to the installation section of > the handbook. While looking at this I noticed some pages of the main > www.openindiana.org website were out of date. Specifically: > > The 'Wiki' item in the 'Documentation' drop down option of the navbar - > this should be removed as the Wiki no longer exists. > > On www.openindiana.org/download/: The links 'How to Upgrade > OpenIndiana' & 'How to Upgrade from OpenSolaris' are broken and the > second of these is probably no longer relevant. Also I suspect the > mention of SPARC is also no longer relevant. The link to 'OpenIndiana > Community HCL' points to the old Wiki, this page now exists in the docs, > the same for 'alternate download sites'. > > On www.openindiana.org/packages/: 'see Wiki' - broken link > > On www.openindiana.org/documentation/faq/: Link to the OSDISC.COM site > which no longer exists. > > On www.openindiana.org/community/getting-involved/: Links for 'get > involved' and 'IRC channel' are broken > > On dlc.openindiana.org: This page has links for 2021.04, the latest > 2021.10 files on this server are linked from the main site. > > On: www.openindiana.org/documentation/release-notes/: It seems these > notes are now stored elsewhere, or should they also be on this page? > > > I think it's just the core OI owners who have access to the source for > this website. I don't believe the source code is on GitHub, otherwise > I'd have created a PR there. > > James Madgwick > > ___ > 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?
- Op 5 apr 2022 om 16:29 schreef gary mills gary_mi...@fastmail.fm: >> # dbus-monitor --system --profile By the way, in my case, I run a MATE desktop and as ordinary user I run dbus-monitor --session not --system. I suppose you are using --system on a server without MATE desktop ... ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What changed between glib versions?
Hi Gary, I think the most difficult thing is to setup a development system (build system) to further test this issue (which is now fortunately solved - for the moment - by the rollback of the glib2 version to 2.62). So that all tools like 'eject' and 'rmmount' and hal and dbus, and media-volume-manager (rmvolmgr) can be built with some debug info. I am not very familiar with dbus and hal but a good overview is at : https://iks.cs.ovgu.de/~elkner/s11/rmmount.html Right now thanks to the 'rollback' or downgrade of glib2 to glib 2.62 the automount of USB devices works fine. On my OpenIndiana system, if I insert a USB device and monitor it with : $ dbus-monitor --session --profile | grep RemoteVolumeMonitor I see events on the dbus-monitor output like : 1. DriveConnected 2. DriveChanged 3. VolumeAdded 4. VolumeMount 5. VolumeChanged 6. MountAdded If a build system with glib2 and debug info is setup by someone then perhaps it is possible to figure out where the "DriveConnected" is happening when the USB removable drive is added. The issue is important I think for users of OpenIndiana who use USB keyboard/mouse as obviously it is not funny if you loose keyboard or mouse access via USB because of this issue ... Anyway I am not really hit by this issue as I use PS/2 mouse/keyboard and because I am not familiar with the dbus/hal/rmvolmgr code my help is minimal I'm afraid, I'm glad to test out future updates on my system ... Regards, David Stes - Op 5 apr 2022 om 16:29 schreef gary mills gary_mi...@fastmail.fm: > On Sun, Apr 03, 2022 at 07:13:45PM -0500, Gary Mills wrote: >> > [...] >> Here's the result with a BE where the USB automount did not work. >> Notice that there are two signals about 60 microseconds apart, and >> nothing more. Notice also that the columns do not align with the >> header: >> >> Script started on April 3, 2022 at 03:05:42 PM CDT >> # dbus-monitor --system --profile >> #type timestamp serial sender destination pathinterface >> member >> # in_reply_to >> sig 1649016387.639814 2 org.freedesktop.DBus:1.60 >> /org/freedesktop/DBus org.freedesktop.DBusNameAcquired >> sig 1649016387.639882 4 org.freedesktop.DBus:1.60 >> /org/freedesktop/DBus org.freedesktop.DBusNameLost > > I suppose the original message contained too much information for > anyone to digest. Consider this instead: The output for a BE where > the USB automount succeeded began with a signal message: > > sig 1648934895.356888 306 :1.2 > /org/freedesktop/Hal/Managerorg.freedesktop.Hal.Manager DeviceAdded > > This is not an actual signal, but a bus message derived from the > signal. Note that the "DeviceAdded" message is entirely absent in the > output from the BE where USB automount did not work. I wonder if a > missing signal is responsible for the failure. > > -- > -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
Re: [oi-dev] What changed between glib versions?
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. 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) VERSION >>>> IFO >>>> 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
Re: [oi-dev] What changed between glib versions?
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 ... 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) VERSION >> IFO >> 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
Re: [oi-dev] What changed between glib versions?
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-- 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
Re: [oi-dev] Mount of USB stick now succeeds
Sorry to report bad news but https://www.illumos.org/issues/14226 is updated again to report that is now NOT working any longer for me ... with # pkg list glib2 NAME (PUBLISHER) VERSIONIFO library/glib2 2.70.0-2022.0.0.0 i-- On the Dell Precision 3640 Tower with xhci driver. The old solution of restarting hal still works for me. I'm using PS/2 keyboard and mouse on the system (PS/2 without hotplug obviously) so I'm not using USB for keyboard and mouse and I'm not so much affected by this issue, but 14226 also is linked to some users who report hotplug keyboard/mouse issues with USB. I should link the issue 14226 also to http://docs.openindiana.org/handbook/community/quikstor/ which claims hal has some difficulties with RDX Quikstor and suggestions there to "Debugging issues with eject and hal" and an interesting overview article https://iks.cs.ovgu.de/~elkner/s11/rmmount.html. Personally I'm only affected when using removable USB storage, and I can live with the solution of restarting hal in that case. I must say that one of the nice features of the Dell Precision design is the availability of legacy PS/2 connectors and those seem to work without problems on OpenIndiana which is a big help for me in the case of keyboard/mouse ... Regards, David Stes - Op 24 mar 2022 om 19:14 schreef stes s...@telenet.be: > I have updated https://www.illumos.org/issues/14226 . USB automount works for > me, > HAL seems to receive now the update of the hardware change correctly. > > > Regards, > David Stes > > - Op 23 mar 2022 om 15:57 schreef gary mills gary_mi...@fastmail.fm: > >> On Wed, Mar 23, 2022 at 11:48:25AM +0100, Andreas Wacknitz wrote: >>> Solaris-userland is >>> at glib-2.70 so they seem to have fixed either hal or glib. >> >> I wonder what they fixed. It would be done with a patch, most likely. >> >> >> >> -- >> -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
Re: [oi-dev] Mount of USB stick now succeeds
I have updated https://www.illumos.org/issues/14226 . USB automount works for me, HAL seems to receive now the update of the hardware change correctly. Regards, David Stes - Op 23 mar 2022 om 15:57 schreef gary mills gary_mi...@fastmail.fm: > On Wed, Mar 23, 2022 at 11:48:25AM +0100, Andreas Wacknitz wrote: >> Solaris-userland is >> at glib-2.70 so they seem to have fixed either hal or glib. > > I wonder what they fixed. It would be done with a patch, most likely. > > > > -- > -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
Re: [oi-dev] Telegram libtdjson.so.1.8.0
I initially simply set GCC_VERSION=11 in my Makefile but that was not sufficient. I had to comment out the GCC_VERSION in the shared-macros.mk because GCC_VERSION was reset to 7. Maybe the include order was wrong, I'll try again. In any case, my Makefile for this component seems to work with gcc-11. It also includes a command line tool tg_cli to connect to telegram (test client). Regards, David Stes - Op 22 mar 2022 om 20:21 schreef Andreas Wacknitz a.wackn...@gmx.de: > 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 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Telegram libtdjson.so.1.8.0
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 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
Re: [oi-dev] Perl 5.34
Based on the comment for PERL_VERSION in oi-userland/makerules/shared-macros.mk I think the idea is to continue to use the 5.22 and 5.24 perl versions, until it is changed system-wide. At least that's how I interpret the comment above PERL_64_ONLY_VERSIONS : # This is the default BUILD version of perl # Not necessarily the system's default version, i.e. /usr/bin/perl PERL_VERSION = 5.22 # Do *not* add 5.34 to PERL_VERSIONS/PERL_64_ONLY_VERSIONS yet. We'll # enable it system-wide once all existing perl modules have been rebuilt # with support for all three current perl versions. PERL_VERSIONS = 5.22 5.24 PERL_64_ONLY_VERSIONS = 5.24 - Op 12 mar 2022 om 11:36 schreef Klaus Ziegler kla...@haus-gisela.de: > 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, but if now and then, a new component > pops up using these old versions, I will never finish that job. > > Please, refrain from using perl-522/524 for new components. > > Thank you very much > Klaus > > P.S. the Makefile patch for postgres-14 attached. > ___ > 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] /usr/libexec/dovecot/anvil crashes immediately
This is true , the manpage warns about some issues with epoll, that occur also on Linux. But I suppose that from a pragmatic point of view, any API has its pro's and con's. So overall I like the fact that Illumos offers the 'epoll feature'. This seems like a feature to me .. not a problem and not something that should be disabled. It works. The OpenSmalltalk VM uses epoll and I find it executes the SUnit tests well, with epoll enabled. From what I understand from the OpenSmalltalk developer, epoll should be preferred over select or poll, when using a large number of connections. That is at least the opinion of some people in the OpenSmalltalk community on Linux. Whereas OpenSmalltalk supports epoll (and I keep it explicitely turned on on OpenIndiana as well), this can be useful for example for games or any application software written in Smalltalk, that handle a large amount of TCP/IP connections. So for example if anyone is investigating issues with large amounts of connections, perhaps it would be interesting to hear about performance differences, between dovecot running with poll and dovecot using epoll. Also if there truly is a problem between epoll and chroot, then it could be an idea as a test to first disable chroot. Regards, David Stes - Op 12 feb 2022 om 23:48 schreef toasterson toaster...@gmail.com: > Hello > > A quick quote I want to have people keep in mind from the epoll manpage > 'man epoll' > > tl;dr epool is for compatibility purposes it is not intended as a full > features replacement. Please do not use it if possible. It works but > there will be dragons. > > ``` > The epoll facility is implemented for purposes of offering >compatibility to and portability of Linux-borne applications; native >applications should continue to prefer using event ports via the >port_create(3C), port_associate(3C) and port_getn(3C) > interfaces. In >particular, use of epoll in a multithreaded environment is > fraught with >peril; even when using EPOLLONESHOT for one-shot events, there > are race >conditions with respect to close(2) that are unresolvable. (For > more >details, see the aborted effort in Linux to resolve this via the >proposed EPOLL_CTL_DISABLE operation.) The event port facility > -- like >the BSD kqueue facility that inspired it -- is designed to deal with >such issues via explicit event source dissociation. > ``` > > Greetings > Till > > On 12.02.22 17:37, Bob Friesenhahn wrote: >> On Sat, 12 Feb 2022, Stephan Althaus wrote: >>> >>> In the snipplet that Mr Al Slater communicated, it looks like there >>> are linux-specific epoll details that are not working with illumos. >>> Apples and apples can be different :-) >> >> This is quite possible. I should mention that I am running Dovecot in a >> zone. I am not quite sure if I am actually using chroot. >> >>> Have a nice day ! >>> P.S. After several weeks of cloudy misty weather the sun is back again >>> here in Germany. Welcome!! >> >> Nice to hear. >> >> Bob > > ___ > 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] /usr/libexec/dovecot/anvil crashes immediately
As I said, I don't know specifically what the issue with DoveCot is, but if disabling chroot() helps, that could also be a good hint to try. Perhaps as an alternative to chroot, dovecot can be ran in a zone. For the component that I maintain (OpenSmalltalk) which is a different component, epoll(5) in OpenIndiana seems to work fine. For example SUnit-Tests, SocketTests etc. all run fine, and epoll() calls are issued. Of course it is possible that OpenSmalltalk is using epoll() in a way that differs from how dovecot is using epoll. - Op 12 feb 2022 om 15:19 schreef Bob Friesenhahn bfrie...@simple.dallas.tx.us: > On Sat, 12 Feb 2022, s...@pandora.be wrote: > >> >> I don't know what the issue or problem with "dovecot" is, >> but regarding Illumos/OpenIndiana epoll support, epoll(5) in >> OpenIndiana/Illumos >> seems to work. > > The problem appeared to be related to being used in > conjunction with chroot(). Have you tried that? > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > > ___ > 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] /usr/libexec/dovecot/anvil crashes immediately
I don't know what the issue or problem with "dovecot" is, but regarding Illumos/OpenIndiana epoll support, epoll(5) in OpenIndiana/Illumos seems to work. For OpenSmalltalk I have in the component Makefile : # epoll(5) seems to work, so use epoll instead of select(3c) CONFIGURE_ENV+= ax_cv_have_epoll=yes CONFIGURE_ENV+= ax_cv_have_epoll_pwait=yes OpenSmalltalk offers (as far as I know) "signal driven nonblocking I/O" with either select or Linux epoll. I reported to the OpenSmalltalk developers (especially to the author of the epoll code in OpenSmalltalk) that it seems to work fine on OpenIndiana. Of course as indicated in the past, there are certainly major differences between Linux and Illumos. For example on OpenIndiana I use "libmapmalloc" which provides a malloc() based on mmap(), because OpenSmalltalk seems to have issues with older malloc() implementations. David Stes - Op 10 feb 2022 om 23:36 schreef Bob Friesenhahn bfrie...@simple.dallas.tx.us: > On Thu, 10 Feb 2022, Stephan Althaus wrote: >> >> o support your investigation, I tried mdb and it says >> >> mdb: target performed exec of /usr/libexec/dovecot/anvil >> *Panic: epoll_ctl(add, 4) failed: Not owner (fd doesn't support epoll)* > > The last time I built dovecot under OmniOS (quite some time ago), it > picked up Linux compatibility functions such as epoll() which were > implemented for Linux system call emulation but did not work in > dovecot. So the solution was to force using the more native poll(2) > instead. > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > > ___ > 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] runpath check in OI pkglint userland check
This PR (pull request) seems fine to me; I can only agree that improving the pkglint tool, without changing it in a incompatible way, should be an improvement. The 32bit path for 64bit bin or 32bit bin in 64bit path checks, are useful, and I like the Solaris and OpenIndiana / OpenSolaris setup for 32bit/64bit paths. Hopefully this feature remains in there. For Smalltalk / Squeak for example, the 32bit binaries for 32bit Smalltalk VM's remain useful, and Squeak is built in both 32bit and 64bit; I would not like having to build Squeak 64bit only, since there are a lot of 32bit Smalltalk images out there which are opened by the 32bit binary. Anyway pkglint enforces the layout of those paths, so pkglint is a great help. Regards, David Stes - Op 7 feb 2022 om 8:39 schreef oi-dev oi-dev@openindiana.org: > the main idea of pkglint userland runpath check is to prevent shipping bins in > package whith runpaths like > > /export/home/user/myprivate/builddir/lib > > wrong architecture like 32bit path for 64bit bin or standard paths which knows > the ldd already. > > > Our pkglint userland checker complains about runpaths which are correct. So we > should update this tool. > > > e.g. > ERROR userland.action001.3 bad RUNPATH, 'opt/SUNWsamfs/bin/archive' includes > '/opt/SUNWsamfs/lib' > ERROR userland.action001.3 bad RUNPATH, 'opt/SUNWsamfs/bin/notify' includes > '/opt/SUNWsamfs/lib' > ERROR userland.action001.3 bad RUNPATH, 'opt/SUNWsamfs/bin/request' includes > '/opt/SUNWsamfs/lib' > these false positives we can get rid off by the version used by > solaris-userland. > https://github.com/OpenIndiana/oi-userland/pull/7710 > > But look deeper there is some more work to do. > This version will not accept runpaths like /usr/gcc/.. and /usr/mariadb/..., > which are correct. > We can allow this paths per default. The most complete solution would be to > allow this paths, if there resolved dependencies for the related bins > > Any thoughts? > -- > Carsten > > ___ > 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] oi-docs contirbution on $HOME/.imf and input method
Great. Thanks. When I compare to the FreeBSD case, they have a chapter 5 on X11 and desktops https://docs.freebsd.org/en/books/handbook/x11/ which is part of their "Part I. Getting Started", although that also in the FreeBSD case there is an overlap with their "Part III. System Administration", their "Chapter 23. Localization - i18n/L10n Usage and Setup" In their 23.2.3. Xorg Setup they have an overlap with their chapter 5. But OpenIndiana's handbook could also divide all of the contents, in smaller chapters in the handbook, but such a reorganisation is a major piece of work. David Stes - Op 23 jan 2022 om 19:07 schreef James Madgwick ja...@madgwick.xyz: > For reference, I've now been merged this and the page can be found > here: https://docs.openindiana.org/handbook/community/inputmethod/ > > I've not looked into handling of keyboard input in OI, but this does > seem like an effective method to manage this. There will be other ways > to do this. One day this content could be moved to somewhere covering > all of the main approaches (as a comprehensive manual would do). But > for now this contribution is certainly appreciated on its own. > > Regards, > James Madgwick > > On Sun, 23 Jan 2022 13:57:07 +0100 (CET) > "s...@pandora.be" wrote: > >> I made some screenshots on how to enable Input methods in MATE and >> the resulting $HOME/.imf file. >> >> My oi-docs pull request documents (with 2 screenshots) how to enable >> IM and the configuration file $HOME/.imf in OpenIndiana, for >> example to configure the Dutch/Belgian input method. >> >> This can be used to enter characters such as ruïne or poëzie in >> Dutch, this is not so common, and I believe not even required in >> Dutch spelling, but you can use and enter a "trema" using IM for >> Dutch using the Belgian keyboard ... >> >> I think the German 'Umlaut" is similar (but no exactly the same) as >> the Dutch trema although its use is probably different. >> >> Anyway - as far as I'm concerned I think the OpenIndiana default not >> to run IM, is perfectly fine ... >> 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] oi-docs contirbution on $HOME/.imf and input method
I made some screenshots on how to enable Input methods in MATE and the resulting $HOME/.imf file. My oi-docs pull request documents (with 2 screenshots) how to enable IM and the configuration file $HOME/.imf in OpenIndiana, for example to configure the Dutch/Belgian input method. This can be used to enter characters such as ruïne or poëzie in Dutch, this is not so common, and I believe not even required in Dutch spelling, but you can use and enter a "trema" using IM for Dutch using the Belgian keyboard ... I think the German 'Umlaut" is similar (but no exactly the same) as the Dutch trema although its use is probably different. Anyway - as far as I'm concerned I think the OpenIndiana default not to run IM, is perfectly fine ... Regards, David Stes ___ 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
I don't know how the docs ("handbook") was made, but I am under the impression
that it attempts to follow the structure of the FreeBSD Handbook.
For FreeBSD there are several parts,
Part I. Getting Started
Part II. Common Tasks
Part III. System Administration
Part IV. Network Communication
Part V. Appendices
They have their ZFS chapter (for FreeBSD) as "Chapter 20. The Z File System
(ZFS)" in part III.
So the pages for the OpenIndiana docs "getting started" and "system
administration" and "network communications" correspond with the Parts of the
FreeBSD handbook; but a division in chapters like FreeBSD is doing, could be a
good idea ...
Regards,
David Stes
- Op 15 jan 2022 om 12:05 schreef James Madgwick ja...@madgwick.xyz:
> 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
Re: [oi-dev] TeX Live doc update
OK but the rolling release is some sort of release. Also note that TeX Live definitely uses years like 2020, 2021 , 2022 as yearly releases. I'm not sure what the /etc/release contents is, but indeed I agree, if required the user should pkg update -f before installing Perl Tk with pkg install tk-perl. That's just what I approximately had in mind when writing "OpenIndiana 2022 or higher". Regards David Stes - Op 12 jan 2022 om 19:12 schreef Andreas Wacknitz a.wackn...@gmx.de: > 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 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] tk-perl
Hi, I just tested a TeXLive 2021 install with: # pkg install -v tk-perl Then as non root user: /scratch/install-tl-20220108$ ./install-tl -gui Click on "Advanced" in the GUI to select a small basic LaTeX scheme, and installed TeXLive. The GUI works fine (as expected). $ pkg list tk-perl NAME (PUBLISHER) VERSIONIFO library/perl-5/tk-perl804.0.36-2022.0.0.0i-- This is very useful addition that makes it easier to install TeXLive using the GUI. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] rrdtool update
I've just created two pull requests for two different components : opensmalltalk stack-spur and opensmalltalk cog-spur. I update those 2 opensmalltalk components by 2 different PR (pull requests). My understanding is that although that one pull requests for two components is perhaps technically possible at the git revision control level, there is a disadvantage at the "jenkins" level for doing so, so although I do not quite know why this is or what the jenkins problem is, but you should create 2 different PR (pull requests) if you update 2 different components ... As to how to correct now the problem, I'm not sure what the best way is. The best solution is not to make this mistake ... But of course it's good to try out an update of some components to see what you should be careful about and like this after a while you'll know how to avoid these issues. David Stes - Op 7 jan 2022 om 21:57 schreef oi-dev oi-dev@openindiana.org: > Hi all, > > I updated rrdtool to latest version 1.7.2 incl. 32-bit and 64-bit perl/lua > bindings. I learnt a lot about the build environment. As a consequence to > successfully publish both 32bit and 64bit binaries and perl/lua bindings > respectively I had to create four *.p5m files which ended up in six packages. > If you have better ideas please share (I still have to learn a lot ;-)). > > > But it seems that I've committed ( [ > https://github.com/OpenIndiana/oi-userland/pull/7525/commits/0a62194cb51c08012031700d7ea6f592593568ac > | 0a62194 ] ) all related changes to my previous github branch (where I added > the tk-perl module). I guess this is wrong :-(. This is reflected in PR#7525. > What is the best method to correct? > > kind regards and thank you for answers in advance, > > Fritz > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Squeak and libjpeg8-turbo
- 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
Re: [oi-dev] Squeak and libjpeg8-turbo
Sorry I meant /usr/include/jpeglib.h ... 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. 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] Squeak and libjpeg8-turbo
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
Re: [oi-dev] Review: PR#7496
Thanks for having a look at the Perl packages. I am not familiar with the build system makefiles for Perl specifically, but as a user I hope a Perl/Tk package can be added and maintained for OpenIndiana ... As Tim Mooney already indicated, for each pull request (PR) on github there is only 1 commit, and in addition to that, a pull request may relate to only 1 (a single) component. For example you cannot have a PR with 1 commit where you change 2 components at once. Regards, David Stes - Op 30 dec 2021 om 20:46 schreef oi-dev oi-dev@openindiana.org: > Dear maintainers, > > could you please review and merge (once ok): > https://github.com/OpenIndiana/oi-userland/pull/7496 > > this adds Perl module Tk (both 332- and 64-bit) to 5.22 and 5.24. > > Thanks a lot, > > Fritz > > PS: I guess now I did the right thing (@Tim thank you once more ;-)) > > > ___ > 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] some Newbie questions
Personally I'd like to request a perl tk package. This can be used for TeXLive on OpenIndiana. Currently the page https://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-dev oi-dev@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 >>> results get stored in the test directory while comparing existing >>> packages with mine). >> >> Create the test directory and within there create (touch) >> >> results-32.master # if your component has a 32 bit build >> results-64.master # if your component has a 64 bit build >> >> there are other possible variants the file could be named, for special >> build conditions. Look through the test directories for the various >> components in oi-userland to get an idea of other possibilities. >> >> Then, add various COMPONENT_TEST_TRANSFORMS to your Makefile, to filter >> out any of the test output that will vary between build systems (PATHs, >> timing, etc.). >> >> Once you have (empty) results files, the test target will
[oi-dev] Squeak and libjpeg9-ijg
Hi, I'm submitting a package called libjpeg9-ijg version 9.4.0. libjpeg is a library from the Independent JPEG Group (http://www.ijg.org) Apparently some contributors to libjpeg software are also reading this mailing list by the way, but I see no libjpeg9 package for OpenIndiana for 9.4.0 so I created one. I know very little of JPEG but my package was to test with Squeak (Smalltalk-80) which can open JPEG images with a plugin. To test JPEG in Squeak the Smalltalk code is documented at http://wiki.squeak.org/squeak/4043 Squeak is currently in the OpenIndiana repo and depends on libjpeg6-ijg and that works with libjpeg6-ijg. But I tested now setting linking against libjpeg9 and that does NOT work : Squeak loads libjpeg.so.9.4.0 but does not display a JPEG image ... (unlike squeak when linked against libjpeg6-ijg). Neither does using libjpeg8-turbo or libjpeg62-turbo work for Squeak. So it seems the Squeak plugin depends on something in libjpeg6-ijg and this needs to be fixed at the Squeak VM level. Nevertheless I'm submitting the libjpeg9-ijg package which may be useful for some other purposes, or in the future for Squeak as well ... Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] elegant way to get leaf packages?
Check pkg exact-install with the --reject option. For example if you have a full install of some group, pkg exact-install --reject somepackage group - Op 26 dec 2021 om 4:36 schreef oi-dev oi-dev@openindiana.org: > I'm just wondering if there is a more clever, or perhaps less intensive > on the publisher server, way to get the same info? ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] elegant way to get leaf packages?
I am not sure I understand your question. Please clarify. However I can add that I once used "pkg exact-install" for something that sounds a little bit like what you are asking. Perhaps this can be used in combination with -n -v dry run verbose. pkg install installs a package pkg exact-install installs a package but removes all "leaf packages" (?) that are not a dependency of the given package. Check the pkg manpage for exact-install. WARNING: always first make a backup BE before testing exact-install because it will remove packages that are not a dependency. I am using (sometimes) exact-install in an attempt to uninstall "recursively" although that's probably the wrong terminology. Regards, David Stes - Op 26 dec 2021 om 4:36 schreef oi-dev oi-dev@openindiana.org: > All- > > Is there an elegant way using pkg (or some other method) to get all > OpenIndiana "leaf" packages, i.e. packages that are not a dependency of > some other package? > > I know how to get this using a brute-force method that is essentially > > all_packages=`pkg list -a | some filtering here` > for p in `echo $all_packages` > do > pkg search -r -o pkg.name "depend:require:$p" > depends-upon-$p > done > > I'm just wondering if there is a more clever, or perhaps less intensive > on the publisher server, way to get the same info? > > Thanks, > > 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
Re: [oi-dev] Fatal error executing "make download" in oi-userland/cpmponents
In order to see how the oi-userland framework works, you could try to build or upgrade a specific component, such as desktop/remote-desktop/tigervnc I am thinking of "VNC" because perhaps VNC is an alternative in this case to RDP. So you could try to enable vnc and connect with vnc to the openindiana system. cd into components and desktop/remote-desktop/tigervnc and then in that directory gmake download to just download that specific components. When "gmake download" works, you can proceed to gmake publish which will compile/build that specific package and create/setup a local repository with your own build of that package. Regards, David Stes - Op 21 dec 2021 om 15:06 schreef clark k weeks c...@mmx3.net: > Please accept my apologies for this late reply. > > Thank you for the warm welcomes. > > As I am new to Openindiana and Mailing Lists (this is my first experience > being > an involved list member), and having read your responses, I see that I need to > be a little more descriptive not only of what I’m doing, but also why I’m > doing > it, as that makes a big difference in how my posts may be interpreted. > > First a little history about myself. I have worked in the IT industry since > 1997, by doing support for Gateway computers at a Stream International call > center taking support calls. I have been a linux buff for longer. I am, > however, not a Linux uber alles guy. I have dabbled with various other unixes. > Rather than go through my list of experiences, for anyone that may be > interested, my resume can be seen at [ http://mmx3.net/clark/resume4.php | > http://mmx3.net/clark/resume4.php ] . I am now retired, so have plenty of time > to play with just about whatever suits my fancy. > > So, to the “why" of my interest in Openindiana. 1) it is community based, 2) > it’s based on a long lived UNIX (Solaris), and 3) after learning (a > functioning > amount) of systemd, I became enamored with the SMF and was curious to learn > more about it. And, as I’m sure most all of you know, experience is the best > teacher. > > I installed Openindiana on one of my machines in order to learn more of its > workings. I use Bacula as the backup system for my home network of computers. > Being that packages for Bacula existed for Openindiana (and they are the same > version as what I am already using) I decided to move my Bacula director over > to the OpenIndiana server. This became a very interesting project because it > became a learning tool to see how I could fit it into learning more about SMF. > This (as an aside) enticed me to get xrdp working on the Openindiana box, as I > do nearly all the work on my home network of computers remotely from the > computer on my desk. (I use The Simpsons as the genre for naming my computes, > as it is an over generous pool of related names to use. The Openindiana box is > named “burns”.) > > Being new to Openindia I had no idea whether there was any sort of remote > desktop system available as a package, so I thought I’d work on incorporating > xrdp to my, as the term is used in the Openindiana pkg documentation, in my > “image”. This was another opportunity for more experience and learning of SMF. > > So, looking for some sort of development system on the OS platform, the best I > cam up with was the oi-userland platform. If there is a more suitable > development environment here than the oi-userland I’d more than willing to be > informed of it, as I believe oi-userland is primarily for creating shared > pkg’s, which I may do after becoming more knowledgable of Openindiana and the > specifics on how it functions. > > Unfortunately, the documentation I could find about Openindiana is not very > expansive. The best I was able to find was the oi-userland README file I > previously referenced. I would like to thank Andreas Wacknitz for his reply > for > mentioning that that README file out of date and pointing me to better > information regarding oi-useland, and his other suggestions on development > work. I genuinely appreciate the advice. > > Well, with this expansion of the “why” I’m doing this, I would gladly accept > any > more assistance from anyone willing to help me in my learning experience. > > Thank you all and I hope we have a wonderful and successful association here > within this mailing list. > > Clark K Weeks > > > > > > On Dec 16, 2021, at 12:10 PM, [ mailto:oi-dev-requ...@openindiana.org | > oi-dev-requ...@openindiana.org ] wrote: > > Date: Thu, 16 Dec 2021 18:10:09 +0100 > From: Andreas Wacknitz < [ mailto:a.wackn...@gmx.de | a.wackn...@gmx.de ] > > To: [ mailto:oi-dev@openindiana.org | oi-dev@openindiana.org ] > Subject: Re: [oi-dev] Fatal error executing "make download" in > oi-userland/cpmponents > Message-ID: < [ mailto:aa5988bc-2775-bf0d-40d4-5cab0dda0...@gmx.de | > aa5988bc-2775-bf0d-40d4-5cab0dda0...@gmx.de ] > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > Am 16.12.21 um 17:11 schrieb clark
Re: [oi-dev] Fatal error executing "make download" in oi-userland/cpmponents
- Op 16 dec 2021 om 18:10 schreef Andreas Wacknitz a.wackn...@gmx.de: > 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: The make-rules/prep-svn.mk complains that it cannot find /usr/bin/svn. "No such file or directory" is because it cannot find /usr/bin/svn. You should (if you really want to rebuild splix) : "pkg install developer/versioning/subversion". As far as I know, SVN (subversion) is NOT part of the "meta-package" build-essential but build-essential should be installed anyway as well. Note that there are only 3 packages in oi-userland that use subversion (I think).. I maintain one of them : Squeak . This traditional Smalltalk-80 implementation uses SVN. There exists other software such as TeX (typesetting) that also uses subversion (but TeX is not in oi-userland). The packages that use SVN currently seem to be : ./runtime/smalltalk/squeak ./print/splix ./network/vpnc splix seems to be CUPS drivers for Samsung printers. Anyway, as several people already pointed out, most likely it was not intentional to rebuild all packages. Regards David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] update of vagrant box
The current hipster box is 202109: https://app.vagrantup.com/openindiana/boxes/hipster Now that OpenIndiana 2021.10 is here: https://www.openindiana.org/2021/12/05/openindiana-hipster-2021-10-is-here/ Would it be possible please to update the vagrant box ? Thanks, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] paprefs : pulseaudio prefs 1.1
I'm submitting a new package called "paprefs" for OpenIndiana. "paprefs" is "PulseAudio Preferences" a GUI (graphical user interface) for setting some PulseAudio settings. I hope it is new, at least I didn't find a paprefs IPS package, maybe I just didn't see it. Anyway paprefs compiles relatively easily on OpenIndiana and it is useful desktop utility. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] How to combine two source archives into one OI package?
Hello, On the website pkg.opendiana.org I entered "pycairo" in Package Search. This results in some packages like : library/python-2/pycairo library/python-2/pycairo-26 library/python/pycairo library/python/pycairo-26 library/python/pycairo-27 library/python/pycairo-34 library/python/pycairo-35 Those are distinct IPS packages not versions of the same IPS package. Without knowing the details of the python Makefile rules, I think the manifests ./pycairo/pycairo-PYVER.p5m ./pycairo/pycairo-GENFRAG.p5m the PYVER is somehow replaced by the Python Version that is targeted. So producing a 37 or 39 package could produce a different package without obsoleting the old package, and perhaps using a "mediator" it is possible to deliver the same file in two different IPS packages. The mediator in this case could be the python mediator ? Unfortunately I'm not familiar with the python build framework, but if you search/grep for mediator, there are many examples. For example grep mediator */*.p5m setuptools/setuptools-PYVER.p5m:link path=usr/bin/easy_install target=easy_install-$(PYVER) mediator=python \ So the symbolic link /usr/bin/easy_install is set to the target easy_install-35 or easy_install-37 or whathever the mediator python indicates. Regards, David Stes - Op 2 dec 2021 om 22:03 schreef gary mills gary_mi...@fastmail.fm: > I'm working on upgrading the pycairo package to the latest version, > but I've run into a conflict with the existing version. Specifically, > the conflict is with usr/include/pycairo/py3cairo.h and > usr/lib/pkgconfig/py3cairo.pc, both of which are created by both > versions. The existing version only supports python 3.5. The latest > version supports only 3.7 and 3.9. The latter are required by many > other packages. > > I could solve the conflict by obsoleting the existing pycairo package. > Is this possible? Do I need to retain it? > > If I have to retain it, I'll need the Makefile to publish packages for > python 3.5, 3.7, and 3.9, using both the existing and latest versions > of the source. How do I do that? Is it even possible? I haven't > seen any examples of doing that. > > > -- > -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] PARI/GP for OpenIndiana
I'm submitting a package for Computer Algebra and (advanced) mathematics called PARI/GP. $ pkg list pari NAME (PUBLISHER) VERSIONIFO library/math/pari (userland) 2.13.3-2020.0.1.0 i-- This is a 64bit version without documentation (which depends on TeX I believe), but the documentation is online at the University of Bordeaux, France: $ pkg info pari Name: library/math/pari Summary: The PARI Computer Algebra System Category: Development/Other Languages State: Installed Publisher: userland Version: 2.13.3 Branch: 2020.0.1.0 Packaging Date: November 21, 2021 at 03:07:00 PM Last Install Time: November 21, 2021 at 03:08:26 PM Size: 12.10 MB FMRI: pkg://userland/library/math/pari@2.13.3-2020.0.1.0:20211121T150700Z Project URL: https://pari.math.u-bordeaux.fr Source URL: https://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.13.3.tar.gz The command to start PARI is "gp". PARI is actually also a C library "libpari" + gp their interactive shell, + GP their scripting language and gp2c a compiler from GP to C. Hopefully this can be added to OpenIndiana as 'end user application software' of interest. I did not check with the PARI group at Bordeaux yet, but because this is GPLv2 software, I think they will not mind. If there is an OK from the OpenIndiana team, I'll ask the PARI developers. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] ruby 3.1.0preview1
Thanks, this helps. Indeed, the ruby configure script detects gar, but it allows to select "ar" by using the AR environment variable. When I configure like this: ./configure --prefix=$HOME/ruby-31 --with-gcc AR=/usr/bin/ar then the "gar" errors disappear and it seems to do correctly: compiling builtin.c generating a glommed object with DTrace probes for static library linking static-library libruby-static.a I'll update the Ruby issue on the ruby website with this info. Thanks again, David Stes - Op 16 nov 2021 om 11:57 schreef Klaus Ziegler kla...@haus-gisela.de: > On 11/14/21 16:55, s...@pandora.be wrote: >> >> >> compiling builtin.c >> generating a glommed object with DTrace probes for static library >> linking static-library libruby-static.a >> gar: ruby-glommed.o: SHT_GROUP section [index 52] has no SHF_GROUP sections >> gar: ruby-glommed.o: SHT_GROUP section [index 53] has no SHF_GROUP sections >> gar: ruby-glommed.o: SHT_GROUP section [index 54] has no SHF_GROUP sections >> gar: ruby-glommed.o: SHT_GROUP section [index 55] has no SHF_GROUP sections >> ... >> lots of similar messages >> gar: ruby-glommed.o: unknown type [0] section `' in group [.group] >> gar: ruby-glommed.o: unknown type [0] section `' in group [.group] >> gar: ruby-glommed.o: unknown type [0] section `' in group [.group] >> > Did you tried to NOT use GNU ar/ranlib at all e.g. > # mv /usr/gnu/bin/ar /usr/gnu/bin/ar.orig > # mv /usr/gnu/bin/ranlib /usr/gnu/bin/ranlib.orig > # mv /usr/bin/gar /usr/bin/gar.orig > > and then start the configure with the dtrace option enabled? > Rgds > 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] Does OI use gtk+ or gtk+3, or both?
- Op 14 nov 2021 om 9:24 schreef Andreas Wacknitz a.wackn...@gmx.de: > Am 11/8/21 um 00:43 schrieb Gary Mills: >> 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 The most realistic - but even then very hard and a lot of work I guess - is to keep following the MATE desktop and integrate MATE updates. https://mate-desktop.org/ But I think that for application software like Squeak, which works on OpenIndiana, GTK+ is sufficient. This does not depend on GTK+3. In fact compiling on GTK+3 GNOME 3 is somewhat harder since application software, like Squeak, which is an old package, follows the changes in GTK in a slow way. However the updates that were done the last year like the Cairo update was fine, and Squeak depends on this (in a formal IPS dependency way) depend fmri=pkg:/library/desktop/cairo@1.16.0-2020.0.1.1 type=require depend fmri=pkg:/library/desktop/pango@1.48.10-2020.0.1.0 type=require depend fmri=pkg:/library/glib2@2.66.8-2020.0.1.0 type=require Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] ruby 3.1.0preview1
I've logged https://bugs.ruby-lang.org/issues/18335 ruby 3.1 preview1 seems to work fine without dtrace. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] ruby 3.1.0preview1
Hello, I tried compiling ruby 3.1 preview on OpenIndiana (Illumos) and this works: ./configure --prefix=$HOME/ruby-31 --with-gcc --disable-dtrace gmake gmake install It works: $HOME/ruby-31/bin/ruby --version ruby 3.1.0preview1 (2021-11-09 master 5a3b2e6141) [i386-solaris2.11] It succesfully compiles with the above config line and seems to work. You can see in the above that it builds a 32bit by default, I did not yet try a full 64bit compile. Note that I use the --with-gcc to select the OpenIndiana GCC compiler (not OpenIndiana clang). Also for some reason it seems I have to use --disable-dtrace. In older versions < 3.0 this works with DTRACE enabled, but this is apparently broken since 3.0.x If I compile with dtrace enabled I get: checking whether dtrace USDT is available... yes(-xnolibs) checking whether dtrace needs post processing... rebuild and then during compile compiling builtin.c generating a glommed object with DTrace probes for static library linking static-library libruby-static.a gar: ruby-glommed.o: SHT_GROUP section [index 52] has no SHF_GROUP sections gar: ruby-glommed.o: SHT_GROUP section [index 53] has no SHF_GROUP sections gar: ruby-glommed.o: SHT_GROUP section [index 54] has no SHF_GROUP sections gar: ruby-glommed.o: SHT_GROUP section [index 55] has no SHF_GROUP sections ... lots of similar messages gar: ruby-glommed.o: unknown type [0] section `' in group [.group] gar: ruby-glommed.o: unknown type [0] section `' in group [.group] gar: ruby-glommed.o: unknown type [0] section `' in group [.group] Does anyone know what ruby-glommed is and what exactly broke here ? It seems some sort of rebuild code generation is done in the dtrace case , but I am not familiar with the ruby config/build system to see what exactly. I've asked the Ruby list what the error with gar (GNU ar) is precisely, but chances are they are not so familiar either with DTRACE. There exist similar reports for FreeBSD like https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/95aff214687a5e12c3eb57d056665741e734c188 "The latest ruby cannot compile with FreeBSD Dtrace enabled." I'll log a ruby issue about this for OpenIndiana as well. Thanks, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Logitech C930e
Presumably it is a lot of work to get it working ... I think this, because based on my attempt to attach a C930e, I discovered in the Illumos database an old request https://www.illumos.org/issues/2268 from a long time ago to have "full V4L2 stack to support TV cards". This is issue is flagged as: Difficulty:Hard Basically there is no libv4l2 (no full V4L2 stack) for OpenIndiana and the BSD alternative that Mehmet Erol Sanliturk pointed out, is probably also a lot of work. Also it is not clear to me whether user level applications such as "ffmpeg" support the BSD webcamd. An effort to port webcamd to OpenIndiana only makes sense if programs such as "ffmpeg" would support webcamd, I suppose. However the good news or positive news is that Squeak has a CameraPlugin which only simply opens /dev/video0 and does not use libv4l2. This plugin compiles but does not seem to work for me. My understanding is that Squeak just like older applications like Ekiga (communication) open /dev/video* devices directly without the "stack" of libv4l2 on top of /dev/video. This can be ported to OpenIndiana but maybe only supports a very limited set of hardware. In any case I've submitted a PR for oi-docs to update the documentation and write that I tried attaching the C930e and that as far as I can see, it does NOT work. This in itself is not a big issue to me, I'm impressed in general by the quality of OpenIndiana which does not have to be underestimated compared to other UNIX variants. Regards, David Stes - Op 7 nov 2021 om 13:57 schreef toasterson toaster...@gmail.com: > Hi > > I know Firefox's WebRTC is disabled but would only need a couple more > libraries to enable during build. Then all Web based conferencing tools > would work. But it is a bit of work to get going. > > > -Till > > > On 07.11.21 12:35, s...@pandora.be wrote: >> >> Hi, >> >> I have attached meanwhile a Logitech C930e webcam to the USB 3.1 ports (some >> docs refer to these ports as USB 3.2) on my OpenIndiana system. >> >> This seems to work. I can record audio with "audacity" so that's already >> working. The microphone of the webcam works and functions fine. >> >> I have not actually been using the webcam video because there seems no >> "cheese" >> package in the OpenIndiana repository and I haven't figured out how to >> capture >> video with "ffmpeg". >> >> So the USB 2.0 device seems to function on the xhci driver for the USB >> 3.1/3.2 >> ports: >> >> # modinfo | grep xhci >> 103 f7cf5000 e8f0 251 1 xhci (USB xHCI Driver) >> >> # cfgadm -lv usb1/6 >> Ap_Id Receptacle Occupant Condition >> Information >> When Type Busy Phys_Id >> usb1/6 connectedconfigured ok Mfg: >> >> Product: Logitech Webcam C930e NConfigs: 1 Config: 0 >> unavailable usb-miscell n/devices/pci@0,0/pci1028,98d@14:6 >> >> # modinfo usbvc >> 7e73000 7bf8 303 1 usbvc (USB video class driver) >> >> Cheese is "obsoleted" in the OI repository. The latest cheese-41 seems to >> use >> "meson" and doesn't build for me, neither do old versions seem to build. >> >> Perhaps it makes more sense to capture video with "ffmpeg". >> >> But I think ffmpeg is currently built on OpenIndiana without >> --enable-libv4l2 >> configure option: >> >> https://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 >> >> So the video4linux2 options do not seem to work. >> >> $ ffmpeg -list_formats all >> ffmpeg version 3.2.14 Copyright (c) 2000-2019 the FFmpeg developers >>built with gcc 7.5.0 (OpenIndiana 7.5.0-il-0) >>configuration: --prefix=/usr --mandir=/usr/share/man --bindir=/usr/bin >>--libdir=/usr/lib/amd64 --cc=/usr/gcc/7/bin/gcc --enable-runtime-cpudetect >>--enable-mmx --enable-sse --enable-ssse3 --disable-debug --enable-nonfree >>--enable-gpl --enable-postproc --enable-avfilter --enable-swscale >>--enable-libgsm --enable-libxvid --enable-libx264 --enable-libx265 >>--enable-libtheora --enable-libmp3lame --enable-libvorbis --enable-libvpx >>--enable-x11grab --enable-libspeex --enable-pthreads --enable-libass >>--enable-openssl --enable-openal --enable-avresample >> --enable-libschroedinger >>--enable-libopenjpeg --enable-librtmp --enable-vdpau --enable-shared >>--disable-static >>libavutil 55. 34.101 / 55. 34.101 >>libavcodec 57. 64.10
Re: [oi-dev] Logitech C930e
Thanks, I'll give it a try. Basically I am also hoping to enhance Squeak (Smalltalk) to support the Webcam. http://wiki.squeak.org/squeak/2411 and http://wiki.squeak.org/squeak/1853 Although that Smalltalk as an old (or very old) environment has no standard support for this AFAIK although that the Smalltalk desktop has had some work to embed Webcam in 'Morphs' (objects for the Morph visual environment). Regards, David Stes - Op 7 nov 2021 om 12:45 schreef Mehmet Erol Sanliturk m.e.sanlit...@gmail.com: > Are able to use > > [ https://opencv.org/ | https://opencv.org/ ] > OpenCV (Open Source Computer Vision Library) > > ? > > In Linux , it is able to use a web camera . > In OpenIndiana , I think , it can use a web camera also . > > > Mehmet Erol Sanliturk > > > > > > > > > On Sun, Nov 7, 2021 at 2:36 PM [ mailto:s...@pandora.be | s...@pandora.be ] < > [ > mailto:s...@telenet.be | s...@telenet.be ] > wrote: > > > > Hi, > > I have attached meanwhile a Logitech C930e webcam to the USB 3.1 ports (some > docs refer to these ports as USB 3.2) on my OpenIndiana system. > > This seems to work. I can record audio with "audacity" so that's already > working. The microphone of the webcam works and functions fine. > > I have not actually been using the webcam video because there seems no > "cheese" > package in the OpenIndiana repository and I haven't figured out how to capture > video with "ffmpeg". > > So the USB 2.0 device seems to function on the xhci driver for the USB 3.1/3.2 > ports: > > # modinfo | grep xhci > 103 f7cf5000 e8f0 251 1 xhci (USB xHCI Driver) > > # cfgadm -lv usb1/6 > Ap_Id Receptacle Occupant Condition Information > When Type Busy Phys_Id > usb1/6 connected configured ok Mfg: Product: Logitech Webcam C930e > NConfigs: 1 Config: 0 > unavailable usb-miscell n /devices/pci@0,0/pci1028,98d@14:6 > > # modinfo usbvc > 7e73000 7bf8 303 1 usbvc (USB video class driver) > > Cheese is "obsoleted" in the OI repository. The latest cheese-41 seems to use > "meson" and doesn't build for me, neither do old versions seem to build. > > Perhaps it makes more sense to capture video with "ffmpeg". > > But I think ffmpeg is currently built on OpenIndiana without --enable-libv4l2 > configure option: > > [ https://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 | > https://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 ] > > So the video4linux2 options do not seem to work. > > $ ffmpeg -list_formats all > ffmpeg version 3.2.14 Copyright (c) 2000-2019 the FFmpeg developers > built with gcc 7.5.0 (OpenIndiana 7.5.0-il-0) > configuration: --prefix=/usr --mandir=/usr/share/man --bindir=/usr/bin > --libdir=/usr/lib/amd64 --cc=/usr/gcc/7/bin/gcc --enable-runtime-cpudetect > --enable-mmx --enable-sse --enable-ssse3 --disable-debug --enable-nonfree > --enable-gpl --enable-postproc --enable-avfilter --enable-swscale > --enable-libgsm --enable-libxvid --enable-libx264 --enable-libx265 > --enable-libtheora --enable-libmp3lame --enable-libvorbis --enable-libvpx > --enable-x11grab --enable-libspeex --enable-pthreads --enable-libass > --enable-openssl --enable-openal --enable-avresample --enable-libschroedinger > --enable-libopenjpeg --enable-librtmp --enable-vdpau --enable-shared > --disable-static > libavutil 55. 34.101 / 55. 34.101 > libavcodec 57. 64.101 / 57. 64.101 > libavformat 57. 56.101 / 57. 56.101 > libavdevice 57. 1.100 / 57. 1.100 > libavfilter 6. 65.100 / 6. 65.100 > libavresample 3. 1. 0 / 3. 1. 0 > libswscale 4. 2.100 / 4. 2.100 > libswresample 2. 3.100 / 2. 3.100 > libpostproc 54. 1.100 / 54. 1.100 > Unrecognized option 'list_formats'. > > The option list_formats seems not to be supported although according to the > docs > if --enable-v4l2 would be used, it could perhaps work. > > The /dev/video0 device is there. > > Has anyone suggestions on what other application could be used to test the > /dev/video0 device ? > > Regards, > David Stes > > ___ > oi-dev mailing list > [ mailto:oi-dev@openindiana.org | oi-dev@openindiana.org ] > [ https://openindiana.org/mailman/listinfo/oi-dev | > 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] Logitech C930e
Hi, I have attached meanwhile a Logitech C930e webcam to the USB 3.1 ports (some docs refer to these ports as USB 3.2) on my OpenIndiana system. This seems to work. I can record audio with "audacity" so that's already working. The microphone of the webcam works and functions fine. I have not actually been using the webcam video because there seems no "cheese" package in the OpenIndiana repository and I haven't figured out how to capture video with "ffmpeg". So the USB 2.0 device seems to function on the xhci driver for the USB 3.1/3.2 ports: # modinfo | grep xhci 103 f7cf5000 e8f0 251 1 xhci (USB xHCI Driver) # cfgadm -lv usb1/6 Ap_Id Receptacle Occupant Condition Information When Type Busy Phys_Id usb1/6 connectedconfigured ok Mfg: Product: Logitech Webcam C930e NConfigs: 1 Config: 0 unavailable usb-miscell n/devices/pci@0,0/pci1028,98d@14:6 # modinfo usbvc 7e73000 7bf8 303 1 usbvc (USB video class driver) Cheese is "obsoleted" in the OI repository. The latest cheese-41 seems to use "meson" and doesn't build for me, neither do old versions seem to build. Perhaps it makes more sense to capture video with "ffmpeg". But I think ffmpeg is currently built on OpenIndiana without --enable-libv4l2 configure option: https://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 So the video4linux2 options do not seem to work. $ ffmpeg -list_formats all ffmpeg version 3.2.14 Copyright (c) 2000-2019 the FFmpeg developers built with gcc 7.5.0 (OpenIndiana 7.5.0-il-0) configuration: --prefix=/usr --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/lib/amd64 --cc=/usr/gcc/7/bin/gcc --enable-runtime-cpudetect --enable-mmx --enable-sse --enable-ssse3 --disable-debug --enable-nonfree --enable-gpl --enable-postproc --enable-avfilter --enable-swscale --enable-libgsm --enable-libxvid --enable-libx264 --enable-libx265 --enable-libtheora --enable-libmp3lame --enable-libvorbis --enable-libvpx --enable-x11grab --enable-libspeex --enable-pthreads --enable-libass --enable-openssl --enable-openal --enable-avresample --enable-libschroedinger --enable-libopenjpeg --enable-librtmp --enable-vdpau --enable-shared --disable-static libavutil 55. 34.101 / 55. 34.101 libavcodec 57. 64.101 / 57. 64.101 libavformat57. 56.101 / 57. 56.101 libavdevice57. 1.100 / 57. 1.100 libavfilter 6. 65.100 / 6. 65.100 libavresample 3. 1. 0 / 3. 1. 0 libswscale 4. 2.100 / 4. 2.100 libswresample 2. 3.100 / 2. 3.100 libpostproc54. 1.100 / 54. 1.100 Unrecognized option 'list_formats'. The option list_formats seems not to be supported although according to the docs if --enable-v4l2 would be used, it could perhaps work. The /dev/video0 device is there. Has anyone suggestions on what other application could be used to test the /dev/video0 device ? Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] crypto/ca-certificates
At Mozilla they replied that they plan to fix this in December. https://bugzilla.mozilla.org/show_bug.cgi?id=1733003 What could work as a temporary workaround is to patch the certdata.txt file $ pkg list ca-certificates NAME (PUBLISHER) VERSIONIFO crypto/ca-certificates (userland) 3.71-2020.0.1.1i-- This is a COMPONENT_REVISION=1 update to the 3.71 package with a patch patches/01-DST_Root_CA_X3.patch --- nss-3.71.orig/nss/lib/ckfw/builtins/certdata.txtFri Oct 29 18:32:43 2021 +++ nss-3.71/nss/lib/ckfw/builtins/certdata.txt Fri Oct 29 18:33:34 2021 @@ -3113,136 +3113,6 @@ CKA_TRUST_STEP_UP_APPROVED CK_BBOOL CK_FALSE # -# Certificate "DST Root CA X3" -# where the DST Root CA X3 is removed from certdata.txt I am not sure whether this is all that is necessary, but it seems to work for me. The package builds fine and the 2 lines for DST Root CA X3 (file and link) are removed from the sample manifest and when updating the manifest to simply remove the DST Root CA X3 all seems fine. Because this is necessary to connect in Squeak Smalltalk to https://squeak.org it would be nice to get rid of the expired certificate. However on the other hand, this is not at all urgent , and it is easy to fix locally. So instead of patching OpenIndiana I think instead of a temporary workaround and patch, it is safest to wait for Mozilla NSS to be changed/updated, and then follow Mozilla NSS unpatched in December 2021. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] crypto/ca-certificates
> Red Hat's approach was to remove 'DST Root CA X3' from their packaged > ca-certificates bundle. > > https://access.redhat.com/articles/6338021 > > I'm not certain how other popular Linux distros have addressed it, but > only a few distros do long-term support, so those would be the ones most > impacted by it. Somebody created a bugzilla entry for the issue at mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1733560 DST X3 expired sep 2021 The current nss-3.72 still has the entries: ./nss-3.72/nss/lib/ckfw/builtins/certdata.txt Perhaps they may remove the expired certificate for nss-3.73, who knows ... For the moment - as long as the upstream nss package still has the expired certificates - an OpenIndiana upgrade of ca-certificates will not help , unless the package is patched to exclude the problem certificate. However in this case it seems safer to just wait for 'upstream' mozilla.org decision. Also note that https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ writes: The next release of OpenSSL 1.0.2 (1.0.2zb - available to premium support customers only) will make it possible to build the release with added -DOPENSSL_TRUSTED_FIRST_DEFAULT on the build configuration command line. That will make the -trusted_first option enabled by default by the OpenSSL library. So an upgrade of OpenIndiana openssl 1.0.2 to 1.0.2zb if that is possible could be another approach. This seems an example of an issue where multiple approaches/solutions exist. For the moment on my machine, I can simply remove the certificate myself, and that works. So if mozilla.org will react/act on the bug report 1733560 then the situation may change. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] crypto/ca-certificates
I tested building a 3.72 package but that also does not solve the problem. $ pkgrepo -s i386/repo/ list PUBLISHER NAME O VERSION userland crypto/ca-certificates 3.72-2020.0.1.0:20211028T165026Z The problem remains for both 3.71 and 3.72 that $ pkg contents ca-certificates | grep DST etc/certs/CA/DST_Root_CA_X3.pem So the expired certificate remains in the package. I am not certain how this should be solved. https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ is clear about several ways to fix it on a client machine. Perhaps escalating / providing a patch "upstream" to the source of those root certificates ?? Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] crypto/ca-certificates
there's a new nss package available at ftp.mozilla.org https://ftp.mozilla.org/pub/security/nss/releases/NSS_3_72_RTM/src/ remember that I have in Squeak Smalltalk an issue with the following certificate # openssl x509 -noout -in /etc/certs/CA/DST_Root_CA_X3.pem -text ... Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3 Validity Not Before: Sep 30 21:12:19 2000 GMT Not After : Sep 30 14:01:15 2021 GMT Subject: O=Digital Signature Trust Co., CN=DST Root CA X3 Unfortunately the previous upgrade to crypto/ca-certificates version 3.71-2020.0.1.0 did not solve that issue. the issue is documented at https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ where they say openssl 1.0.2 has an issue with that expired certificate and they say openssl 1.1 does not (but perhaps openssl 1.1 may have some other issues) Perhaps a new upgrade to the ca-certificates 3.72 is a possibility ? I didn't test that. Note that this is not super urgent as the workaround document in the blog article works fine. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] what target creates $(WS_TOP)/archives ?
Was it intentional that the oi-userland/archives/.gitkeep file and directory
placeholder were removed ?
In the past there was a 'empty placeholder' directory ("archives") with a file
.gitkeep (empty) in the oi-userland repository.
I liked the approach with the empty placeholder, although that setting
USERLAND_ARCHIVES to some other directory that you create yourself may be best.
The way I read Andreas email was that he prefers creating the directory
yourself - I don't mind and in fact it is true that this provides some
advantages.
Regards
David Stes
- Op 24 okt 2021 om 7:36 schreef oi-dev oi-dev@openindiana.org:
> In regard to: Re: [oi-dev] what target creates $(WS_TOP)/archives ?, Tim...:
>
>> It seems like creating it if it doesn't exist might be a useful addition
>> to either 'setup' or 'env-prep' (or perhaps 'download'). Otherwise, if
>> the user must do it manually when starting out with oi-userland, the step
>> needs to be added to the documentation.
>
> A PR that I think does that:
>
> https://github.com/OpenIndiana/oi-userland/pull/7225
>
> If people think this isn't the right approach, that's fine. I'm willing
> to take a different approach, if there's some consensus on what that
> should be.
>
> 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
Re: [oi-dev] what target creates $(WS_TOP)/archives ?
> Perhaps if you try a oi-userland from a few weeks ago (or months) it can be > reproduced that "gmake setup" used to create the archives directory. I just tried this myself and there is a difference but I incorrectly stated that 'gmake setup' was creating the archives directory. What seems to explain the difference (in the past the archives directory did not have to manually created) is that if I clone oi-userland it does not contain an archives directory any longer but it seems that if I checkout to a commit from a few weeks ago, there was an archives directory : $ git checkout 147934d8c Note: switching to '147934d8c'. You are in 'detached HEAD' state. ... HEAD is now at 147934d8c squeak-4: update to 4.19.6 $ ls -ld archives drwxr-xr-x 2 stes staff 3 Oct 23 17:27 archives $ git checkout oi/hipster Previous HEAD position was 147934d8c squeak-4: update to 4.19.6 Switched to branch 'oi/hipster' Your branch is up to date with 'origin/oi/hipster'. $ ls -ld archives archives: No such file or directory So perhaps older versions of oi-userland had an archives directory and this was perhaps removed. David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Optimize level O2 for libz
> > The community HCL lists some webcams > > http://docs.openindiana.org/community-hcl/components/#webcams > > There are some devices listed there, I'd have to figure one that works for me. > > If somebody has webcam suggestions for using with JITSI and OpenIndiana I'd be > interested ... One of the things I wonder when reading the webcams community-hcl, is whether this was tested with USB 2.0 ehci or USB 3.0 xhci drivers at the host end. There are items for various webcams, but not how they were attached to the host. There is an open Illumos bug for audio cards and USB 2.0/USB 3.0 interoperability. https://www.illumos.org/issues/13483 But perhaps the usbvc driver that is used for webcams is not affected by the audio issue. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] what target creates $(WS_TOP)/archives ?
Hi, I didn't report this, but I also noticed that "gmake setup" is not creating the directory archives any longer. I think it used to create that directory indeed. Not 100% sure but still whenever I cloned oi-userland I believe it automatically (through gmake setup) created the archives directory, while now I create it manually. I don't really mind manually creating the archives directory, so I didn't report it. Perhaps if you try a oi-userland from a few weeks ago (or months) it can be reproduced that "gmake setup" used to create the archives directory. Regards, David Stes - Op 23 okt 2021 om 12:02 schreef Andreas Wacknitz a.wackn...@gmx.de: > 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 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Optimize level O2 for libz
I'd certainly appreciate an invitation for the JITSI maintainer meeting; I'll accept if I can JITSI working. In any case I can document the steps to setup JITSI on OpenIndiana. Or is there already documentation on using JITSI on OpenIndiana and on joining the JITSI maintainer meeting ? I'd definitely want to get JITSI (https://jitsi.org/) working on my OpenIndiana machine (Dell 3640). The monitor is a Dell U2410 and this monitor has some USB ports, or perhaps I could attach to the Dell 3640 system directly with USB (if the cable is long enough). I'm not sure what the USB ports and smartcard slot on the U2410 monitor are for and if they work with OpenIndiana. The community HCL lists some webcams http://docs.openindiana.org/community-hcl/components/#webcams There are some devices listed there, I'd have to figure one that works for me. If somebody has webcam suggestions for using with JITSI and OpenIndiana I'd be interested ... Regards, David Stes - Op 15 okt 2021 om 9:24 schreef Carsten Grzemba grze...@contac-dt.de: > Am 14.10.21 20:01 schrieb "s...@pandora.be" : >> >> >> If there are tests for libz and if the tests do not fail, the O2 setting >> could >> be removed. >> >> Ideally there exist tests that show why the O2 setting was/is being used. >> >> In the case of Smalltalk Squeak I currently have a note in my Makefile >> >> # override gcc_OPT (defaults to -O3) for the moment >> # squeak compiles with -O2 or -O3 but >> # KernelTests-Chronology with version 4.16.7 or 4.19.* >> # gcc -O : 438 pass tests >> # gcc -O2 : 20 failures 1 errors #testAsDelay error >> # the system compiled with -O3 / -O2 is usable but has Chronology failures >> gcc_OPT= -O >> >> >> What exactly is the "maintainer meeting" ? >> > > A jitsi session every first wednesday of month. If you like Till can invite > you. > >> >> >> >> Regards, >> David Stes >> >> - Op 12 okt 2021 om 15:34 schreef oi-dev oi-dev@openindiana.org: >> >> > We discussed in the last maintainer meeting about the history of the O2 >> > setting >> > for build libz in OI. In the component build recipe is a note about >> > problems >> > with firefox if libz optimized in a higher level. >> > I build libz without this restriction an tested with firefox 91.2.0esr. >> > There I >> > could not see any problems, so I suggest to remove the O2 setting for libz. >> > -- >> > Carsten >> > >> > ___ >> > oi-dev mailing list >> > oi-dev@openindiana.org >> > https://openindiana.org/mailman/listinfo/oi-dev >> > -- > Carsten Grzemba > Tel.: +49 3677 64740 > Mobil: +49 171 9749479 > Email: carsten.grze...@contac-dt.de > contac Datentechnik GmbH ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Optimize level O2 for libz
If there are tests for libz and if the tests do not fail, the O2 setting could be removed. Ideally there exist tests that show why the O2 setting was/is being used. In the case of Smalltalk Squeak I currently have a note in my Makefile # override gcc_OPT (defaults to -O3) for the moment # squeak compiles with -O2 or -O3 but # KernelTests-Chronology with version 4.16.7 or 4.19.* # gcc -O : 438 pass tests # gcc -O2 : 20 failures 1 errors #testAsDelay error # the system compiled with -O3 / -O2 is usable but has Chronology failures gcc_OPT=-O What exactly is the "maintainer meeting" ? Regards, David Stes - Op 12 okt 2021 om 15:34 schreef oi-dev oi-dev@openindiana.org: > We discussed in the last maintainer meeting about the history of the O2 > setting > for build libz in OI. In the component build recipe is a note about problems > with firefox if libz optimized in a higher level. > I build libz without this restriction an tested with firefox 91.2.0esr. There > I > could not see any problems, so I suggest to remove the O2 setting for libz. > -- > Carsten > > ___ > 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] update of ca-certificates ?
Right, the issue seems not Squeak specific but I happen to see it in Squeak. Note that the OpenSSL support in Squeak is not perfect so I don't claim that there are no problems with the SSL plugin of Squeak, but in this case, it seems more a lower level, general issue. https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ Regards, David Stes - Op 14 okt 2021 om 19:29 schreef oi-dev oi-dev@openindiana.org: > On Thu, 14 Oct 2021 at 10:26, s...@pandora.be wrote: >> # cd /etc/certs/CA >> # rm DST_Root_CA_X3.pem >> # svcadm restart ca-certificates >> >> at the OS level - without changing anything in Squeak. > > I had to do this recently as well for another application. > >> So should there be an update of the ca-certificates package in OpenIndiana ? > > Yes, I believe there needs to be an update. > > > Cheers. > > -- > Joshua M. Clulow > http://blog.sysmgr.org > > ___ > 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] More on USB failure to automount
- Op 10 okt 2021 om 10:33 schreef Andreas Wacknitz a.wackn...@gmx.de: >> > Hi, are there any news about this bug and its fix? With the latest osnet-incorporation of Branch: 2020.0.1.20719 Packaging Date: Sat Oct 9 01:15:14 2021 when I plug in a USB key nothing happens. I have noticed that although that I'm sure I enabled it last time, meanwhile rmvolmgr is disabled again: # svcs -a | grep rmvol disabled 12:47:26 svc:/system/filesystem/rmvolmgr:default Maybe this is related to the manifest: but on the other hand it seems something disables the existing rmvolmgr:default instance. After # svcadm restart hal # svcadm enable rmvolmgr the automount of the USB key works fine: # eject -l /dev/dsk/c4t1d0s2cdrom,cdrom0,cd,cd0,sr,sr0 /dev/dsk/c5t0d0p0:1 rmdisk,rmdisk0,USBSLACK,/media/USBSLACK David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-vagrantfiles
I wrote : > I'm not sure why the port_forwarding does not work. I found out that port_forwarding in the Vagrantfile does work fine. The solution is very simple and documented in the note at http://docs.openindiana.org/contrib/getting-started/#prerequisites you have to run mkdocs serve --dev-addr=0.0.0.0:8000 or mkdocs serve -a 0.0.0.0:8000 in the Vagrant guest VM in order to connect to it by firefox or another webbrowser from the host. by default it only listens on 127.0.0.1:8000 The vagrantfile is a nice way to deploy a VM for oi-docs contributions, best of all, this kind of OpenIndiana VM can be deployed on Linux; or some other host. David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-vagrantfiles
That would be excellent, if you can import the oi-vagrantfiles-1.0.1.tar.gz from Sourceforge, then I can delete the sourceforge.net project and repository. My personal interest is in Smalltalk, not OpenIndiana in itself, OpenIndiana is just one of the operating systems running Smalltalk, although historically speaking Squeak/Smalltalk certainly existed a long time on SunOS systems. I don't mind deleting the oi-vagrantfiles repo at sourceforge, but Smalltalk is a "use case" or "usage scenario". I must say in the Smalltalk case the "vagrant" deployment works better than I thought it would, installing OpenIndiana by using "vagrant" is relatively fast. So please create a repo github.com/OpenIndiana/oi-vagrantfiles if possible ! By the way my oi-docs/Vagrantfile works fine for the lynx and links web browsers, but somehow the port_forwarding for port 8000 does not work for me to connect from the host, to the guest VM to preview the HTML docs. I'm not sure why the port_forwarding does not work. David Stes - Op 22 sep 2021 om 1:36 schreef Till Wegmueller toaster...@gmail.com: > Hey David > > Yeah I can setup a repo where you can push to. I think that is worth it > for the Vagrantfiles. Can you send me your Github username off list? > > -Till > > On 21.09.21 14:55, s...@pandora.be wrote: >> >> As a generalisation of the idea to have a Vagrantfile for Cuis and Squeak, >> I created an oi-vagrantfiles project to setup VM's with vagrant. >> >> The ability to deploy OpenIndiana with/by vagrant can be used for example to >> create a VM to have oi-docs or oi-userland contributions, or for running >> Smalltalk in a VM. >> >> The Vagrantfile project is at >> https://sourceforge.net/projects/oi-vagrantfiles/ >> >> Currently there is the excellent Vagrantfile in the oi-userland repo, >> by Adam Stevko and Michael Nowak and I copied that file (while retaining the >> copyright of course), >> to the oi-vagrantfiles repo. >> >> The idea of oi-vagrantfiles is to collect all sorts of Vagrantfiles for >> OpenIndiana development. >> >> If there is interest, this could perhaps also be hosted at >> https://github.com/OpenIndiana/ >> >> 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
Re: [oi-dev] oi-vagrantfiles
Adam, The Vagrantfile that you wrote, looks like an excellent idea to me, it works fine for me, and this is really useful. I used your Vagrantfile as an example for an oi-docs/Vagrantfile. When I use my oi-docs Vagrantfile to create a VM for oi-docs, vagrant installs OpenIndiana, then pkg install python mkdocs and ruby mdl, and also the links and lynx web browsers. So in the guest, in one window I can "vagrant ssh" into the VM, and run "mkdocs serve", while in a different window I can "vagrant ssh" into the VM and "lynx or links http://127.0.0.1:8000; seems to work. Currently I host this at sourceforge.net although my personal interest is in Smalltalk, and I intend to continue to use sourceforge.net for Smalltalk, although that it is true, that in this case (oi-docs Vagrantfile) this is more something OpenIndiana related of course. It's no problem for me to delete my sourceforge.net oi-vagrantfiles repository, if a github.com exists or is created. David Stes - Op 21 sep 2021 om 23:30 schreef Adam Števko adam.ste...@gmail.com: > Hello, > > instead of using [ http://sourceforge.net/ | sourceforge.net ] I would > recommend > creating the project under OI Github organization. Scattering resources around > the Internet is not helpful and can be confusing for new comers. > I would also recommend basing these vagrant files on the stock ones. I think > there was a way how you could just say to use OI base vagrant box and then > modify it with the vagrantfile for particular app. > > Thanks, > Adam > > On Tue, Sep 21, 2021 at 7:56 PM [ mailto:s...@pandora.be | s...@pandora.be ] > < [ > mailto:s...@telenet.be | s...@telenet.be ] > wrote: > > > > As a generalisation of the idea to have a Vagrantfile for Cuis and Squeak, > I created an oi-vagrantfiles project to setup VM's with vagrant. > > The ability to deploy OpenIndiana with/by vagrant can be used for example to > create a VM to have oi-docs or oi-userland contributions, or for running > Smalltalk in a VM. > > The Vagrantfile project is at [ > https://sourceforge.net/projects/oi-vagrantfiles/ | > https://sourceforge.net/projects/oi-vagrantfiles/ ] > > Currently there is the excellent Vagrantfile in the oi-userland repo, > by Adam Stevko and Michael Nowak and I copied that file (while retaining the > copyright of course), > to the oi-vagrantfiles repo. > > The idea of oi-vagrantfiles is to collect all sorts of Vagrantfiles for > OpenIndiana development. > > If there is interest, this could perhaps also be hosted at [ > https://github.com/OpenIndiana/ | https://github.com/OpenIndiana/ ] > > David Stes > > ___ > oi-dev mailing list > [ mailto:oi-dev@openindiana.org | oi-dev@openindiana.org ] > [ https://openindiana.org/mailman/listinfo/oi-dev | > 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] oi-vagrantfiles
As a generalisation of the idea to have a Vagrantfile for Cuis and Squeak, I created an oi-vagrantfiles project to setup VM's with vagrant. The ability to deploy OpenIndiana with/by vagrant can be used for example to create a VM to have oi-docs or oi-userland contributions, or for running Smalltalk in a VM. The Vagrantfile project is at https://sourceforge.net/projects/oi-vagrantfiles/ Currently there is the excellent Vagrantfile in the oi-userland repo, by Adam Stevko and Michael Nowak and I copied that file (while retaining the copyright of course), to the oi-vagrantfiles repo. The idea of oi-vagrantfiles is to collect all sorts of Vagrantfiles for OpenIndiana development. If there is interest, this could perhaps also be hosted at https://github.com/OpenIndiana/ David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Status of OpenIndiana Wiki (Atlassian Confluence)
I have created an oi-vagrantfiles project with oi-docs/Vagrantfile to setup with "vagrant up" a VM for the oi-docs. The Vagrantfile is at https://sourceforge.net/projects/oi-vagrantfiles/ This is a project for any Vagrantfile for OpenIndiana (oi) that creates a VM that runs the openindiana box. mdl from Sep 15 fixed the issues with it. Works for me now. However for mkdocs I have now: $ pkg list -af | grep futures library/python/futures3.2.0-2020.0.1.1 --o library/python/futures-27 3.2.0-2020.0.1.1 --o File "/usr/lib/python2.7/vendor-packages/pkg_resources/__init__.py", line 786, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'futures' distribution was not found and is required by tornado The futures package seems obsoleted: $ pkg list -af | grep futures library/pyth$ pkg list -af | grep futures library/python/futures3.2.0-2020.0.1.1 --o library/python/futures-27 3.2.0-2020.0.1.1 --oon/futures3.2.0-2020.0.1.1 --o library/python/futures-27 3.2.0-2020.0.1.1 --o "pip install futures" works for me and after the "pip install" mkdocs serve works. David Stes - Op 15 sep 2021 om 6:57 schreef Alexander Pyhalov a...@sfedu.ru: > Hi. > Separate issue - wanted to work on docs conversion (ipf section), but found > that > mdl is broken. > For now it seems I fixed it. Will try to work on this section later if I have > a > bit of free time. > > С уважением, > Александр Пыхалов, > программист отдела телекоммуникационной инфраструктуры > управления информационно-коммуникационной инфраструктуры ЮФУ > > > > От: James Madgwick > Отправлено: 13 сентября 2021 г. 0:43 > Кому: oi-dev@openindiana.org > Тема: Re: [oi-dev] Status of OpenIndiana Wiki (Atlassian Confluence) > > On Sat, 11 Sep 2021 18:59:04 -0300 > Till Wegmueller wrote: > >> In my opinion I would put the HTML under wiki.openindiana.org or >> another space. >> >> Docs should only be the migrated docs. >> > > To give an idea of what the Confluence HTML exported wiki looks like, > I've created this: https://oi-wiki-test.madgwick.xyz/ > > The HTML pages don't look great, but are usable as an archived version. > Happy to put the zip of HTML files and images (125MB - too big for gist) > somewhere - new OI repo? > > 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
[oi-dev] Vagrantfile for Cuis Smalltalk on OpenIndiana
The availability of an OpenIndiana image for Vagrant (a vagrant "box") is really useful. http://docs.openindiana.org/handbook/getting-started/#vagrant The doc there says "Vagrant is officially available for Mac OS X, Windows and Linux." and Vagrant can also be used on OpenIndiana (compiled from source), it works. I've created a small Vagrantfile using the Vagrant "box" to deploy Cuis Smalltalk. https://sourceforge.net/projects/cuisonopenindiana/ Initially I thought it could perhaps be a limitation that there is only a CLI (commandline) minimal box, not a desktop in the vagrant cloud, however thanks to pkg(5) IPS (Image Package System), it turns out it's possible to quickly add only the minimal set of X11 libraries without a full desktop. The set of required packages is computed by IPS pkg(5) from the dependencies of cog-spur (the packaged Smalltalk VM that runs the Smalltalk image). The vagrant box that I've used is the one from 202109 : $ vagrant box list openindiana/hipster (202109) You can ssh into the OpenIndiana VM and use X11 port forwarding: $ vagrant ssh The illumos Project illumos-77161fd3d7 September 2021 vagrant@openindiana:~$ echo $DISPLAY localhost:10.0 vagrant@openindiana:~/Cuis-Smalltalk-Dev$ squeak Cuis5.0-4834.image Thanks to the dependencies of the Cuis VM (cog-spur) the installer only installs about 22 packages on top of the OpenIndiana box (CLI) and it seems it installs all of the required X11 libraries so that it's then possible to run a GUI (graphical userinterface) Cuis Smalltalk system and forward the X11 display to the host system. Also I think the Vagrantfile can be deployed on Linux and perhaps other OS as well (running an OpenIndiana VM). Once the VM is created a "pkg update" will then update the binaries / software to the latest versions. Regards David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] ruby 3.0.2
It turns out that Vagrant 2.2.19dev works fine with Ruby 3.0.2 -- I think. It seems to work. I'll contribute some notes to oi-docs on how to setup Vagrant on OpenIndiana. Procedure : compile Ruby 3.0.2 from source and Vagrant clone from github.com/hashicorp repo Regards, David Stes - Op 14 sep 2021 om 1:57 schreef Till Wegmueller toaster...@gmail.com: > While I can see your logic, I am afraid there wont be a package unless > we make one. For one that I doubt Hashicorp makes one without us asking, > and on the other hand it is not that easy to build IPS packages outside > OI-userland. Which defines a lot of build time variables and structure. > Also all of the people needed to make a review and get the software > tested are in this community. > > In any case a build from source Article will help. Can you make that? > > If you are still up to make a OI package I would definitely help testing it. > > -Till > > On 13.09.21 15:37, s...@pandora.be wrote: >> >> Ruby 3.0.2 builds on OpenIndiana Hipster: >> >> $ /scratch/ruby-30/bin/ruby --version >> ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [i386-solaris2.11] >> >> The following config line works to build ruby 3.0.2: >> >> ./configure --disable-dtrace --with-gcc --prefix=/scratch/ruby-30 >> BISON=/scratch/bison-35/bin/bison >> >> This is with a custom bison instead of the currently OI installed bison >> 3.7.6. >> >> There's some gar (gnu ar) errors when dtrace is enabled. >> >> The gem ext/ripper grammar has a problem with bison 3.7.6 , the generated >> ripper.c is generated by the Ruby developers using bison 3.5.1. >> >> However when I try to use vagrant with ruby 3.0.2 that poses a problem >> because >> the bundle --binstubs exec step from: >> >> https://github.com/hashicorp/vagrant >> >> is not working. While with the tradition ruby-2.7.4 it works fine. >> >> There may be more experimental features in ruby-3.0.2 compared to ruby-2.7.4 >> so >> 2.7.4 is preferable anyway. >> >> So for the moment probably it just needs some testing (or a lot of testing) >> before IPS packaging this. >> >> In fact "vagrant" can be used perfectly well from source ... >> >> There could just be a community documentation page on docs.openindiana.org >> that >> documents how to install vagrant from source. I'll make a PR for oi-docs to >> document this. >> >> If a 'vagrant' IPS package is to be made, this would be more logically >> something >> for hashicorp, >> since it is hashicorp's product. >> >> 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] ruby 3.0.2
Ruby 3.0.2 builds on OpenIndiana Hipster: $ /scratch/ruby-30/bin/ruby --version ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [i386-solaris2.11] The following config line works to build ruby 3.0.2: ./configure --disable-dtrace --with-gcc --prefix=/scratch/ruby-30 BISON=/scratch/bison-35/bin/bison This is with a custom bison instead of the currently OI installed bison 3.7.6. There's some gar (gnu ar) errors when dtrace is enabled. The gem ext/ripper grammar has a problem with bison 3.7.6 , the generated ripper.c is generated by the Ruby developers using bison 3.5.1. However when I try to use vagrant with ruby 3.0.2 that poses a problem because the bundle --binstubs exec step from: https://github.com/hashicorp/vagrant is not working. While with the tradition ruby-2.7.4 it works fine. There may be more experimental features in ruby-3.0.2 compared to ruby-2.7.4 so 2.7.4 is preferable anyway. So for the moment probably it just needs some testing (or a lot of testing) before IPS packaging this. In fact "vagrant" can be used perfectly well from source ... There could just be a community documentation page on docs.openindiana.org that documents how to install vagrant from source. I'll make a PR for oi-docs to document this. If a 'vagrant' IPS package is to be made, this would be more logically something for hashicorp, since it is hashicorp's product. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] virtualbox 6.1.26 ?
As far as I can see vagrant works fine. OpenIndiana is an excellent platform for vagrant with provider VirtualBox. Vagrant also supports other providers such as VMware but obviously I use VirtualBox as provider. Vagrant currently requires ruby and bsdtar (libarchive.de). The Vagrant README file encourages you to compile your own ruby version which makes some sense. Vagrant 2.2.19dev installs on top of ruby 2.7.4 fine. It also works with the system provided ruby-26. Vagrant is installing additional 'gems' and vagrant script/executable. However on the Hashicorp (makers of vagrant) community list I've been warned that they are redesigning vagrant (supposedly) not to use ruby any longer (they may switch language - somebody said there). I could give it a try ruby-27 and ruby-30 and see how far I get. Regards, David Stes - Op 12 sep 2021 om 18:17 schreef Till Wegmueller toaster...@gmail.com: > Hello > > Last time I checked vagrant did not build but good to know it now does > :) Any package would be welcome. Want to do an update to virtualbox and > vagrant/ruby? > > -Till > > On 12.09.21 07:05, s...@pandora.be wrote: >> >>> 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... >> >> This is true, I've already contributed docs under >> http://docs.openindiana.org/handbook/community/ for Smalltalk-80 and TexLive >> 2021. >> >> But of course there's an enormeous amount of other work to be done ... >> >> Also keeping the docs up to date is a lot of work, I just noticed that the >> TexLive docs still refer to TL 2020 not to the current TL 2021 ... Same >> thing >> for Squeak / Smalltalk the docs should be updated 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 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] virtualbox 6.1.26 ?
> 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... This is true, I've already contributed docs under http://docs.openindiana.org/handbook/community/ for Smalltalk-80 and TexLive 2021. But of course there's an enormeous amount of other work to be done ... Also keeping the docs up to date is a lot of work, I just noticed that the TexLive docs still refer to TL 2020 not to the current TL 2021 ... Same thing for Squeak / Smalltalk the docs should be updated as well. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] virtualbox 6.1.26 ?
>> >> 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
[oi-dev] virtualbox 6.1.26 ?
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 ? Thanks, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] More on USB failure to automount
The workaround for USB automount that I discussed in my previous email, is still working. You just have to make sure rmvolmgr is enabled, not just restarting it ... For the service/hal and service/storage/removable-media packages: # pkg list hal removable-media NAME (PUBLISHER) VERSIONIFO service/hal 0.5.11-2020.0.1.20664 i-- service/storage/removable-media 0.5.11-2020.0.1.20664 i-- The problem was that rmvolmgr was disabled and restart does not enable it: # svcs rmvolmgr STATE STIMEFMRI disabled 19:57:43 svc:/system/filesystem/rmvolmgr:default # svcadm enable rmvolmgr After explicitely enabling it restart works to automount : # svcadm restart hal rmvolmgr # svcs hal rmvolmgr STATE STIMEFMRI online 21:40:33 svc:/system/hal:default online 21:40:33 svc:/system/filesystem/rmvolmgr:default # eject -l /dev/dsk/c4t1d0s2cdrom,cdrom0,cd,cd0,sr,sr0 /dev/dsk/c5t0d0p0:1 rmdisk,rmdisk0,USBSLACK,/media/USBSLACK Anyway on my system automount is working, although it's true that I shouldn't have to manually restart those services. Regards, David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] More on USB failure to automount
Hi, First of all it seems there are again OpenIndiana packages being updated; thanks a lot for the work on this. I updated succesfully by running "pkg update" to the latest osnet-incorporation/userland-incorporation from September 2: Again - thanks for providing those update packages. Unfortunately the USB problem is still there and it got worse for me. # prtdiag -v | head System Configuration: Dell Inc. Precision 3640 Tower BIOS Configuration: Dell Inc. 1.2.3 08/06/2020 Processor Sockets Version Location Tag -- Intel(R) Core(TM) i3-10100 CPU @ 3.60GHz U3E1 When I insert a USB key (Kingston) nothing happens, but my workaround of restarting hal and rmvolmgr is not working any longer. # svcadm restart hal # svcadm restart rmvolmgr # eject -l /dev/dsk/c4t1d0s2cdrom,cdrom0,cd,cd0,sr,sr0 /dev/dsk/c5t0d0p0:1 rmdisk,rmdisk0,USBSLACK # df -h /media/USBSLACK df: (/media/USBSLACK) not a block device, directory or mounted resource A manual mount is fortunately still working: # mount -F pcfs /dev/dsk/c5t0d0p0:1 /mnt # df -h /mnt Filesystem Size Used Available Capacity Mounted on /dev/dsk/c5t0d0p0:1 15.95M 7.58M 8.37M48%/mnt So the manual mount works but in the past for me restarting hal and rmvolmgr was making automount work automatically, which seems now not the case any longer for me ... Anyway personally I think it is still acceptable as long as the manual mount works ! I can live with this failure, although it would be nice if it could get fixed ... Regards, David Stes - Op 27 aug 2021 om 17:55 schreef gary mills gary_mi...@fastmail.fm: > Joshua M. Clulow has identified the location of the error: > >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. >... >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've managed to add a few details using truss. Here's the command I > used to examine the top hald process: > ># truss -f -o /tmp/NNN.truss -t read -u \ >libglib-2.0::g_io_channel_read_line -p PID > > On a system where USB automount still worked, with a BE dated > 2020-11-27, I got the following output: > >1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, >0x8046204, 0x0) >1994/1: read(12, " E C _ d e v f s E S C".., 1024)= 80 >1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 1 >1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, >0x8046204, 0x0) >1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 1 >1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, >0x8046204, 0x0) >1994/1: read(12, " E C _ d e v f s E S C".., 1024)= 89 >1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 1 >1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, >0x8046204, 0x0) >1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 1 >1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, >0x8046204, 0x0) >1994/1: read(12, 0x08341480, 1024) Err#11 > EAGAIN >1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 3 >1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, >0x8046204, 0x0) >1994/1: read(12, " E C _ d e v _ a d d d".., 1024)= 98 >1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 1 > > It shows the entry and return of g_io_channel_read_line() as well as > the underlying read() system call that occurs between the two. Note > that all three lines in the pipe were read back by hald. In this > case, the return value from g_io_channel_read_line() is 1. Note also > that one read system
Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY
I just want to add that I think the current solution ,
with the /etc/system.d/reserve_bits_for_tagged_pointers
is fine for me.
Also I am not knowledgeable at all about this issue (I have no experience with
the link editor mapfiles).
Also the title subject line "RESERVE_SEGMENT or CAPABILITY" already indicates
my misunderstanding, as it indicates a syntax that is NOT supported by OI if I
understand correctly.
When I was looking at my current OpenSmalltalk cog-spur issue, I simply
recalled the old discussion,
as it seems relevant, although perhaps not 100% the same issue, to my case.
There is an old blog at Oracle describing the "old AT link editor" mapfile
syntax.
https://blogs.oracle.com/solaris/post/the-problems-with-solaris-svr4-link-editor-mapfiles
However the compiler tools used there are the Sun tools : cc and ld.
In the case of OI the GNU tools are used (gcc and perhaps /usr/gnu/bin/ld ?)
How exactly do you compile and link ?
You write "Linked with this mapfile" but how is this done , in the framework of
oi-userland ?
Thanks,
David Stes
- Op 11 aug 2021 om 9:37 schreef oi-dev oi-dev@openindiana.org:
> Am 09.08.21 23:03 schrieb Richard Lowe :
>
>
> It's been so long I honestly don't remember right now, but it or V look right
> (ignoring the documentation, for now). You should be able to check it was
> created using elfdump -p
>
> -- Rich
>
> On Mon, Aug 9, 2021, 01:34 Carsten Grzemba via oi-dev < [
> mailto:oi-dev@openindiana.org | oi-dev@openindiana.org ] > wrote:
>
>
>
>
> Am 08.08.21 23:46 schrieb Richard Lowe < [ mailto:richl...@richlowe.net |
> richl...@richlowe.net ] >:
>
>
> We haven't added RESERVE_SEGMENT yet, though it would be fairly easy to do I
> think.
> You can do the same thing in the v1 syntax though, using the ?E flag to say
> it's
> empty.
>
>
>
>
> I try to translate the mapfile version 2 to version 1
> version 2;
>
> RESERVE_SEGMENT spidermonkey_reserve {
> VADDR = 0x8000;
> SIZE = 0x7fff;
> };
>
> Is the following correct in version = 1?
>
> spidermonkey_reserve = LOAD A0x8000 L0x7fff ?E;
>
>
> Linked with this mapfile I get with elfdump -p xpcshell:
>
>
> Program Header[0]:
> p_vaddr: 0x400040 p_flags: [ PF_X PF_R ]
> p_paddr: 0 p_type: [ PT_PHDR ]
> p_filesz: 0x1c0 p_memsz: 0x1c0
> p_offset: 0x40 p_align: 0
>
> Program Header[1]:
> p_vaddr: 0x400200 p_flags: [ PF_R ]
> p_paddr: 0 p_type: [ PT_INTERP ]
> p_filesz: 0x17 p_memsz: 0x17
> p_offset: 0x200 p_align: 0
>
> Program Header[2]:
> p_vaddr: 0x40 p_flags: [ PF_X PF_R ]
> p_paddr: 0 p_type: [ PT_LOAD ]
> p_filesz: 0x3f811 p_memsz: 0x3f811
> p_offset: 0 p_align: 0x1
>
> Program Header[3]:
> p_vaddr: 0x44f820 p_flags: [ PF_W PF_R ]
> p_paddr: 0 p_type: [ PT_LOAD ]
> p_filesz: 0x8a8 p_memsz: 0xdf8
> p_offset: 0x3f820 p_align: 0x1
>
> Program Header[4]:
> p_vaddr: 0x8000 p_flags: 0
> p_paddr: 0 p_type: [ PT_LOAD ]
> p_filesz: 0 p_memsz: 0x7fff
> p_offset: 0 p_align: 0x10
>
> Program Header[5]:
> p_vaddr: 0x44fb10 p_flags: [ PF_W PF_R ]
> p_paddr: 0 p_type: [ PT_DYNAMIC ]
> p_filesz: 0x470 p_memsz: 0
> p_offset: 0x3fb10 p_align: 0
>
> Program Header[6]:
> p_vaddr: 0x4500c8 p_flags: [ PF_W PF_R ]
> p_paddr: 0 p_type: [ PT_TLS ]
> p_filesz: 0 p_memsz: 0x8
> p_offset: 0x400c8 p_align: 0x8
>
> Program Header[7]:
> p_vaddr: 0x400218 p_flags: [ PF_R ]
> p_paddr: 0 p_type: [ PT_SUNW_UNWIND ]
> p_filesz: 0xe4c p_memsz: 0xe4c
> p_offset: 0x218 p_align: 0x8
>
> If I try to run:
> $ LD_LIBRARY_PATH=. ./xpcshell
> Killed
>
> or
> $ LD_LIBRARY_PATH=. ldd ./xpcshell
> ldd: ./xpcshell: execution failed due to signal 9
>
> So I guess to use LOAD for this is no good idea because OS thinks this space
> is
> really to reserve instead of not to use?
> --
> Carsten
>
> ___
> 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] mapfile and RESERVE_SEGMENT or CAPABILITY
- Op 8 aug 2021 om 14:32 schreef stes s...@telenet.be: > Thanks indeed I noticed this setting is now in /etc/system.d/ in the latest OI > but it somehow did not fix my problem. > >> set _userlimit=0x7fffc000 > > seems a reasonable setting to simulate the behavior of Linux ... Despite the fact that I have on my system $ cat /etc/system.d/reserve_bits_for_tagged_pointers # This sets the maximum virtual memory address for user processes. It makes the system behave a bit more like Linux. # The address space for each 64-bit process is still roughly 128TB. set _userlimit=0x7fffc000 However I should add that indeed the _userlimit is applied because endOfJITZone is set to 7fffae45 So _userlimit does work - it is incorrect from my side to say that it does not work. But it does not completely fix my cog-spur problem. For the moment I applied a small patch to force MAP_32BIT which fixes the issue for me. Basically this seems to me a recently introduced bug in cog-spur OpenSmalltalk, I have to get the OpenSmalltalk developer look at this and fix it if possible, but it sounds similar to the spidermonkey issue. David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY
Thanks indeed I noticed this setting is now in /etc/system.d/ in the latest OI but it somehow did not fix my problem. > set _userlimit=0x7fffc000 seems a reasonable setting to simulate the behavior of Linux ... However I have pushed a workaround to patch - set MAP_32BIT for cog-spur 5.0.3031 for the moment. If I limit the mmap results to 4GB 32bit then cog-spur also works. I'd say this is a bug in (very recent) cog-spur versions, the return value of mmap on OI is not wrong, it is just that the pointer arithmetic in OpenSmalltalk latest code for cog-spur assumes the Linux layout. The traditional stack-spur interpreter which is more like the traditional Squeak VM continues to support full 64bit. So stack-spur 5.0.3031 is supporting full 64bit memory; also cog-spur 2967 still supported the full 64bit. David Stes - Op 8 aug 2021 om 14:01 schreef oi-dev oi-dev@openindiana.org: > Am 08.08.21 11:27 schrieb "s...@pandora.be" : > > > > Back in March 2021 there was an interesting post by Alan Coopersmith about the > address space layout diagrams for the AMD64 ABI. > > This was related in March to firefox, spidermonkey and so-called tagged > pointers. > > He described various strategies, some were adding a ld link editor mapfile > using > either RESERVE_SEGMENT or CAPABILITY. > > However I fear that the OpenIndiana ld has no support for RESERVE_SEGMENT. > > I have ran into a new issue in the very latest versions of OpenSmalltalk > cog-spur where apparently new code in OpenSmalltalk expects the Linux address > space layout - not the OpenIndiana layout. > > The issue is that new code when ran under a debugger seems to set > > endOfJITZone = 0x80ffbcecf000 > > instead of > > endOfJITZone = 0x7fffbe40 > > as on Linux. The OpenIndiana layout seems to use the full 64bit pointer range > while Linux does not seem to do that but unfortunately it appears that > OpenSmalltalk now expects the Linux layout. A few weeks ago that was not the > case so I already raised the issue with the OpenSmalltalk developers. > > I am trying now to use a ld -M mapfile on OI as workaround. > > There are some examples in : > > /usr/lib/ld > > and > > /usr/lib/ld/amd64 > > These examples are : map.default, map.below4G and map.above4G > > Has anyone - perhaps for spidermonkey ? - created a mapfile for simulating the > Linux address space layout ? > > Something like: /usr/lib/ld/amd64/map.linux ? > > Thanks > David Stes > > ___ > oi-dev mailing list > oi-dev@openindiana.org > [ https://openindiana.org/mailman/listinfo/oi-dev | > https://openindiana.org/mailman/listinfo/oi-dev ] > OI mapfile do not support such setting, so I guess the /etc/system setting: > > set _userlimit=0x7fffc000 > > is the only option for you. > -- > Carsten > > ___ > 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] mapfile and RESERVE_SEGMENT or CAPABILITY
Back in March 2021 there was an interesting post by Alan Coopersmith about the address space layout diagrams for the AMD64 ABI. This was related in March to firefox, spidermonkey and so-called tagged pointers. He described various strategies, some were adding a ld link editor mapfile using either RESERVE_SEGMENT or CAPABILITY. However I fear that the OpenIndiana ld has no support for RESERVE_SEGMENT. I have ran into a new issue in the very latest versions of OpenSmalltalk cog-spur where apparently new code in OpenSmalltalk expects the Linux address space layout - not the OpenIndiana layout. The issue is that new code when ran under a debugger seems to set endOfJITZone = 0x80ffbcecf000 instead of endOfJITZone = 0x7fffbe40 as on Linux. The OpenIndiana layout seems to use the full 64bit pointer range while Linux does not seem to do that but unfortunately it appears that OpenSmalltalk now expects the Linux layout. A few weeks ago that was not the case so I already raised the issue with the OpenSmalltalk developers. I am trying now to use a ld -M mapfile on OI as workaround. There are some examples in : /usr/lib/ld and /usr/lib/ld/amd64 These examples are : map.default, map.below4G and map.above4G Has anyone - perhaps for spidermonkey ? - created a mapfile for simulating the Linux address space layout ? Something like: /usr/lib/ld/amd64/map.linux ? Thanks David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] libmapmalloc and libumem
When I compiled OpenSmalltalk on OpenIndiana, initially it seemed to work but there were sometimes malloc() errors, pointing to some form of memory corruption. The names of the OpenSmalltalk packages are cog-spur and stack-spur. Those are also the names that the principal developer of OpenSmalltalk (Eliot Miranda) also uses. Both cog-spur and stack-spur were sometimes working fine for a while, then crashing either without error message or with some malloc error. I ran cog-spur and stack-spur under valgrind, a tool to debug malloc, but valgrind did not find a problem. Fortunately I discovered a while ago that OpenIndiana has multiple malloc() libraries. Since I link against libmapmalloc, a malloc() implementation that only uses mmap() and not brk() or sbrk() , the situation is much better. The packages are now much more stable and I have not seen a malloc() error any longer although that these are hard to reproduce problems. Perhaps I should be using libumem instead of libmapmalloc. Has anyone recommendations on perhaps preference for libumem on OI instead of libmapmalloc ? David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Some X11 updates
I tested my port of the OpenSmalltalk package after the update $ pkg list | grep X11 runtime/smalltalk/cog-spur-display-X115.0.3003-2020.0.1.0i-- and I don't see a difference after the X updates :-) But which regression or possible problem could occur after the update ? I can report that the upgrade went smoothly on my system, but how to observe any regression of interest ? David Stes - Op 5 aug 2021 om 9:54 schreef Aurélien Larcher aurelien.larc...@gmail.com: > Thanks for the feedback :) > It is still Xorg 1.19.7 for the reason that Xorg 1.20.x requires a rather > large > update of drm and libdrm. > However I still have problems to fix, my laptop crashes with the latest bits. > > On Wed, Aug 4, 2021 at 10:13 PM [ mailto:s...@pandora.be | s...@pandora.be ] > < [ > mailto:s...@telenet.be | s...@telenet.be ] > wrote: > > > > Updated to > > Name: x11/server/xorg > Summary: Xorg - X11R7 X server > Category: System/X11 > State: Installed > Publisher: [ http://openindiana.org/ | openindiana.org ] > Version: 1.19.7 > Branch: 2020.0.1.8 > Packaging Date: August 4, 2021 at 03:52:36 PM > > - Op 4 aug 2021 om 19:04 schreef Aurélien Larcher [ > mailto:aurelien.larc...@gmail.com | aurelien.larc...@gmail.com ] : > >> Hello, >> I pushed some X11 updates earlier today. >> Although they have been tested for some time on two machines, please let me >> know >> if you observe any regression. >> Kind regards, >> >> Aurélien >> >> -- >> --- >> Praise the Caffeine embeddings >> >> ___ >> oi-dev mailing list >> [ mailto:oi-dev@openindiana.org | oi-dev@openindiana.org ] >> [ https://openindiana.org/mailman/listinfo/oi-dev | >> https://openindiana.org/mailman/listinfo/oi-dev ] > > ___ > oi-dev mailing list > [ mailto:oi-dev@openindiana.org | oi-dev@openindiana.org ] > [ https://openindiana.org/mailman/listinfo/oi-dev | > https://openindiana.org/mailman/listinfo/oi-dev ] > > > -- > --- > 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] Some X11 updates
Updated to Name: x11/server/xorg Summary: Xorg - X11R7 X server Category: System/X11 State: Installed Publisher: openindiana.org Version: 1.19.7 Branch: 2020.0.1.8 Packaging Date: August 4, 2021 at 03:52:36 PM - Op 4 aug 2021 om 19:04 schreef Aurélien Larcher aurelien.larc...@gmail.com: > Hello, > I pushed some X11 updates earlier today. > Although they have been tested for some time on two machines, please let me > know > if you observe any regression. > Kind regards, > > Aurélien > > -- > --- > 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
