Re: [oi-dev] Purpose of PACKAGE_NAMES
On Fri, Sep 29, 2023 at 3:13 PM Marcel Telka wrote: > On Fri, Sep 29, 2023 at 02:13:42PM +0200, Aurélien Larcher wrote: > > On Fri, Sep 29, 2023 at 10:15 AM Marcel Telka wrote: > > > > > Hi, > > > > > > I noticed there are PACKAGE_NAMES macros set for few components in the > > > oi-userland git repo. Namely here: > > > > > > components/meta-packages/history/Makefile > > > components/openindiana/gfx-drm/Makefile > > > components/openindiana/pkg/Makefile > > > components/openindiana/slim_source/Makefile > > > > > > They were added in October 2018 by following commits: > > > > > > c7b5e23fc94 > > > 2e3897664af > > > ac1196a7cb0 > > > a4bb6ce259f > > > > > > I'm curious what is the purpose of these macros. As far as I know > there > > > is no known consumer for them. They looks like some attempt to list > > > packages generated by a component before we had support for pkg5 files > > > (introduced in 2020). > > > > > > If PACKAGE_NAMES are unused then I plan to simply remove them once I > > > touch those Makefiles. > > > > > > > If I remember correctily they were introduced to produce package names > used > > in dependency resolution in the external python scripts, for components > > that generate packages internally and then copy them rather than the > usual > > procedure. > > Okay, thanks. I translate the above as: yes, PACKAGE_NAMES was a > predecessor of pkg5. > > > The goal was to trigger rebuild of dependencies based on this information > > and avoid publication of broken repositories e.g. when ABI is broken and > > the update is split in several PRs due to our flawed CI. > > If I'm not mistaken the same could be done using the (modern) pkg5 files. > If you see the packages listed in the pkg5 files then it is fine indeed. We had some work in progress back then with Adam but some parts were never integrated. However the pkg5 part did work to the extent that the dependency graph was built. Thanks for looking into it. > > > Without these definitions print-package-names would produce an incomplete > > list of packages provided by the component and the graph will have > dangling > > dependencies. > > I just tried `gmake publish` and then `gmake print-package-names` in > openindiana/pkg and this is the result: > > Makefile:45: warning: overriding recipe for target 'update' > /data/builds/ul-workspace/make-rules/component.mk:49: warning: ignoring > old recipe for target 'update' > package-names= (origin: undefined, flavor: undefined) > > So PACKAGE_NAMES is useless there these days. > > Also, `gmake update-metadata` in openindiana/pkg does strange things, so > apparently there is something else broken. Anyway, if `gmake > update-metadata` is able to work for openindiana/illumos-gate without > PACKAGE_NAMES, then we should be able to make it working for other > components too wihout PACKAGE_NAMES. > > > However I am not sure if the bass/component.py script still relies on > these > > definitions (there is also a build-plan branch that attempts to automate > > rebuild of dependencies). > > I'm unable to find PACKAGE_NAMES in bass/component.py so it apparently > does not rely on it. And looking at the history it never did. > > Quick look at your build-plan branch shows there is no PACKAGE_NAMES > mentioned there. > > > So the result so far is: PACKAGE_NAMES is unused nad useless and we > should simply remove it. > > > Thanks Aurélien for information. > > -- > +---+ > | 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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Purpose of PACKAGE_NAMES
On Fri, Sep 29, 2023 at 10:15 AM Marcel Telka wrote: > Hi, > > I noticed there are PACKAGE_NAMES macros set for few components in the > oi-userland git repo. Namely here: > > components/meta-packages/history/Makefile > components/openindiana/gfx-drm/Makefile > components/openindiana/pkg/Makefile > components/openindiana/slim_source/Makefile > > They were added in October 2018 by following commits: > > c7b5e23fc94 > 2e3897664af > ac1196a7cb0 > a4bb6ce259f > > I'm curious what is the purpose of these macros. As far as I know there > is no known consumer for them. They looks like some attempt to list > packages generated by a component before we had support for pkg5 files > (introduced in 2020). > > If PACKAGE_NAMES are unused then I plan to simply remove them once I > touch those Makefiles. > If I remember correctily they were introduced to produce package names used in dependency resolution in the external python scripts, for components that generate packages internally and then copy them rather than the usual procedure. The goal was to trigger rebuild of dependencies based on this information and avoid publication of broken repositories e.g. when ABI is broken and the update is split in several PRs due to our flawed CI. Without these definitions print-package-names would produce an incomplete list of packages provided by the component and the graph will have dangling dependencies. However I am not sure if the bass/component.py script still relies on these definitions (there is also a build-plan branch that attempts to automate rebuild of dependencies). > > > Thank you. > > -- > +---+ > | 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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] SUnit and gmake test on OpenIndiana
On Sat, Oct 29, 2022 at 10:56 AM s...@pandora.be wrote: > > 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 ? > 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. > > Thanks > David Stes > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] COMPONENT_TEST_TRANSFORMS for PARI
On Sat, Oct 15, 2022 at 7:34 PM s...@pandora.be wrote: > > 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. > The maintainer's guide that I had started writing on the wiki did not make it to the docs website (yet): https://oi-wiki-test.madgwick.xyz/35913833.html https://oi-wiki-test.madgwick.xyz/2.-Overview-of-the-Build-System_37060624.html https://oi-wiki-test.madgwick.xyz/3.-Common-Tasks_37060626.html The last page contains information on transforms. > > - 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 > -- --- Praise the Caffeine embeddings ___ 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
On Tue, Oct 4, 2022 at 4:34 PM Marcel Telka wrote: > On Fri, Sep 30, 2022 at 07:16:18PM +0200, s...@pandora.be wrote: > > > > 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. > > The futures python package was obsoleted in May 2021 in OpenIndiana. > The reason is, apparently, this - see https://pypi.org/project/futures/: > > It does not work on Python 3 due to Python 2 syntax being used in the > codebase. Python 3 users should not attempt to install it, since the > package is already included in the standard library. > Marcel is right, there were a few modules to ensure the transition from Python 2 to Python 3 such as this one and other backport.* packages. Migrating to Python 3 as default and obsoleting these transitional packages should be enough. > > > 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 > -- --- Praise the Caffeine embeddings ___ 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
On Thu, Sep 29, 2022 at 4:30 PM Marcel Telka wrote: > On Thu, Sep 29, 2022 at 04:18:01PM +0200, Aurélien Larcher wrote: > > We could define some rules or information depending on the nature of the > > package to mark which dependencies are expected. > > Some python modules have been added for the sake of resolving a > dependency > > while others have no consumer in userland but are expected to be > installed > > as "standalone" and consumed by users directly. > > > > Also I am not sure I understood which type of dependencies are considered > > here: > > - resolved within userland either directly or added explicitly in the > > manifest > > - build requirements > > - dependencies detected by pipdeptree (which are a superset of what > > pkg/userland detects) > > > > I just want to make sure that we do not miss some border effects. > > Okay, I'll stop to obsolete more python related packages and leave it as > it is for now so everybody have a chance to add back packages that were > obsoleted, but they are needed for any reason. > I am not asking you to stop anything at all, I am just asking questions to understand if this will not bite us back at some point. If you feel that you have everything covered then it is fine by me. Seeing the stream of obsoletions without warning was quite surprising and raised a few questions. You know how you want to handle things, but this is maybe less clear to others. At least maybe some indications on how to add the packages back and make sure there is no mistake or loss of consistency with the location/naming etc.. Kind regards, Aurélien > > -- > +---+ > | 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 > -- --- Praise the Caffeine embeddings ___ 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
On Thu, Sep 29, 2022 at 4:00 PM Marcel Telka wrote: > On Thu, Sep 29, 2022 at 03:18:29PM +0200, Aurélien Larcher wrote: > > I do not understand the need for obsoleting the entire package and > removing > > all the files instead of updating on the go. > > > > Could you explain the motivation? > > There is no particular need. It is just simpler to obsolete than to > update. And since there is no known consumer, then the obsoletion is > the obvious option chosen. > We could define some rules or information depending on the nature of the package to mark which dependencies are expected. Some python modules have been added for the sake of resolving a dependency while others have no consumer in userland but are expected to be installed as "standalone" and consumed by users directly. Also I am not sure I understood which type of dependencies are considered here: - resolved within userland either directly or added explicitly in the manifest - build requirements - dependencies detected by pipdeptree (which are a superset of what pkg/userland detects) I just want to make sure that we do not miss some border effects. > > > To me this seems a bit of overhead, like removing the mkdocs, cython, > numpy > > packages completely from the tree instead of updating them. > > Feel free to create PRs to get them back. > > > We therefore lose track of what was in the tree and people may start from > > scratch all over again. > > > > Maybe you intend to provide some level of automation later? > > Maybe. If I find it easy to do I'll do so, but I've no immediate plan > to do so. > > > An earlier heads-up before starting to remove everything could have been > > nice to have a chance to update a few components in advance and avoid the > > mumbo-jumbo. > > Sorry. I try to do my best. Nothing is perfect. > > Anyway, an earlier update/rebuild of those packages for non-EOLed python > would be nice from you before you left them fall out of support and be > surprised that they are disappearing. > > Sorry, talking is easy. > > > Thank you. > > -- > +---+ > | 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 > -- --- Praise the Caffeine embeddings ___ 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
On Thu, Sep 29, 2022 at 4:00 PM Marcel Telka wrote: > On Thu, Sep 29, 2022 at 03:18:29PM +0200, Aurélien Larcher wrote: > > I do not understand the need for obsoleting the entire package and > removing > > all the files instead of updating on the go. > > > > Could you explain the motivation? > > There is no particular need. It is just simpler to obsolete than to > update. And since there is no known consumer, then the obsoletion is > the obvious option chosen. > > > To me this seems a bit of overhead, like removing the mkdocs, cython, > numpy > > packages completely from the tree instead of updating them. > > Feel free to create PRs to get them back. > > > We therefore lose track of what was in the tree and people may start from > > scratch all over again. > > > > Maybe you intend to provide some level of automation later? > > Maybe. If I find it easy to do I'll do so, but I've no immediate plan > to do so. > > > An earlier heads-up before starting to remove everything could have been > > nice to have a chance to update a few components in advance and avoid the > > mumbo-jumbo. > > Sorry. I try to do my best. Nothing is perfect. > Sure, just at least a few days would be fine. Some of us cannot check the ML on a daily basis. > > Anyway, an earlier update/rebuild of those packages for non-EOLed python > would be nice from you before you left them fall out of support and be > surprised that they are disappearing. > > Sorry, talking is easy. > You are probably using this argument with the wrong person (you can look at the git history for example) but fair enough, I do not like talking for nothing either, just a discussion now and then to keep consistency across all the participants. > > > Thank you. > > -- > +---+ > | 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 > -- --- Praise the Caffeine embeddings ___ 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
On Thu, Sep 29, 2022 at 2:25 PM Marcel Telka wrote: > Hi, > > Currently we provide Python versions 2.7, 3.5, 3.7, and 3.9 for > OpenIndiana, while version 3.9 is the default version. > > Both Python 2.7 and 3.5 are no longer supported for two or almost three > years now respectively - see > https://devguide.python.org/versions/#versions for details, so we > started to obsolete them. Since there are many related packages that > needs to be rebuilt to get python 2.7 and 3.5 obsoleted, this transition > is expected to take long time (probably weeks, maybe months). > > There are basically two sets of related packages: > > #1 software that uses python (e.g. gimp), and > #2 packages that provide some enhancement to python; these are usually >python modules, for example cherrypy. > > For #1 we just need to rebuild packages that require python 2.7 or 3.5 > so they start to require either python 3.7, or python 3.9. Volunteers > are welcome! > > For #2 the situation is a bit more complex. The name of all packages in > this set is starting with 'library/python'. There is usually a basic > package (e.g. library/python/cherrypy) and few version specific packages > (e.g. library/python/cherrypy-35, library/python/cherrypy-37, > library/python/cherrypy-39). Another example is library/python/pycups > and its library/python/pycups-27 and library/python/pycups-35. > > For such packages we will slowly obsolete their -27 and -35 variants. > In a case there is neither -37 nor -39 variant already available, nor it > is needed for some other package, we will end up with all package > variants obsoleted. If this happens, then in addition to obsolete of > both -27 and -35 we will obsolete the base package too. > > For example, cherrypy. There are already -35, -37, and -39 variants. > We will obsolete the -35 variant and both -37 and -39 will be kept, so > we will keep the basic library/python/cherrypy too. > > When looking at pycups, we will obsolete both -27 and -35 variants. > Let's assume there is currently no other package that needs pycups, so > we would end with orphaned library/python/pycups, so we will obsolete > the library/python/pycups package too. > > Based on the rule above we already obsoleted following packages > recently: > > library/python/augeas > library/python/backports.shutil_get_terminal_size > library/python/backports.tempfile > library/python/cheetah > library/python/click > library/python/cssutils > library/python/cython > library/python/dulwich > library/python/geoip > library/python/elixir > library/python/import-profiler > library/python/kafka-python > library/python/livereload > library/python/m2crypto > library/python/mkdocs-bootstrap > library/python/mkdocs-bootswatch > library/python/mkdocs > library/python/netaddr > library/python/netifaces > library/python/numpy > library/python/pygtksourceview > library/python/pymongo > library/python/pyorbit > library/python/pyrex > library/python/pyro > library/python/python-ldap > library/python/python-memcached > library/python/python-mysql > library/python/python-notify > library/python/python-sexy > library/python/pywbem > library/python/scientific-py > library/python/sqlalchemy > library/python/typing > library/python/unittest2 > > Here is a list of packages that could get possibly obsoleted soon: > > library/python/backport_abc > library/python/backports.functools_lru_cache > library/python/backports.ssl_match_hostname > library/python/colorama > library/python/decorator > library/python/enum > library/python/flamegraph > library/python/funcsigs > library/python/ipaddress > library/python/ipython > library/python/ipython_genutils > library/python/notify2 > library/python/pickleshare > library/python/prompt-toolkit > library/python/pyatspi2 > library/python/pycups > library/python/pygobject > library/python/pygtk2 > library/python/python-compizconfig > library/python/python-xdg > library/python/python-xlib > library/python/rbtools > library/python/simplegeneric > library/python/traitlets > > If you need any package from these lists then please create a pull > request (see https://github.com/OpenIndiana/oi-userland/pulls) to get > the package back and built for python 3.7 and/or 3.9 (in a case it is on > the first list of already obsoleted packages), or either let us know or > create a pull request to rebuild the package for python 3.7 and/or 3.9 > (if it is on the second list of packages we could possibly obsolete). > > Any help with this task is very welcome (for example pull requests to > get software in set #1 rebuilt). > > Please note that support for building python modules for python 2.7 and > 3.5 was already dropped from oi-userland. > I do not understand the need for obsoleting the entire package and removing all the files instead of updating on the go. Could you explain the motivation? To me this seems a bit of overhead, like removing the mkdocs, cython, numpy packages completely from the tree instead of updating them. We therefore
[oi-dev] Miscellaneous component fixes and migrations
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
Re: [oi-dev] VLC maintainer ?
On Tue, May 3, 2022 at 9:44 PM s...@pandora.be wrote: > > - 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. > I am not sure my previous message was clear enough... What I meant is that there are known issues in the way VLC uses ffmpeg internally. Therefore as VLC changes somes ffmpeg flags (like forcing strict GPU capabilities), rendering in VLC using ffmpeg may stutter while ffmpeg may work perfectly when used directly to play the video. > > As soon as 3.0.18 is released I can create a new PR to update to VLC > 3.0.18. > Very nice :) > > Regards, > David Stes > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] VLC maintainer ?
On Sun, May 1, 2022 at 2:54 PM Andreas Wacknitz wrote: > Am 01.05.22 um 14:42 schrieb s...@pandora.be: > > I'm a user of the VLC media player on OpenIndiana; > > > > I've noticed that the videolan.org website lists 3.0.17.4 as the latest > version, while OpenIndiana delivers 3.0.16. > > > > Assuming that there is currently no OI maintainer for VLC, I'm creating > a PR (pull request) to update to 3.0.17.4, > > although obviously if the current VLC maintainer would like to continue > work on this package, > > that is not a problem of course. > > > > Regards, > > David Stes > > > > ___ > > oi-dev mailing list > > oi-dev@openindiana.org > > https://openindiana.org/mailman/listinfo/oi-dev > Everybody is free (and welcomed) to create PR's for every package in > oi-userland. > You should at least test it in your environment and write about how you > tested it in the PR's. > You should also check whether other packages are effected by an upgrade > and provide one or more helper PR's with rebuilds if needed. > Note that we cannot have upgrades and rebuilds of effected packages in > the same PR because that's how our build server works. > An update is not available before the build and deployment succeeded. > Thus, we need separate PR's for the upgrade of one package and a second > PR for its dependent packages. > 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. As I commented there is a problem with capabilities detection in VLC: the bottomline is that if the video plays fine with ffmpeg and stutters in VLC then it is a VLC bug. Kind regards, Aurélien > > Andreas > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] samba package needs a maintainer
On Tue, Mar 15, 2022 at 2:51 PM Stephan Althaus < stephan.alth...@duedinghausen.eu> wrote: > On 3/15/22 14:23, Andreas Wacknitz wrote: > > Hi all, > > > > our samba package doesn't build at the moment. It fails in the 64-bit > > part probably because of a missing flag. > > Alas this prevents for fixing man page collisions that have been > > introduced by an update of illumogs-gate (IPD4). > > > > I have stopped our nightly illumos-gate builds at rhe moment because of > > this but we need to find a solution for it soon. > > When the jenkins job will be ra-activated before we have a solution > > either everybody needs to uninstall samba or we need to obsolete the > > samba package. > > > > Short: We need to find a maintainer for the samba package otherwise it's > > doomed for OI. > > > > Regards, > > Andreas > > > > > > ___ > > oi-dev mailing list > > oi-dev@openindiana.org > > https://openindiana.org/mailman/listinfo/oi-dev > > Hello! > > I gave it a try. It seems some symbols are "lost" ;-) > > > [2687/3948] Linking bin/default/librpc/tools/ndrdump > Undefinedfirst referenced > symbol in file > __gmpn_sec_powm_itch/usr/lib/amd64/libhogweed.so.5 > __gmpn_sec_invert /usr/lib/amd64/libhogweed.so.5 > __gmpz_limbs_write /usr/lib/amd64/libgnutls.so > __gmpn_sec_div_r_itch /usr/lib/amd64/libhogweed.so.5 > __gmpz_limbs_finish /usr/lib/amd64/libgnutls.so > __gmpn_sec_invert_itch /usr/lib/amd64/libhogweed.so.5 > __gmpz_limbs_modify /usr/lib/amd64/libgnutls.so > __gmpn_sec_powm /usr/lib/amd64/libhogweed.so.5 > __gmpn_sec_add_1_itch /usr/lib/amd64/libhogweed.so.5 > __gmpn_sec_mul_itch /usr/lib/amd64/libhogweed.so.5 > __gmpz_roinit_n /usr/lib/amd64/libgnutls.so > __gmpn_sec_mul /usr/lib/amd64/libhogweed.so.5 > __gmpn_sec_add_1/usr/lib/amd64/libhogweed.so.5 > __gmpn_sec_div_r/usr/lib/amd64/libhogweed.so.5 > __gmpn_cnd_sub_n/usr/lib/amd64/libgnutls.so > __gmpn_cnd_add_n/usr/lib/amd64/libgnutls.so > __gmpz_limbs_read /usr/lib/amd64/libgnutls.so > ld: fatal: symbol referencing errors. No output written t > > > Anyone 'knows' some of these and has a hint ? > Probably just linking to the right libgmp (GNU Multiple Precision Library) provided with the compiler. There is also a system libgmp, make sure there is no mix up. > > Greetings, > > Stephan > > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] [developer] recompile oi-userland > gcc-7
On Mon, Feb 28, 2022 at 4:14 PM Klaus Ziegler wrote: > > > On 2/28/22 16:09, Toomas Soome via oi-dev wrote > > Multiply defined symbol means there are many object modules providing > the same symbol. This often happens because variable is declared in header > without ‘extern’. gcc 10 did switch on that warning - it was off in > previous versions. Many third party packages already have this fixed, so > you may want to check for updates…. > > > > rgds, > > toomas > > > Hi Toomas, > I allready did, the latest release of trousers has the same problem, so > I need to fix it myself looking for the symbol in header files and add > extern for the affected symbol (s) ? > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 You can add -fcommon to CFLAGS as a workaround. > > Rgds > Klaus > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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] Deprecation of 32-bit encumbered binaries
Hi, I have now deprecated 32-bit builds in the encumbered repository. This means that ffmpeg is now 64-bit only and audacity was migrated to 64-bit. The main motivation is that gcc-10 were failing for 32-bit builds and they are probably not worth the trouble. A few components in userland still rely on 32-bit gstreamer plugins: they should be migrated as well. I have already switched Gthumb to 64-bit yesterday. As a side effect, meson was fixed to handle static linking properly, you should update if you experience similar issues. 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] Fwd: [developer] SECURITY HEADS UP - illumos#14424
Given that illumos-gate is rebuilt every night, this change will land in Hipster by tomorrow; it was merged into illumos-gate 3 hours ago. Nonetheless I am forwarding the information in case it affects anyone subscribed to these mailing lists. -- Forwarded message - From: Dan McDonald Date: Tue, Jan 18, 2022 at 7:55 PM Subject: [developer] SECURITY HEADS UP - illumos#14424 To: illumos-developer , illumos-discuss < disc...@lists.illumos.org> Cc: Dan McDonald Hello folks! Quick breakdown: IMPACT: This bug allows an unprivileged user with access to a tmpfs to induce a denial of service to the system. This is more serious if untrusted users have access to the system (e.g. a shared environment). ACTION: Please be on the look out for patches from the various distributions and be ready to install them. MITIGATIONS: At this time, there are no known easy mitigations that one can apply short of disabling access to untrusted users and/or removing the ability to use tmpfs from their zones. NEXT STEPS: As we follow up on this, we'll be doing some additional auditing and looking to more generally strengthen our regression test suites to be able to catch issues like this in advance and ensure that that they are not reintroduced. . . . These details are also in https://www.illumos.org/issues/14424 Security researcher Hans Christian Woithe reported CVE-2021-43395 to both us and Oracle. He discovered conditions where any arbitrary user could induce tmpfs to panic with deadlock-detection. This bug tracks our fix for this problem. Tested using Hans's PoC, which now does not induce a panic. Tested on OmniOS both bare-metal (by Andy Fiddaman) and VM (by Dan McD.). Tested on SmartOS bare-metal (by Dan McD.). We will introduce more analysis into the bug report as this fix gets propagated. If you run a distro PLEASE PUT THIS FIX IN ANY SUPPORTED RELEASE YOU HAVE. It's easily backportable/cherry-pickable; I know OmniOS has it in their old-LTS r151030, for example. Thanks to Robert Mustacchi and Andy Fiddaman for feedback of earlier revisions of this fix. Thanks especially to security researcher Hans Christian Woithe, who informed us and Oracle of this very old bug. I appreciate he took the advice here: https://kebe.com/blog/?p=505 and I hope we reacted accordingly and politely (given we coordinated releasing this fix with Oracle). Please update your distros ASAP. And after some time, we'll update 14424 with details on how we arrived at the illumos fix. Thank you, Dan McDonald & Robert Mustacchi - on behalf of secur...@illumos.org -- illumos: illumos-developer Permalink: https://illumos.topicbox.com/groups/developer/T1c9e4f27f8c2f959-M152e45495ece9b9555b52167 Delivery options: https://illumos.topicbox.com/groups/developer/subscription -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] elegant way to get leaf packages?
On Sun, Dec 26, 2021 at 9:18 PM Till Wegmueller wrote: > Hey Tim > > You basically need to do what you are doing, but you can limit your > search to local with -l parameter to pkg search. That would result in > your local leaf packages. To get the full list for OI, the simplest way > is to grep the Makefiles for 32bit builds. They are explicitly mentioned > there. From what I remember it should only be library packages and big > hitters like libreoffice. > > There is a feature in omnios PKG which we could port at some point > (autoremove) and one could use the python API to write a script to do > that. But that would also call a lot of search queries. > It would be very nice as long as it does not work like APT's autoremove :p this one is really a pain... > > -Till > > On 26.12.21 15:20, Tim Mooney via oi-dev wrote: > > In regard to: Re: [oi-dev] elegant way to get leaf packages?,...: > > > >> I am not sure I understand your question. Please clarify. > > > > I'm using "leaf" in the same sense as in a computer science tree > > structure; a node that does not have any descendants. > > > > https://en.wikipedia.org/wiki/Tree_(data_structure) > > > > A tree isn't the best model for package dependencies; a directed graph > > is better, but the terminology for a node with no exiting vertices > > isn't as clear, so I used "leaf" thinking everyone would understand > > what I was asking for. Sorry if that just made things worse. > > > > A package like 'glib' or 'python-39' have many other packages that depend > > upon them. glib and python-39 are *not* leaf packages. > > > > An example of a 'leaf' package would be 'media/vlc'. There are > > (currently) no other OI packages that list media/vlc as a dependency. > > Leaf packages are typically "end user applications", but even something > > like 'editor/vim' is not a leaf, because it has at least one real package > > (editor/gvim and SUNWvim) that depends upon it. The distinction is a > > little fuzzy here because it also has 'mate_install' and 'server_install' > > as dependencies, but for my purposes I wouldn't count those. > > > > My reason for asking is that I wanted to get a complete list of all > > leaf packages for OI, and then see which of those packages still ship > > 32 bit binaries. I'm just trying to get an idea of easy components for > > conversion to be 64 bit only. > > > >> pkg exact-install installs a package but removes all > >> "leaf packages" (?) that are not a dependency of the given package. > > > > Thanks for the suggestion about exact-install, but for what I'm trying to > > identify, it's not really an option. It only looks at a portion of the > > dependency graph. > > > > As I said in my original question, I know how to generate the list using > > a brute force method. I was just wondering if there was a better method > > that doesn't require running hundreds or thousands of 'pkg' commands to > > find all the leaf nodes. > > > > Thanks, > > > > Tim > > > >>> 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? > > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] How to combine two source archives into one OI package?
On Fri, Dec 3, 2021 at 6:23 PM s...@pandora.be wrote: > > 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. > You could split first the package in two directories: https://github.com/OpenIndiana/oi-userland/commit/2de4e11a0f8069802bf0d32d3d937bb46edef321 Then provide the headers in /usr/include/pycairoXY like it was done for pycairo-27, and provide a symlink in the current version usr/include/pycairo/py3cairo.h -> usr/include/pycairoXY/py3cairo.h using a $(PYTHON_X.Y_ONLY) in the manifest to include it only in X.Y version (or use the GENFRAG manifest), same for the *.pc file. Actually file path=usr/include/pycairo is provided in py2cairo-27 as a symlink... so more work will be needed in the future... When ready to switch to 3.9 as default version you can republish but you will need a dependency to the 3.5 version that does not ship the symlinks to avoid conflicts. It seems a bit overkill to introduce a mediator. > > > > > > -- > > -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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Some X11 updates
On Thu, Aug 5, 2021 at 8:24 PM s...@pandora.be wrote: > > 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.0 > i-- > > 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 ? > I could only test the updates on my machines so it was just in case they affected others in some way. > > 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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Some X11 updates
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 s...@pandora.be wrote: > > 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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Some X11 updates
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
Re: [oi-dev] What to do with python module dependancies?
On Sun, Jul 18, 2021 at 4:47 PM Nona Hansel wrote: > Hello Gary, > > I believe that when you have a packages that has dependencies, these > dependencies must be added as individual packages themselves. After > incorporating them (which means create a folder, Makefile, .p5m file and > separate PR), your python package would find them. > > As for knowing in advance how many dependencies a package has, I usually > check the package in Fedora and Suse and see their spec files: > https://src.fedoraproject.org/ > https://build.opensuse.org/ > Also you can have a look at the pypi website. To verify a posteriori if the dependencies are satisfied you can use the pipdeptree command, it is packaged at: https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/python/pipdeptree > > I hope this was helpful. > Best regards, > Nona > > -- Původní e-mail -- > Od: Gary Mills > Komu: oi-dev@openindiana.org > Datum: 18. 7. 2021 16:02:07 > Předmět: [oi-dev] What to do with python module dependancies? > > I'm working on a python package that imports many other python > modules. So far I've discovered two python modules that don't have > corresponding packages in OI. There should be dependancies on these > two packages, but the automatic mechanism seems not to add them. > How can I add them myself? Do I do it directly in the P5M file? > > The original package builds and installs with the setup.py method. > It doesn't check for dependancies at all. I don't notice missing > dependancies until I test the module and get an error message when > an "import" fails. I'd like to be able to build a package that does > not have this problem. > > > -- > -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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Numpy - upgrade for Python 3.X
You can bump it safely and use Python 3.9, the only consumer is I think the boost/python bindings but this is not a big deal, go ahead. On Fri, Jul 16, 2021 at 2:08 PM Nona Hansel wrote: > Hello, > > I'm thinking about updating numpy since we have it just for Python 2.7. > But before doing any changes, I wanna consult some things for having a > clearer view of what to do. > > First, when I run > > pkg search -H -r -o pkg.name 'depend:require:library/python/numpy' > > I get: > library/python-2/numpy > > which tells me that there are no packages with numpy as a dependency, > right? > > Second, the newest version of numpy > https://github.com/numpy/numpy/releases supports Python 3.7. and 3.9. Is > that okay? I believe it is because Python 3.5. doesn't have numpy today > anyway and according to this web https://endoflife.date/python security > support for Python 3.5. has ended 10 months ago. > > I assume I can start working on it on Monday but it won't be finished any > time soon - the Makefile looks very complicated to me. > > Thank you for your insights. Any tips about this upgrade would be much > appreciated. > > Best regards, > Nona > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] DDU HCL submission - Dell Precision 3640 Intel(R) Core(TM) i3-10100 CPU
On Thu, Jun 24, 2021 at 8:15 PM s...@pandora.be wrote: > > Last update on > > https://wiki.openindiana.org/oi/Servers+and+Workstations > > says: last modified by Michal Nowak on May 13, 2018 > > That's from 2018, there is a need to update the Hardware Compatibility > Guide !! > > The HCL seems to have moved to > http://docs.openindiana.org/community-hcl/systems/ > > OpenIndiana 2020.04 and 2021.04 seems to install and work on the Dell > Precision 3640 workstation. > > See screenshot oi-dell-precision-3640 in attach. > > The text install 2020.04 worked fine (UEFI boot since this is a EFI > system), > and installation went fine on a SATA boot disk from physical CD-ROM. > > I didn't try a SSD boot disk. > > Audio seems to work fine as well > (onboard audio Comet Lake PCH cAWS or Nvidia, not sure 2 cards are listed > in DDU) > > Video (MATE lightdm as well) on NVidia as well - but not on the onboard > Intel UHD 630. > > The intel onboard UHD 630 card works in vgatext for booting multi-user or > console. > > On the Nvidia card, openindiana MATE runs fine in X11 with the nvidia > driver and config/settings tool. > > I ran diagnostics/ddu and it finds a few unknown devices for which it > installed one package > > Intel Corporation Comet Lake PCH Termal Controller > > ddu installed a driver for the above > > Should I worry about the remaining 4 unknown devices ? > > Intel Corporation Comet Lake PCH Serial IO I2C Controller #0 > > Intel Corporation Comet Lake PCH Serial IO I2C Controller #1 > Intel Corporation Comet Lake HECI Controller > Intel Corporation Comet Lake PCH SPI Controller > > I'm unable to submit an entry for this system. > > When I click Submit I get : " OpenIndiana HCL server is not active. " > > Also the DDU is not recognizing the i3-10100 CPU. It just prints CPU : 1X > instead of something like 1X Intel(R) Core(TM) i3-10100 CPU > > However psrinfo and prtdiag seem ok and the system seems to run fine. > > Is the feedback address hcl-feedb...@openindiana.org still active ? > It is an alias to my email address. > > Possibly this system could be added to the OpenIndiana HCL as a new > submission, > or I'll try to see whether I can add it to the docs ... > > Regards, > David Stes > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Upgrade of gdb to 8.0 and python 3.7
On Wed, May 19, 2021 at 11:44 PM Gary Mills wrote: > This message is just to inform the OI developers that I'm working on > gdb now. It will be a version upgrade from 7.10.1 to 8.0 and a python > upgrade from 2.7 to 3.7 . Gdb version 8.0 is the Oracle Solaris > freeware version, used in the current Solaris. I know that the > current gdb version is 10.2, but 8.0 comes with a set of patches that > are known to work with Solaris, and will likely work with OI. > > Note that the gdb presently included with OI has 63 patches. I'm not > about to review all of those. Version 8.0 has only eight patches. > All of them seem to work. > > All I have to do before creating a PR is to do a bit of testing with > the new gdb. The important thing is to remove the current dependancy > on python-2, so we can get rid of that version of python. I also > intend to try some more recent versions of gdb to see if they also > work with the Solaris patches. > This is a very good strategy, thank you for your work on this :) > > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, > Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Distribution build system requirements?
On Tue, Apr 6, 2021 at 12:45 AM Reginald Beardsley via oi-dev < oi-dev@openindiana.org> wrote: > What computer resources are needed to build all the distribution images > overnight, i.e. 8 hours, from a local repository? > On my workstation (4 year old 10 core machine with 48GB RAM) it takes a ~2h if I remember correctly. I do not think it is CPU bound as the work is mainly serialized. > I'm on a 3 Mb/s downlink, so as a practical matter I'm better off building > and testing release candidates locally. > > I'd like to take on the work. It's a few weeks twice a year which I can > comfortably manage. I have plenty of professional experience producing > internal software releases in major oil companies. > > I've also done FreeBSD, Debian, Solaris 11 and Solaris 10 installs in the > last week. For all the flaws I encountered in the Hipster 2020.10 images, > it's still better than the others in many ways. I'm proposing to work on > the software to build the installation media with a strong focus on > intensive testing of the install process and making it more flexible. > Once you have the distro constructor set up on the machine it is fairly easy. I expected the initial setup would take ~30min and some trial and error to modify the vanilla manifests. e.g. to use your own local repository to spin custom images. > > The installation process is the new user's first impression. Gparted not > working doesn't give a good impression. Nor does, "you can only use 2 TB > of your new 5 TB disk". I'd like to fix that. > I know gparted is not great... I attempted to port our patchset to newer versions a long time ago but it was too much work... > > Have Fun! > Reg > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] shell/ksh93
On Tue, Mar 30, 2021 at 11:44 PM Jim Klimov wrote: > On March 30, 2021 5:57:11 PM UTC, Gary Mills > wrote: > >On Tue, Mar 30, 2021 at 05:53:00PM +0200, s...@pandora.be wrote: > >> > >> I think there is no need to do bulk conversion of OpenIndiana > >> packages, due to the change (the commit > >> c063eb990f530561e469b3c1e4bb64230456c0da in illumos-gate). > > > >> Older versions of packages that depend on SUNWcs (core solaris or > >> core system) continue to work fine. > > > >> New versions of packages can modify their manifest and Makefile and > >> require pkg:/shell/ksh93. > Probably just add REQUIRED_PACKAGES += shell/ksh93 in shared-macros.mk If this is not enough then fix the script that generates REQUIRED_PACKAGES to avoid re-adding in the Makefile dependencies that have already been listed in the make-rules/*.mk files. > > >This analysis seems correct, at least for installed systems. We do > >have to think about updates to installed systems, new installations, > >and the build system, however. > > > >As long as the ksh package is a dependancy of another package that is > >always installed, it will always be installed as well. That situation > >should be fine for updates and new installations. > > > >Certainly the OI build system will be affected. I'm assuming that > >this system only rebuilds packages when something in them has changed. > >So, some of those packages will fail to build, because they do not > >have the new ksh package in the REQUIRED_PACKAGES gmake variable. The > >easiest course might be to fix the Makefile of various packages as the > >rebuild breaks. An alternative might be to identify the packages and > >fix them in advance, so that the rebuild succeeds. I don't think that > >a permanent global fix is possible for the build system. > > Hi all, > > I currently presume (did not check to prove) that SUNWcs might (for some > transition period or forever) depend on shell/ksh93 and so package builds > with unchanged recipes would succeed. Just two packages instead of one, > delivering more or less same bytes. > > Updating recipes may be more due to optimization (do we really need the > bulk of OS/Net in the scratch build zone to build this script-only > package), if SUNWcs is/will-be-one-day at all avoidable as an installation > footprint, and/or if an older version may be deployed and unchanged since > golden image because it is not a relevant critical part of the recipe > requirements? > > And possibly limit the impact of inverse dependencies (we critically > changed a low-level dependency so everyone using them should get rebuilt - > the attack surface of ksh93 alone is smaller than SUNWcs altogether). > > No idea if there's a grain of practical truth to my ideas above, just > that's what I think about it today, based on experience with various OSes > and build systems, until proven wrong :) > > Jim > > > > -- > Typos courtesy of K-9 Mail on my Android > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] gcc builds - no cc1objplus
On Mon, Feb 22, 2021 at 7:16 PM Andreas Wacknitz wrote: > Am 22.02.21 um 13:38 schrieb Klaus Ziegler - owner of sunfreeware.de: > > Hi, > > > > is there any reason why we don't provide cc1objplus compiler in gcc > > builds? > Most probably because nobody uses it and if we merge it into OI Hipster > we will have to support it. > Thus, additional work and not much gain. > Indeed nobody uses this... > > > > --- Makefile.orig2021-02-21 21:09:30.515646158 + > > +++ Makefile2021-02-21 21:17:44.199125768 + > > @@ -47,7 +47,7 @@ > > CONFIGURE_OPTIONS+= --enable-plugins > > CONFIGURE_OPTIONS+= --enable-objc-gc > > CONFIGURE_OPTIONS.i386+= --enable-initfini-array > > -CONFIGURE_OPTIONS+= --enable-languages=c,c++,fortran,lto,objc > > +CONFIGURE_OPTIONS+= --enable-languages=c,c++,fortran,lto,objc,obj-c++ > > CONFIGURE_OPTIONS+= --disable-libitm > > CONFIGURE_OPTIONS+= enable_frame_pointer=yes > > > > maybe just forgotten? however including it does not harm at all, > > and the tests for it also work fine: > > > > === obj-c++ tests === > > > > > > Running target unix/-m64 > > > > === obj-c++ Summary for unix/-m64 === > > > > # of expected passes1451 > > # of expected failures10 > > # of unsupported tests77 > > > > Running target unix/-m64/-msave-args > > > > === obj-c++ Summary for unix/-m64/-msave-args === > > > > # of expected passes1451 > > # of expected failures10 > > # of unsupported tests77 > > > > === obj-c++ Summary === > > > > # of expected passes2902 > > # of expected failures20 > > # of unsupported tests154 > > > > Much Regards > > Klaus > > > > ___ > > oi-dev mailing list > > oi-dev@openindiana.org > > https://openindiana.org/mailman/listinfo/oi-dev > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: Re: requests-37
On Wed, 17 Feb 2021, 7:43 pm Andreas Wacknitz, wrote: > Am 17.02.21 um 19:17 schrieb Nona Hansel: > > Hello again, > > since I have installed new versions today, I get the same warning every > time I use pkg. > > /usr/lib/python3.7/vendor-packages/requests/__init__.py:91: > RequestsDependencyWarning: urllib3 (1.25.1) or chardet (4.0.0) doesn't > match a supported version! > RequestsDependencyWarning) > > But it looks like the version 2.25.1 could work with chardet 4.0.0: > https://github.com/psf/requests/blame/master/setup.py#L44 > > Can I try to update requests to this version or was there a particular > reason why to have 2.22? > > I don't know, alarcher may have an answer. > It seems I forgot to push the update... > If you create a PR for a newer request version make sure that it support > Python 2.7 or else you'll need to split the package into one for Python 2.7 > and another one for Python 3 versions. > > Regards, > Andreas > > > > Regards, > Nona > > -- Původní e-mail -- > Od: Nona Hansel > Komu: OpenIndiana Developer mailing list > > Datum: 17. 2. 2021 10:22:26 > Předmět: Re: [oi-dev] requests-37 > > I'm trying to fix it and the requests publishes and locally installs fine, > but when I try to use it in python3.7: > > >>> import requests > > I get this message: > /usr/lib/python3.7/vendor-packages/requests/__init__.py:91: > RequestsDependencyWarning: urllib3 (1.25.1) or chardet (4.0.0) doesn't > match a supported version! > RequestsDependencyWarning) > > When I ask pipdeptree, it gives me this: > > requests==2.22.0 > - chardet [required: >=3.0.2,<3.1.0, installed: 4.0.0] > - idna [required: >=2.5,<2.9, installed: 2.10] > - urllib3 [required: >=1.21.1,<1.26,!=1.25.0, installed: 1.25.1] > > It looks like the version of chardet and maybe idna are outside of > requests' scope of supported versions. Is there a way how to make requests > use the previous versions? > Thank you! > > -- Původní e-mail -- > Od: Aurélien Larcher > > Komu: OpenIndiana Developer mailing list > > Datum: 16. 2. 2021 18:57:38 > Předmět: Re: [oi-dev] requests-37 > > Probably I messed up the rebase and -$(PYV) is missing from the > manifest in the fmri. > > On 2/16/21, Nona Hansel wrote: > > > > Hello, > > > > > > > > > > I'm trying to install requests-37 which according to it's Makefile we > > should > > provide, but when I ask for it: > > > > > > > > > > $ pfexec pkg info -r library/python/requests* > > > > > > > > > > it doesn't show it nor it shows requests-39. > > > > > > > > > > It can't be found here: > > https://pkg.openindiana.org/hipster/en/search.shtml? > > action=Search&token=requests-37&failed=1 > > > > and when I try to find requests-35 in this website, it finds the > previous > > version. > > > > > > > > > > Isn't there something wrong with this component? > > > > > > > > > > Thank you, > > > > Nona > > > > > -- > --- > Praise the Caffeine embeddings > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > > > ___ > oi-dev mailing > listoi-dev@openindiana.orghttps://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] requests-37
Probably I messed up the rebase and -$(PYV) is missing from the manifest in the fmri. On 2/16/21, Nona Hansel wrote: > > Hello, > > > > > I'm trying to install requests-37 which according to it's Makefile we > should > provide, but when I ask for it: > > > > > $ pfexec pkg info -r library/python/requests* > > > > > it doesn't show it nor it shows requests-39. > > > > > It can't be found here: > https://pkg.openindiana.org/hipster/en/search.shtml? > action=Search&token=requests-37&failed=1 > > and when I try to find requests-35 in this website, it finds the previous > version. > > > > > Isn't there something wrong with this component? > > > > > Thank you, > > Nona > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] screen: CVE-2021-26937
Hi, make sure to update your screen package rather sooner than later. The new package will land in the repository within an hour. Kind regards, Aurélien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OpenSSL update process
On Sun, Feb 7, 2021 at 5:02 PM Andreas Wacknitz wrote:
> Am 07.02.21 um 14:09 schrieb Aurélien Larcher:
>
>
>
> On Sun, Feb 7, 2021 at 1:21 PM Andreas Wacknitz wrote:
>
>> Am 06.02.21 um 21:56 schrieb Aurélien Larcher:
>>
>>
>> OpenSSL 1.1 is now merged:
>>
>> 1. The mediator is default set to 1.0 but can be safely set to 1.1.
>> 2. illumos-gate is patched to accept library/security/openssl-11 as
>> dependency so that it builds when the mediator version is 1.1.
>> 3. oi-userland has now a switch USE_OPENSSL10=yes or USE_OPENSSL11=yes
>> which should be placed before shared-macros.mk is included.
>> 4. If 'gmake update' is executed in a component depending on OpenSSL then
>> the switch is made to OpenSSL 1.1 unless USE_OPENSSL10=yes is set.
>>
>> Now the fun begins:
>>
>> 3. Move all the components supporting OpenSSL 1.1 or update them.
>>> 4. Deprecate possible rotting components which cannot be updated and may
>>> cause security issues.
>>>
>>
>> and... the more, the merrier!
>>
>>
>> Cheers
>>
>>
>> ___
>> oi-dev mailing
>> listoi-dev@openindiana.orghttps://openindiana.org/mailman/listinfo/oi-dev
>>
>> Hi,
>>
>> do we have a problem with missing engine files in the openssl-11 package?
>>
>> ╰─➤ cat /usr/openssl/1.1/lib/pkgconfig/libcrypto.pc
>> prefix=/usr/openssl/1.1
>> exec_prefix=${prefix}
>> libdir=${exec_prefix}/lib/
>> includedir=${prefix}/include
>> enginesdir=${libdir}/engines-1.1
>>
>> Name: OpenSSL-libcrypto
>> Description: OpenSSL cryptography library
>> Version: 1.1.1i
>> Libs: -L${libdir} -lcrypto
>> Libs.private: -lsocket -lnsl -ldl -pthread
>> Cflags: -I${includedir}
>>
>> So, libcrypto.pc states that there shall be /usr/openssl/1.1/lib/engine
>> files but there aren't any (same for 64-bit):
>>
>
> It seems like they did not bother to remove the enginesdir variable from
> the .pc file if engines are not built...
>
> We could ship an empty directory or patch the .pc files but if you think
> that it is better to ship the engines we can do that also.
> I do not really know who consumes them...
>
> I don't know, too. But letting a .pc file pointing to something
> non-existing is the worst way imo.
>
But there is no support for them in any case so the probability that a
broken build system would use that path after detecting that engines are
not shipped is thin...
Best would probably be to ship them where they are expected.
>
If you have time you could just enable them and publish a new openssl, but
even then we do not ship pk11 unless someone takes time to look at it.
There are no consumers so it is likely not going to make much difference
but at least consistency is restored.
Do want you think is best.
___
> oi-dev mailing list
> oi-dev@openindiana.org
> 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
Re: [oi-dev] OpenSSL update process
The mediator was introduced with revision 3. On Sunday, February 7, 2021, Gary Mills wrote: > On Sun, Feb 07, 2021 at 11:29:28AM +0100, Andreas Wacknitz wrote: >> >> If /usr/include/openssl does not point anywhere probably the >> mediator is >> not set to a right version or openssl-11 is not installed: >> narval> pkg mediator openssl >> MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION >> openssl local 1.1 local openssl > > Something is peculiar here. I'm still using the previous version > of openssl: > > $ pkg list library/security/openssl > NAME (PUBLISHER) VERSION IFO > library/security/openssl 1.0.2.21-2020.0.1.2 i-- > $ pkg mediator openssl > MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION > openssl vendorvendor default > > Note that there is no version number. > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] OpenSSL update process
On Sun, Feb 7, 2021 at 1:21 PM Andreas Wacknitz wrote:
> Am 06.02.21 um 21:56 schrieb Aurélien Larcher:
>
>
> OpenSSL 1.1 is now merged:
>
> 1. The mediator is default set to 1.0 but can be safely set to 1.1.
> 2. illumos-gate is patched to accept library/security/openssl-11 as
> dependency so that it builds when the mediator version is 1.1.
> 3. oi-userland has now a switch USE_OPENSSL10=yes or USE_OPENSSL11=yes
> which should be placed before shared-macros.mk is included.
> 4. If 'gmake update' is executed in a component depending on OpenSSL then
> the switch is made to OpenSSL 1.1 unless USE_OPENSSL10=yes is set.
>
> Now the fun begins:
>
> 3. Move all the components supporting OpenSSL 1.1 or update them.
>> 4. Deprecate possible rotting components which cannot be updated and may
>> cause security issues.
>>
>
> and... the more, the merrier!
>
>
> Cheers
>
>
> ___
> oi-dev mailing
> listoi-dev@openindiana.orghttps://openindiana.org/mailman/listinfo/oi-dev
>
> Hi,
>
> do we have a problem with missing engine files in the openssl-11 package?
>
> ╰─➤ cat /usr/openssl/1.1/lib/pkgconfig/libcrypto.pc
> prefix=/usr/openssl/1.1
> exec_prefix=${prefix}
> libdir=${exec_prefix}/lib/
> includedir=${prefix}/include
> enginesdir=${libdir}/engines-1.1
>
> Name: OpenSSL-libcrypto
> Description: OpenSSL cryptography library
> Version: 1.1.1i
> Libs: -L${libdir} -lcrypto
> Libs.private: -lsocket -lnsl -ldl -pthread
> Cflags: -I${includedir}
>
> So, libcrypto.pc states that there shall be /usr/openssl/1.1/lib/engine
> files but there aren't any (same for 64-bit):
>
> ╭─andreas@skoll /usr/openssl/1.1/lib/pkgconfig
> ╰─➤ ls -l /usr/openssl/1.1/lib
> total 7445
> lrwxrwxrwx 1 root root 1 Feb 6 11:17 32 -> ./
> lrwxrwxrwx 1 root root 5 Feb 6 11:17 64 -> amd64/
> lrwxrwxrwx 1 root root 12 Feb 6 11:17 CA.pl ->
> ../bin/CA.pl*
> drwxr-xr-x 3 root sys7 Feb 6 11:17 amd64/
> lrwxrwxrwx 1 root root 16 Feb 6 11:17 libcrypto.so ->
> libcrypto.so.1.1*
> -r-xr-xr-x 1 root bin 2947532 Feb 6 11:17 libcrypto.so.1.1*
> lrwxrwxrwx 1 root root 13 Feb 6 11:17 libssl.so ->
> libssl.so.1.1*
> -r-xr-xr-x 1 root bin 748144 Feb 6 11:17 libssl.so.1.1*
> drwxr-xr-x 2 root sys5 Feb 6 11:17 pkgconfig/
>
> "pkg contents openssl-11" doesn't show any engine files in the package.
>
>
> Maybe unrelated to this: At the moment I try to build remmina with
> openssl-1.1 but it fails to link:
>
> [100%] Linking C executable remmina
> Undefinedfirst referenced
> symbol in file
> ERR_load_crypto_strings
> CMakeFiles/remmina.dir/remmina_stats_sender.c.o
> ERR_free_strings
> CMakeFiles/remmina.dir/remmina_stats_sender.c.o
> ld: fatal: symbol referencing errors. No output written to remmina
>
Could it be that libcrypto and libssl are linked in the wrong order or that
you need to repeat one of the libs in the list?
Unlike GNU ld our ld does not try to be smart and reorder the libs (in a
possibly disastrous way).
> Regards,
> Andreas
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> 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
Re: [oi-dev] OpenSSL update process
On Sun, Feb 7, 2021 at 1:21 PM Andreas Wacknitz wrote:
> Am 06.02.21 um 21:56 schrieb Aurélien Larcher:
>
>
> OpenSSL 1.1 is now merged:
>
> 1. The mediator is default set to 1.0 but can be safely set to 1.1.
> 2. illumos-gate is patched to accept library/security/openssl-11 as
> dependency so that it builds when the mediator version is 1.1.
> 3. oi-userland has now a switch USE_OPENSSL10=yes or USE_OPENSSL11=yes
> which should be placed before shared-macros.mk is included.
> 4. If 'gmake update' is executed in a component depending on OpenSSL then
> the switch is made to OpenSSL 1.1 unless USE_OPENSSL10=yes is set.
>
> Now the fun begins:
>
> 3. Move all the components supporting OpenSSL 1.1 or update them.
>> 4. Deprecate possible rotting components which cannot be updated and may
>> cause security issues.
>>
>
> and... the more, the merrier!
>
>
> Cheers
>
>
> ___
> oi-dev mailing
> listoi-dev@openindiana.orghttps://openindiana.org/mailman/listinfo/oi-dev
>
> Hi,
>
> do we have a problem with missing engine files in the openssl-11 package?
>
> ╰─➤ cat /usr/openssl/1.1/lib/pkgconfig/libcrypto.pc
> prefix=/usr/openssl/1.1
> exec_prefix=${prefix}
> libdir=${exec_prefix}/lib/
> includedir=${prefix}/include
> enginesdir=${libdir}/engines-1.1
>
> Name: OpenSSL-libcrypto
> Description: OpenSSL cryptography library
> Version: 1.1.1i
> Libs: -L${libdir} -lcrypto
> Libs.private: -lsocket -lnsl -ldl -pthread
> Cflags: -I${includedir}
>
> So, libcrypto.pc states that there shall be /usr/openssl/1.1/lib/engine
> files but there aren't any (same for 64-bit):
>
It seems like they did not bother to remove the enginesdir variable from
the .pc file if engines are not built...
We could ship an empty directory or patch the .pc files but if you think
that it is better to ship the engines we can do that also.
I do not really know who consumes them...
>
> ╭─andreas@skoll /usr/openssl/1.1/lib/pkgconfig
> ╰─➤ ls -l /usr/openssl/1.1/lib
> total 7445
> lrwxrwxrwx 1 root root 1 Feb 6 11:17 32 -> ./
> lrwxrwxrwx 1 root root 5 Feb 6 11:17 64 -> amd64/
> lrwxrwxrwx 1 root root 12 Feb 6 11:17 CA.pl ->
> ../bin/CA.pl*
> drwxr-xr-x 3 root sys7 Feb 6 11:17 amd64/
> lrwxrwxrwx 1 root root 16 Feb 6 11:17 libcrypto.so ->
> libcrypto.so.1.1*
> -r-xr-xr-x 1 root bin 2947532 Feb 6 11:17 libcrypto.so.1.1*
> lrwxrwxrwx 1 root root 13 Feb 6 11:17 libssl.so ->
> libssl.so.1.1*
> -r-xr-xr-x 1 root bin 748144 Feb 6 11:17 libssl.so.1.1*
> drwxr-xr-x 2 root sys5 Feb 6 11:17 pkgconfig/
>
> "pkg contents openssl-11" doesn't show any engine files in the package.
>
>
> Maybe unrelated to this: At the moment I try to build remmina with
> openssl-1.1 but it fails to link:
>
> [100%] Linking C executable remmina
> Undefinedfirst referenced
> symbol in file
> ERR_load_crypto_strings
> CMakeFiles/remmina.dir/remmina_stats_sender.c.o
> ERR_free_strings
> CMakeFiles/remmina.dir/remmina_stats_sender.c.o
> ld: fatal: symbol referencing errors. No output written to remmina
>
> Regards,
> Andreas
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
>
--
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OpenSSL update process
On Sun, Feb 7, 2021 at 1:21 PM Andreas Wacknitz wrote:
> Am 06.02.21 um 21:56 schrieb Aurélien Larcher:
>
>
> OpenSSL 1.1 is now merged:
>
> 1. The mediator is default set to 1.0 but can be safely set to 1.1.
> 2. illumos-gate is patched to accept library/security/openssl-11 as
> dependency so that it builds when the mediator version is 1.1.
> 3. oi-userland has now a switch USE_OPENSSL10=yes or USE_OPENSSL11=yes
> which should be placed before shared-macros.mk is included.
> 4. If 'gmake update' is executed in a component depending on OpenSSL then
> the switch is made to OpenSSL 1.1 unless USE_OPENSSL10=yes is set.
>
> Now the fun begins:
>
> 3. Move all the components supporting OpenSSL 1.1 or update them.
>> 4. Deprecate possible rotting components which cannot be updated and may
>> cause security issues.
>>
>
> and... the more, the merrier!
>
>
> Cheers
>
>
> ___
> oi-dev mailing
> listoi-dev@openindiana.orghttps://openindiana.org/mailman/listinfo/oi-dev
>
> Hi,
>
> do we have a problem with missing engine files in the openssl-11 package?
>
> ╰─➤ cat /usr/openssl/1.1/lib/pkgconfig/libcrypto.pc
> prefix=/usr/openssl/1.1
> exec_prefix=${prefix}
> libdir=${exec_prefix}/lib/
> includedir=${prefix}/include
> enginesdir=${libdir}/engines-1.1
>
> Name: OpenSSL-libcrypto
> Description: OpenSSL cryptography library
> Version: 1.1.1i
> Libs: -L${libdir} -lcrypto
> Libs.private: -lsocket -lnsl -ldl -pthread
> Cflags: -I${includedir}
>
> So, libcrypto.pc states that there shall be /usr/openssl/1.1/lib/engine
> files but there aren't any (same for 64-bit):
>
> ╭─andreas@skoll /usr/openssl/1.1/lib/pkgconfig
> ╰─➤ ls -l /usr/openssl/1.1/lib
> total 7445
> lrwxrwxrwx 1 root root 1 Feb 6 11:17 32 -> ./
> lrwxrwxrwx 1 root root 5 Feb 6 11:17 64 -> amd64/
> lrwxrwxrwx 1 root root 12 Feb 6 11:17 CA.pl ->
> ../bin/CA.pl*
> drwxr-xr-x 3 root sys7 Feb 6 11:17 amd64/
> lrwxrwxrwx 1 root root 16 Feb 6 11:17 libcrypto.so ->
> libcrypto.so.1.1*
> -r-xr-xr-x 1 root bin 2947532 Feb 6 11:17 libcrypto.so.1.1*
> lrwxrwxrwx 1 root root 13 Feb 6 11:17 libssl.so ->
> libssl.so.1.1*
> -r-xr-xr-x 1 root bin 748144 Feb 6 11:17 libssl.so.1.1*
> drwxr-xr-x 2 root sys5 Feb 6 11:17 pkgconfig/
>
> "pkg contents openssl-11" doesn't show any engine files in the package.
>
Engines are not shipped with 1.1.
>
>
> Maybe unrelated to this: At the moment I try to build remmina with
> openssl-1.1 but it fails to link:
>
> [100%] Linking C executable remmina
> Undefinedfirst referenced
> symbol in file
> ERR_load_crypto_strings
> CMakeFiles/remmina.dir/remmina_stats_sender.c.o
> ERR_free_strings
> CMakeFiles/remmina.dir/remmina_stats_sender.c.o
> ld: fatal: symbol referencing errors. No output written to remmina
>
> Regards,
> Andreas
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
>
--
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OpenSSL update process
Are you sure you did not change the mediator before installing 1.1? This is the only reason I can see. Switch back to 1.0 and this should be OK. For some reason pkg allows switching to a nonexistent mediator and then is in a dangling state. On Sunday, February 7, 2021, Tim Mooney via oi-dev wrote: > In regard to: Re: [oi-dev] OpenSSL update process, Aurélien Larcher said...: > >> On Sun, Feb 7, 2021 at 12:33 AM Tim Mooney via oi-dev < >> oi-dev@openindiana.org> wrote: >> >>> In regard to: Re: [oi-dev] OpenSSL update process, Aurélien Larcher >>> said...: >>> >>>> OpenSSL 1.1 is now merged: >>>> >>>> 1. The mediator is default set to 1.0 but can be safely set to 1.1. >>> >>> Is changing the mediator supposed to make /usr/include/openssl/ >>> available, or is that supposed to be done by shared-macros.mk after >>> setting USE_OPENSSL11=yes, or do we now need to specify >>> -I$(OPENSSL_PREFIX)/include in the component Makefile? >>> >>> I've changed the mediator and done a git pull to get the latest >>> oi-userland bits. 'gmake update' now works in e.g. >>> components/perl/net-ssleay/ but the build step doesn't know where to look >>> for the headers. >>> >> >> If /usr/include/openssl does not point anywhere probably the mediator is >> not set to a right version or openssl-11 is not installed: >> >> narval> pkg mediator openssl >> MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION >> openssl local 1.1 local openssl >> >> narval> ls -lha /usr/include/openssl >> lrwxrwxrwx 1 root staff 30 Feb 5 22:54 /usr/include/openssl -> >> ../openssl/1.1/include/openssl >> >> But you should not need to change the mediator to build the package unless >> the component's own build system is buggy. > > openssl-11 is installed and I went ahead and changed the mediator before > even attempting the build, since I didn't know it wasn't strictly > required. > > $ pkg mediator openssl > MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION > openssl local 1.1 local system > > $ pkg list | egrep openssl > library/python/pyopenssl (openindiana.org)16.2.0-2020.0.1.4 i-- > library/python/pyopenssl-27 (openindiana.org) 16.2.0-2020.0.1.4 i-- > library/python/pyopenssl-35 (openindiana.org) 16.2.0-2020.0.1.4 i-- > library/security/openssl (openindiana.org)1.0.2.21-2020.0.1.3 i-- > library/security/openssl-11 (openindiana.org) 1.1.1.9-2020.0.1.0 i-- > > $ ls -lha /usr/include/openssl > /usr/include/openssl: No such file or directory > >> In any case openssl-11 should install automatically at your next update >> since I pushed a new wget package depending on it. > > I'll pkg update again and see if the situation improves. > > > 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 -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OpenSSL update process
On Sun, Feb 7, 2021 at 12:33 AM Tim Mooney via oi-dev < oi-dev@openindiana.org> wrote: > In regard to: Re: [oi-dev] OpenSSL update process, Aurélien Larcher > said...: > > > OpenSSL 1.1 is now merged: > > > > 1. The mediator is default set to 1.0 but can be safely set to 1.1. > > Is changing the mediator supposed to make /usr/include/openssl/ > available, or is that supposed to be done by shared-macros.mk after > setting USE_OPENSSL11=yes, or do we now need to specify > -I$(OPENSSL_PREFIX)/include in the component Makefile? > > I've changed the mediator and done a git pull to get the latest > oi-userland bits. 'gmake update' now works in e.g. > components/perl/net-ssleay/ but the build step doesn't know where to look > for the headers. > If /usr/include/openssl does not point anywhere probably the mediator is not set to a right version or openssl-11 is not installed: narval> pkg mediator openssl MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION openssl local 1.1 local openssl narval> ls -lha /usr/include/openssl lrwxrwxrwx 1 root staff 30 Feb 5 22:54 /usr/include/openssl -> ../openssl/1.1/include/openssl But you should not need to change the mediator to build the package unless the component's own build system is buggy. In any case openssl-11 should install automatically at your next update since I pushed a new wget package depending on it. Do not hesitate if you have any other questions. Also you can report if the 'gmake update' trick does not work for some components, it is after all based on a hastily written piece of python by a non-python developer :P Kind regards, Aurélien > > 2. illumos-gate is patched to accept library/security/openssl-11 as > > dependency so that it builds when the mediator version is 1.1. > > 3. oi-userland has now a switch USE_OPENSSL10=yes or USE_OPENSSL11=yes > > which should be placed before shared-macros.mk is included. > > 4. If 'gmake update' is executed in a component depending on OpenSSL then > > the switch is made to OpenSSL 1.1 unless USE_OPENSSL10=yes is set. > > > > Now the fun begins: > > > > 3. Move all the components supporting OpenSSL 1.1 or update them. > >> 4. Deprecate possible rotting components which cannot be updated and may > >> cause security issues. > >> > > > > and... the more, the merrier! > > 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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OpenSSL update process
> 1. The mediator is default set to 1.0 but can be safely set to 1.1. > > Is changing the mediator supposed to make /usr/include/openssl/ > available, or is that supposed to be done by shared-macros.mk after > setting USE_OPENSSL11=yes, or do we now need to specify > -I$(OPENSSL_PREFIX)/include in the component Makefile? > The mediator can stay as it is on 1.0 for now. Technically the switch with USE_OPENSSL1X: 1. preprends the directory $(OPENSSL_BINDIR) to PATH, 2. preprends $(OPENSSL_PKG_CONFIG_PATH) to PKG_CONFIG_PATH, so that any build system relying on pkg-config files or the openssl binary to detect the paths and the version would get the right one. However if you change the mediator to 1.1 you should make sure that library/security/openssl-11 is installed. > I've changed the mediator and done a git pull to get the latest > oi-userland bits. 'gmake update' now works in e.g. > components/perl/net-ssleay/ but the build step doesn't know where to look > for the headers. > > > 2. illumos-gate is patched to accept library/security/openssl-11 as > > dependency so that it builds when the mediator version is 1.1. > > 3. oi-userland has now a switch USE_OPENSSL10=yes or USE_OPENSSL11=yes > > which should be placed before shared-macros.mk is included. > > 4. If 'gmake update' is executed in a component depending on OpenSSL then > > the switch is made to OpenSSL 1.1 unless USE_OPENSSL10=yes is set. > > > > Now the fun begins: > > > > 3. Move all the components supporting OpenSSL 1.1 or update them. > >> 4. Deprecate possible rotting components which cannot be updated and may > >> cause security issues. > >> > > > > and... the more, the merrier! > > 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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OpenSSL update process
OpenSSL 1.1 is now merged: 1. The mediator is default set to 1.0 but can be safely set to 1.1. 2. illumos-gate is patched to accept library/security/openssl-11 as dependency so that it builds when the mediator version is 1.1. 3. oi-userland has now a switch USE_OPENSSL10=yes or USE_OPENSSL11=yes which should be placed before shared-macros.mk is included. 4. If 'gmake update' is executed in a component depending on OpenSSL then the switch is made to OpenSSL 1.1 unless USE_OPENSSL10=yes is set. Now the fun begins: 3. Move all the components supporting OpenSSL 1.1 or update them. > 4. Deprecate possible rotting components which cannot be updated and may > cause security issues. > and... the more, the merrier! Cheers ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] OpenSSL update process
Hi, two (belated) PRs are queued to amend OpenSSL 1.0 and add OpenSSL 1.1 to our repository: https://github.com/OpenIndiana/oi-userland/pull/6471 https://github.com/OpenIndiana/oi-userland/pull/6472 Both implementations live in their own prefix with mediated links in /lib and /usr/lib; pkg-config files are also mediated. The recipe is adapted from the solaris-userland efforts, thanks to them. Tasks at hand: 1. Fix 3 small illumos-gate nits due to cypher deprecation. 2. Add macros to ease the switch between OpenSSL 1.0/1.1 3. Move all the components supporting OpenSSL 1.1 or update them. 4. Deprecate possible rotting components which cannot be updated and may cause security issues. A PR will contain 2 + 3 and we'll try to use the simple build_plan scheme to publish on the build server in one go. Priority is on the cryptographic Python modules used by pkg5 and security + server side software. When we feel confident that all is rebuilt and well we set OpenSSL 1.1 as the default mediator version. Any ideas on the details? 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] PostgreSQL 9.5 deprecation notice
Hi, during the migration to newer Python and the OpenSSL update, a few components delivered as 32-bit binaries will either be moved to 64-bit or phased out. According to https://www.postgresql.org/support/versioning/, PostgreSQL 9.5 the last 32/64-bit postgres we deliver, is EOL'ed on 11th February 2021. Therefore you are encouraged to migrate to a newer version as version 9.5 will be deprecated in our repository shortly after its official EOL. Note that PostgreSQL 9.6 will be phased out at the end of November 2021 as well. 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] Python modules update status
Hi, we are moving forward well with the migration. Out of 172 components: 1) 46 got Python 3.7 and 3.9 support (in bold pending for merge): argcomplete 2.7 3.5 3.7 3.9 atomicwrites 2.7 3.5 3.7 3.9 attrs 2.7 3.5 3.7 3.9 *automat* 3.5 3.7 3.9 chardet 2.7 3.5 3.7 3.9 *cheroot* 3.5 3.7 3.9 *cherrypy* 3.5 3.7 3.9 *constantly* 3.7 3.9 coverage 2.7 3.5 3.7 3.9 *hamcrest* 3.5 3.7 3.9 *hyperlink* 2.7 3.5 3.7 3.9 idna 2.7 3.5 3.7 3.9 importlib-metadata 2.7 3.5 3.7 3.9 incremental 2.7 3.5 3.7 3.9 iniconfig 3.5 3.7 3.9 mock 2.7 3.5 3.7 3.9 more-itertools 3.5 3.7 3.9 *nose* 3.5 3.7 3.9 packaging 2.7 3.5 3.7 3.9 *pexpect* 3.5 3.7 3.9 pip 2.7 3.5 3.7 3.9 pipdeptree 3.5 3.7 3.9 pluggy 2.7 3.5 3.7 3.9 *ptyprocess* 3.5 3.7 3.9 py 2.7 3.5 3.7 3.9 py-cpuinfo 3.5 3.7 3.9 pycodestyle 2.7 3.5 3.7 3.9 pylxml 2.7 3.5 3.7 3.9 pyparsing 3.5 3.7 3.9 pytest 3.5 3.7 3.9 pytest-benchmark 3.5 3.7 3.9 pytest-reporter 3.5 3.7 3.9 python-rapidjson 3.7 3.9 pytz 2.7 3.5 3.7 3.9 requests 2.7 3.5 3.7 3.9 setuptools 3.5 3.7 3.9 setuptools_scm 2.7 3.5 3.7 3.9 six 2.7 3.5 3.7 3.9 sortedcontainers 2.7 3.5 3.7 3.9 toml 3.5 3.7 3.9 twisted 3.5 3.7 3.9 urllib3 2.7 3.5 3.7 3.9 wcwidth 2.7 3.5 3.7 3.9 zc.lockfile 2.7 3.5 3.7 3.9 zipp 2.7 3.5 3.7 3.9 zope-interface 2.7 3.5 3.7 3.9 2) 46 are Python 2.7 only and some of them may simply be deprecated. Thanks to Andreas, Nona, and Gary for their help. Kind regards, Aurélien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Tasks to focus on
On Tue, Feb 2, 2021 at 4:23 PM Nona Hansel wrote: > > -- Původní e-mail -- > Od: Aurélien Larcher > Komu: OpenIndiana Developer mailing list > Datum: 2. 2. 2021 0:58:32 > Předmět: Re: [oi-dev] Tasks to focus on > > > > On Thu, Jan 28, 2021 at 3:55 AM Gary Mills wrote: > > On Wed, Jan 27, 2021 at 03:14:14PM +0100, Aurélien Larcher wrote: > > > >My list is pretty much the same except that Python 3.9 is now packaged > >together with some modules (including pip and pipdeptree for > >convenience) and that we will skip 3.8. > >Also we are going to jump to pkg supporting 3.9 as Andy did recently. > >In the top priorities: > >- Moving packages to use Python 3.7 instead of 2.7 or 3.5. > >- Adding python modules for 3.7 and 3.9. > >- Updating Clang. > > > >One urgent task is to move away from Python 2.7 and 3.5. > >For example all these dependencies need to be addressed: the more > hands > >the better. > >alarcher@narval:/export/home/alarcher$ pkg search -H -r -o [2] > pkg.name > >'depend:require:runtime/python-27' | sed -e '/library\/python/d' | > sort > >-u > >application/cluster/cluster-glue > > I decided on Python upgrades, starting with the cluster-glue package. > I'd like to determine if newer versions are available, since they may > use newer Python versions. However, I couldn't find any mention of > Python except for this line in Makefile: > > REQUIRED_PACKAGES += runtime/python-27 > > > The list of packages I provided does not contain Python modules per se but > software relying on Python 2.7. > This could be e.g. because of providing Python bindings. > > On the other hand you can find in the directory > > > https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/python > > all the python modules provided in oi-userland. > > It may be more pleasant to update these components to support Python 3.7 > and 3.9 beforehand. > As you see fit. > > > Hi, > > do I get it right that the task now is to "just" add Python 3.7 and 3. 9. > to the python modules or is it to deprecate Python 2.7. plus add Python 3.7 > and 3. 9? > Hello :) Just add Python 3.7 and 3.9 versions for now, because we still have a few components depending on Python 2.7 modules (these should be migrated as well in the meantime). We can remove Python 2.7 modules at once when we are ready i.e. no component in oi-userland depends either on Python 2.7 or a Python 2.7 module. Thank you Nona and Gary for your continued contributions to the project :) Kind regards, Aurélien > Thank you! > > > > > > > I decided I needed to install python39 on my development system first, > using python37 as a model. I do have a few questions. Is it version > 3.9.1 that you are using? What did you do with the tkinter manifest? > What configure options did you use? I suppose most of the answers are > in your Makefile . > > >This is a long list of packages that should be either patched to use > >3.7, updated to a recent version supporting 3.X or simply removed if > >they are obsolete. > >Of course due to dependency hell we may need to update some of the > >python packages in the meantime to provide >= 3.7 versions. > >So far ~25% of the Python modules have been upgraded (within a week, > so > >the task is not as humongous as one would think). > > I'm sure I'll discover most of those things as I go along. > > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, > Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] CVE-2021-3156 seems relevant for OI
On Thu, Jan 28, 2021 at 12:19 PM Till Wegmueller wrote: > Yeah > > People still don't inform us or the BSD's / Apple properly for these > sorts of things, but we can scramble to address small patches like this > very fast it turns out. Thankfully now a couple of people in the BSD's > now ping us in tweets when this happens so we get the news very fast, > although still post embargo and not pre. > And following Alan's notification you may want to update the sudo package on your systems again: https://github.com/OpenIndiana/oi-userland/pull/6468 The new package has been published already. > > > -Till > > On 28.01.21 04:36, Tony Brian Albers wrote: > > On 01/28/21 07:14 AM, Tim Mooney via oi-dev wrote: > >> In regard to: [oi-dev] CVE-2021-3156 seems relevant for OI, Tony > Brian...: > >> > >>> We might want to get sudo patched really, really quickly. > >> > >> Rich Lowe had a PR for it last night, just a few hours after the > >> embargo lifted: > >> > >> https://github.com/OpenIndiana/oi-userland/pull/6456 > >> > >> Tim > > > > Cool, that's what I call fast :) > > > > /tony > > > > > > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] texlive package
On Fri, Jan 29, 2021 at 1:07 PM s...@pandora.be wrote: > > One of the possible ways to install latex is : > > pkg install texlive (to get the meta-packages/texlive package) > > Then run > > install-tl --profile latex.profile > > where latex.profile is the profile for LaTeX. > > This has the nice feature that it is possible to make "symbolic links" > from the /usr/texlive/2020 directory to /usr/bin. > So that you get the /usr/bin/tex, /usr/bin/latex etc. > > Another way could be to use: > > pkg install latex > > which is built on the build server by the texlive framework; > > The build server can run the TeX installer on the prototype area (as build > user). > > There still is a pkgmogrify error but the manifest could be more or less > OK: > > components/text/latex/Makefile > components/text/latex/latex.p5m > components/text/latex/latex.profile > components/text/latex/manifests/sample-manifest.p5m > components/text/latex/texlive.profile > make-rules/texlive.mk > > where in the latex directory the texlive.profile is used for the > install-tl. > > This way it only downloads the required components, in order to get a > small latex package. > Hi David, let me know if you need help with testing. Also I added you as a reviewer to the project, you should be able to edit the "TeX Project" page. Kind regards, Aurélien > David Stes > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Tasks to focus on
On Thu, Jan 28, 2021 at 3:55 AM Gary Mills wrote: > On Wed, Jan 27, 2021 at 03:14:14PM +0100, Aurélien Larcher wrote: > > > >My list is pretty much the same except that Python 3.9 is now packaged > >together with some modules (including pip and pipdeptree for > >convenience) and that we will skip 3.8. > >Also we are going to jump to pkg supporting 3.9 as Andy did recently. > >In the top priorities: > >- Moving packages to use Python 3.7 instead of 2.7 or 3.5. > >- Adding python modules for 3.7 and 3.9. > >- Updating Clang. > > > >One urgent task is to move away from Python 2.7 and 3.5. > >For example all these dependencies need to be addressed: the more > hands > >the better. > >alarcher@narval:/export/home/alarcher$ pkg search -H -r -o [2] > pkg.name > >'depend:require:runtime/python-27' | sed -e '/library\/python/d' | > sort > >-u > >application/cluster/cluster-glue > > I decided on Python upgrades, starting with the cluster-glue package. > I'd like to determine if newer versions are available, since they may > use newer Python versions. However, I couldn't find any mention of > Python except for this line in Makefile: > > REQUIRED_PACKAGES += runtime/python-27 > The list of packages I provided does not contain Python modules per se but software relying on Python 2.7. This could be e.g. because of providing Python bindings. On the other hand you can find in the directory https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/python all the python modules provided in oi-userland. It may be more pleasant to update these components to support Python 3.7 and 3.9 beforehand. As you see fit. > > I decided I needed to install python39 on my development system first, > using python37 as a model. I do have a few questions. Is it version > 3.9.1 that you are using? What did you do with the tkinter manifest? > What configure options did you use? I suppose most of the answers are > in your Makefile . > > >This is a long list of packages that should be either patched to use > >3.7, updated to a recent version supporting 3.X or simply removed if > >they are obsolete. > >Of course due to dependency hell we may need to update some of the > >python packages in the meantime to provide >= 3.7 versions. > >So far ~25% of the Python modules have been upgraded (within a week, > so > >the task is not as humongous as one would think). > > I'm sure I'll discover most of those things as I go along. > > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, > Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Helper tool for Python modules update
On Mon, Feb 1, 2021 at 11:42 PM Gary Mills wrote: > On Mon, Feb 01, 2021 at 09:50:29PM +0100, Aurélien Larcher wrote: > > > >Are you working on packaging python-39 for SPARC? > > No, for x86. As I mentioned last week, I was looking at cluster-glue, > the first python package in your list. I couldn't see anything in > that package that required python-27, but before I went further I > thought I'd better install python-39 on my development system. I > expect you missed that message. My source clone, from late September, > did not have a directory python39, so I assumed I'd have to build my > own. > I am very sorry, with the recent stream of messages I definitely missed this... > > >I have pushed python-39 to the OI repository early January, the > patches > >are at: > >[3] > https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/component > >s/python/python39 > >based on solaris-userland patches and upstream post-3.9.1, if it can > >help. > >Also the package is > >[4]runtime/python-39@3.9.1,5.11-2020.0.1.0:20210108T232023Z > > I didn't know about any of that. I'll discard my work and use the > packaged version instead. > Sorry again about the time you spent on the patches :( > > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, > Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Helper tool for Python modules update
On Mon, Feb 1, 2021 at 9:44 PM Aurélien Larcher wrote: > > > On Mon, Feb 1, 2021 at 9:34 PM Gary Mills wrote: > >> On Mon, Feb 01, 2021 at 06:05:27PM +0100, Aurélien Larcher wrote: >> >I tested a little something even if it is still very rudimentary... >> and >> >given that I am not a Python developer the code is probably quite >> ugly. >> >With the last few commits to oi-userland you can use: >> >$ gmake update-latest >> >in Python components to modify the Makefile to the latest known >> version >> >in PyPI. >> >> I'm still working on python39 itself, not the python scripts. I >> assume it's not available in the OI repository yet. My current >> obstacle is all the patches used for python37 . Many of them have to >> be rewritten to suit python39 . It's a slow process. >> > > Are you working on packaging python-39 for SPARC? > > I have pushed python-39 to the OI repository early January, the patches > are at: > > > https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/python/python39 > > based on solaris-userland patches and upstream post-3.9.1, if it can help. > Also the package is runtime/python-39@3.9.1,5.11-2020.0.1.0:20210108T232023Z <http://pkg.openindiana.org/hipster/info/0/runtime%2Fpython-39%403.9.1%2C5.11-2020.0.1.0%3A20210108T232023Z> > > Kind regards, > > Aurélien > > > >> >> >> -- >> -Gary Mills--refurb--Winnipeg, Manitoba, >> Canada- >> >> ___ >> oi-dev mailing list >> oi-dev@openindiana.org >> https://openindiana.org/mailman/listinfo/oi-dev >> > > > -- > --- > Praise the Caffeine embeddings > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Helper tool for Python modules update
On Mon, Feb 1, 2021 at 9:34 PM Gary Mills wrote: > On Mon, Feb 01, 2021 at 06:05:27PM +0100, Aurélien Larcher wrote: > >I tested a little something even if it is still very rudimentary... > and > >given that I am not a Python developer the code is probably quite > ugly. > >With the last few commits to oi-userland you can use: > >$ gmake update-latest > >in Python components to modify the Makefile to the latest known > version > >in PyPI. > > I'm still working on python39 itself, not the python scripts. I > assume it's not available in the OI repository yet. My current > obstacle is all the patches used for python37 . Many of them have to > be rewritten to suit python39 . It's a slow process. > Are you working on packaging python-39 for SPARC? I have pushed python-39 to the OI repository early January, the patches are at: https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/python/python39 based on solaris-userland patches and upstream post-3.9.1, if it can help. Kind regards, Aurélien > > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, > Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Helper tool for Python modules update
On Mon, Feb 1, 2021 at 6:05 PM Aurélien Larcher wrote: > Hi, > I tested a little something even if it is still very rudimentary... and > given that I am not a Python developer the code is probably quite ugly. > > With the last few commits to oi-userland you can use: > > $ gmake update-latest > > in Python components to modify the Makefile to the latest known version in > PyPI. > > The rest of the procedure remains fairly manual so far... > > Some notes specific to Python components: > 1) If the COMPONENT_ARCHIVE_URL is set to $(call pypi_url) you can remove > it. > Actually probably not for now... should make it more streamlined. > 2) The COMPONENT_PYPI macro is default set to COMPONENT_NAME but you may > need to define it if there is a discrepancy. > 3) If the component uses PyPI then the checksum will be automatically > updated to the one stored in the JSON metadata. > 4) This is all very basic, in particular you need to check if the latest > version supports all Python versions or only Python >= 3.x, and if needed > split the component into 2.x and 3.x. > > Next step will be to use the 'require_dist' metadata to generate > dependencies. > > We are just a few maintainers so as Till said, let us try to be smart... > > Kind regards, > > Aurélien > > -- > --- > Praise the Caffeine embeddings > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Helper tool for Python modules update
Hi, I tested a little something even if it is still very rudimentary... and given that I am not a Python developer the code is probably quite ugly. With the last few commits to oi-userland you can use: $ gmake update-latest in Python components to modify the Makefile to the latest known version in PyPI. The rest of the procedure remains fairly manual so far... Some notes specific to Python components: 1) If the COMPONENT_ARCHIVE_URL is set to $(call pypi_url) you can remove it. 2) The COMPONENT_PYPI macro is default set to COMPONENT_NAME but you may need to define it if there is a discrepancy. 3) If the component uses PyPI then the checksum will be automatically updated to the one stored in the JSON metadata. 4) This is all very basic, in particular you need to check if the latest version supports all Python versions or only Python >= 3.x, and if needed split the component into 2.x and 3.x. Next step will be to use the 'require_dist' metadata to generate dependencies. We are just a few maintainers so as Till said, let us try to be smart... Kind regards, Aurélien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Tasks to focus on
On Sun, Jan 24, 2021 at 5:35 PM Volker A. Brandt wrote: > Hi Gary! > > > > On Sat, Jan 23, 2021 at 02:35:01PM -0700, Nelson H. F. Beebe wrote: > > > > > > I'm part of the TeX Live team that every (northern) winter produces a > > > new release; many O/S distributions then take up that release and > > > repackage it according to their preferences. > > > > That's probably what Openindiana would do too. All software products > > installed on OI systems are installed from IPS packages, the same as > > on Solaris. The packages are built from source. Binaries are of no > > use for OI packages. > > > > First, though, there has to be demand for the software product. I, > > myself, have no interest in Tex. In fact, I don't even know what Tex > > is, except that it's used by mathematicians. I'm not one of those. I > > have some doubts about the demand. > > I use it every day. :-) TBH it's a self-built version on Solaris 11.3. > > > [...] > > > However, at Utah, I make a point of doing test builds for many more, > > > and I can report that this year, with newer compilers on Oracle > > > Solaris 11.4, there were few problems in building a complete TeX Live > > > 2021 set of binaries. > > > > > > The current status report is here: > > > > > > http://www.math.utah.edu/pub/texlive-utah/ > > > > I've read this quickly, and already see obstacles. OI packages have > > some restrictions that may not arise when the software is installed > > directly. > > TeX (in the form of TeXlive 2020) is available as an IPS package from > the OmniOS "extra" repository, so packaging is no problem. > Packaging TeXLive needs some scripting to split tex packages by groups, otherwise you get a >= 1.5GB blob to install at once. I think the Debian Sciences team had developed such scripts to maintain their packages. I did package TexLive ~2015 in oi-userland but this was a lot of work to maintain ctan packages individually so it was never integrated. I ended up using the prepackaged TexLive suite for this reason. Being an applied mathematician/numerician and therefore avid user of TeX I would be very happy if TexLive were to be added to oi-userland. > > > Regards -- Volker > -- > > Volker A. BrandtConsulting and Support for Solaris-based Systems > Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ > Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de > Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 > Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt > > "When logic and proportion have fallen sloppy dead" > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Tasks to focus on
On Fri, Jan 22, 2021 at 5:39 PM Gary Mills wrote: > On Thu, Jan 07, 2021 at 10:39:12PM +0100, Aurélien Larcher wrote: > >Back in March I was working on: > >- building oi-userland with GCC-10 (everything was built except ~10 > >packages). > >- providing Python 3.8 and 3.9. > >- migrating pkg5 to Python 3.7. > >- updating Boost. > >- updating Clang. > >- updating Rust. > >- updating libdrm to 2.4.100. > >- bringing automated rebuild of oi-userland packages and dependencies > >in order. > >However priorities should be set as I cannot dedicate too much time... > >- What do you think should be prioritized? > >- Is anybody interested in picking up one of the tasks? I can assist > >and provide some guidance. > > Is your list still the same, or have some tasks been completed? > Hi Gary, sorry for the late reply, I have been quite busy with research and PhD students... My list is pretty much the same except that Python 3.9 is now packaged together with some modules (including pip and pipdeptree for convenience) and that we will skip 3.8. Also we are going to jump to pkg supporting 3.9 as Andy did recently. In the top priorities: - Moving packages to use Python 3.7 instead of 2.7 or 3.5. - Adding python modules for 3.7 and 3.9. - Updating Clang. > I'd like to take on something, but those tasks are mostly outside of > my area of expertise. On the other hand, I know how to build OI > packages and how to create PRs. What do you suggest. > One urgent task is to move away from Python 2.7 and 3.5. For example all these dependencies need to be addressed: the more hands the better. alarcher@narval:/export/home/alarcher$ pkg search -H -r -o pkg.name 'depend:require:runtime/python-27' | sed -e '/library\/python/d' | sort -u application/cluster/cluster-glue application/cluster/pcs backup/bacula/bacula-sd backup/rdiff-backup-27 database/couchdb-21 database/postgres-10/contrib database/postgres-10/language-bindings database/postgres-11/contrib database/postgres-11/language-bindings database/postgres-12/contrib database/postgres-12/language-bindings database/postgres-95/language-bindings database/postgres-96/language-bindings desktop/gnumeric desktop/studio/jokosher-27 desktop/window-manager/openbox developer/debug/gdb developer/documentation-tool/gtk-doc developer/dtrace/toolkit developer/gnome/gnome-doc-utils developer/meld developer/parser/antlr-2 developer/python/pylint-27 developer/versioning/git developer/versioning/mercurial-27 diagnostic/nmap-cli diagnostic/nmap-gui editor/geany/plugins image/editor/gimp library/desktop/libpeas/libpeas-pythonloader library/e/efl library/e/expedite library/java/grails library/libevent2 library/math/petsc/mpich/gcc library/math/petsc/openmpi/gcc mail/claws-mail mail/fetchmail metapackages/build-essential runtime/python-27/tests system/desktop/ldtp-27 system/management/ansible system/management/salt-27 system/test/fio terminal/terminator-27 web/editor/bluefish web/server/apache-24/module/apache-wsgi-27 This is a long list of packages that should be either patched to use 3.7, updated to a recent version supporting 3.X or simply removed if they are obsolete. Of course due to dependency hell we may need to update some of the python packages in the meantime to provide >= 3.7 versions. So far ~25% of the Python modules have been upgraded (within a week, so the task is not as humongous as one would think). > I know C and perl, but not Python. My background is Solaris, mostly > command-line, not GUI. I'm slow but steady. > Packaging Python stuff is fairly easy but if you feel more confident with compilers then providing a newer Clang >= 10 is an important task. Do no hesitate to post to ask for more details. However expect some latency on my side in the coming week (workload). Kind regards, Aurélien > > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, > Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Python 3.7 and 3.9
> > 1) Migrate away from 3.5 to 3.7 as the default Python implementation. > First steps of the week, the following modules were updated and support for Python 3.7 and 3.9 was added: argcomplete atomicwrites attrs chardet coverage funcsigs hypothesis idna importlib-metadata incremental ipaddress mock more-itertools packaging pathlib2 pluggy ptyprocess py pycodestyle pytest rapidjson requests scandir setuptools setuptools_scm six sortedcontainers urllib3 zipp zope.interface Updated to use Python 3.9: ninja meson Deprecation: pytest-27 -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Plan for openssl update
On Thu, Jan 14, 2021 at 10:02 PM Chris wrote: > On 2021-01-14 12:33, Aurélien Larcher wrote: > > Hello, > > I have just run the tool for creating a build plan for openssl. > > > > The stages, with each -- denoting a required intermediate update, are: > > > > narval> gmake print-dependents-plan FMRI=library/security/openssl > > library/openssl/openssl-1.0.2 > > -- > > cluster/libesmtp > > database/freetds > > database/mariadb-101 > > database/mariadb-103 > > database/mongodb-34 > > desktop/gftp > > desktop/hexchat > > desktop/pulseaudio > > desktop/synergy > > encumbered/rtmpdump > > library/botan > > library/gnome-vfs > > library/gsoap > > library/ldns > > library/libarchive > > library/libcouchbase > > library/libneon > > library/libp11 > > library/libssh2 > > library/libtorrent > > library/libvncserver > > library/trousers > > library/uwimap > > library/xmlsec > > mail/isync > > mail/mutt > > mail/postfix > > network/bind > > network/irssi > > network/lftp > > network/ntp > > network/openldap > > network/openssh > > network/openvpn > > network/proftpd > > network/rsync > > network/slrn > > network/socat > > network/vpnc > > openindiana/ca-certificates > > perl/net-ssleay > > print/cups > > python/python27 > > python/python35 > > python/python37 > > python/python39 > > ruby/ruby-23 > > ruby/ruby-26 > > runtime/erlang > > shell/mosh > > sysutils/borgbackup > > sysutils/ipmitool > > sysutils/snort > > sysutils/stunnel > > tcl/tcltls > > web/ejabberd > > web/elinks > > web/haproxy > > web/httping > > web/links > > web/lynx > > web/nginx > > web/php/php-7_0-ext-mongodb > > web/php/php-7_3-ext-mongodb > > web/w3m > > web/wget > > x11/mesa > > -- > > database/postgresql-10 > > database/postgresql-11 > > database/postgresql-12 > > database/postgresql-95 > > database/postgresql-96 > > desktop/e/efl > > desktop/freerdp > > encumbered/ffmpeg > > library/lasso > > library/libevent2 > > library/libgit2 > > library/serf > > mail/fetchmail > > mail/sendmail > > network/openconnect > > network/samba > > python/cryptography > > python/m2crypto > > python/pyopenssl > > runtime/squeak4 > > runtime/squeak5 > > runtime/squeak5c > > sysutils/net-snmp > > sysutils/nmap > > web/apache24 > > web/curl > > web/lighttpd > > x11/x11vnc > > -- > > database/couchdb-21 > > database/mongodb-40 > > database/percona-server-56 > > database/percona-server-57 > > database/pgadmin > > database/pgbouncer > > database/postgresql-11-citus > > database/postgresql-12-citus > > desktop/libreoffice > > desktop/remmina > > desktop/transmission > > developer/rust > > encumbered/gst-plugins-bad1 > > library/libetpan > > network/asterisk > > network/pdns-recursor > > network/tor > > python/pycurl > > sysutils/bacula > > sysutils/clamav > > sysutils/nut > > sysutils/virtualbox > > web/apache2-modules/mod_auth_mellon > > web/php/php-7_0 > > web/php/php-7_3 > > -- > > Required installation: [] > > > > However do you see any package that we could happily deprecate in the > > process? ;) > I'm not sure what IO's policy is. But, given python2x went EOL upstream. > You could eliminate python/python27 from the list. Which, given all the > packages that _depend_ on it, would make the list even smaller. ;-) > Indeed :) I wish the theory would apply here :) There are a bunch of packages depending on python-27 and I'd be happy to drop them if I knew nobody uses them :D > > > > Kind regards, > > > > Aurélien > > > --Chris > -- > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Plan for openssl update
Hello, I have just run the tool for creating a build plan for openssl. The stages, with each -- denoting a required intermediate update, are: narval> gmake print-dependents-plan FMRI=library/security/openssl library/openssl/openssl-1.0.2 -- cluster/libesmtp database/freetds database/mariadb-101 database/mariadb-103 database/mongodb-34 desktop/gftp desktop/hexchat desktop/pulseaudio desktop/synergy encumbered/rtmpdump library/botan library/gnome-vfs library/gsoap library/ldns library/libarchive library/libcouchbase library/libneon library/libp11 library/libssh2 library/libtorrent library/libvncserver library/trousers library/uwimap library/xmlsec mail/isync mail/mutt mail/postfix network/bind network/irssi network/lftp network/ntp network/openldap network/openssh network/openvpn network/proftpd network/rsync network/slrn network/socat network/vpnc openindiana/ca-certificates perl/net-ssleay print/cups python/python27 python/python35 python/python37 python/python39 ruby/ruby-23 ruby/ruby-26 runtime/erlang shell/mosh sysutils/borgbackup sysutils/ipmitool sysutils/snort sysutils/stunnel tcl/tcltls web/ejabberd web/elinks web/haproxy web/httping web/links web/lynx web/nginx web/php/php-7_0-ext-mongodb web/php/php-7_3-ext-mongodb web/w3m web/wget x11/mesa -- database/postgresql-10 database/postgresql-11 database/postgresql-12 database/postgresql-95 database/postgresql-96 desktop/e/efl desktop/freerdp encumbered/ffmpeg library/lasso library/libevent2 library/libgit2 library/serf mail/fetchmail mail/sendmail network/openconnect network/samba python/cryptography python/m2crypto python/pyopenssl runtime/squeak4 runtime/squeak5 runtime/squeak5c sysutils/net-snmp sysutils/nmap web/apache24 web/curl web/lighttpd x11/x11vnc -- database/couchdb-21 database/mongodb-40 database/percona-server-56 database/percona-server-57 database/pgadmin database/pgbouncer database/postgresql-11-citus database/postgresql-12-citus desktop/libreoffice desktop/remmina desktop/transmission developer/rust encumbered/gst-plugins-bad1 library/libetpan network/asterisk network/pdns-recursor network/tor python/pycurl sysutils/bacula sysutils/clamav sysutils/nut sysutils/virtualbox web/apache2-modules/mod_auth_mellon web/php/php-7_0 web/php/php-7_3 -- Required installation: [] However do you see any package that we could happily deprecate in the process? ;) Kind regards, Aurélien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] userland-mangler behaviour can lead to broken packages
Hi, can I have your opinion on: https://github.com/OpenIndiana/oi-userland/pull/6420 It seems that userland-mangler only copies libraries if the destination does not exist in prototype/mangled. However since our build server does not clean up systematically the workspace, it happened that broken packages where published mixing incompatible libraries if this latter do not reflect versioning/abi breakage in the filename. Latest instance was libqsqlite.so from Qt where version 5.9 was published to Qt 5.12 although the new version had been built and installed in the proto area. Kind regards, Aurélien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Shipping the nano editor alongside with vi
On Mon, Jan 11, 2021 at 5:32 PM Hung Nguyen Gia via oi-dev < oi-dev@openindiana.org> wrote: > Sorry. I had a really bad day. I hope I could call back some of my mails. > But it's impossible anyway. > This is fine, no problem. Take care Aurélien > > > On Mon, 11 Jan 2021 16:15:08 +0700 Michael Schuster < > michaelspriv...@gmail.com> wrote > > > Hi Hung, > > > > On Mon, Jan 11, 2021 at 8:39 AM Hung Nguyen Gia via oi-dev < > oi-dev@openindiana.org> wrote: > > Maybe... I'm impolite. But what if I'm just visit here once for this > purpose then? > > > > I only care about the result. Maybe I'm posted on the wrong mailing > list. Maybe OI-discuss more fit? > > > > The only thing I want to see and to care is: the next version of OI, > nano is included alongside of vi in the text and minimal version. > > > > It's just simple as that. Why make thing complicated? > > > > Or this whole DIY stuffs here is just a polite way to say: we don't > care about your concern and it you could send we a pull request we may > 'optionally' consider it? > > > > Then just said: 'Fuck off! We don't care!'. Straight forward so I > could know to silently go away. This will not waste our time with a bunch > of back and forth emails. > > > > you don't seem to realise or appreciate the fact that this is a project > that is (almost?) exclusively driven by volunteers. As such, these > volunteers decide what gets done. > > In such an environment, the best way to get things the way you want > them done is doing them yourself (not because people don't care, but > because their priorities aren't necessarily yours ... and because they're > probably quite busy doing stuff) - as you've found out, this requires > effort on your part. The second best option is asking, nicely, and offering > your help on the way and supplying as much information as possible (eg, > error messages, compiler output ... ). > > > > Using language like "I want", "morons", "weird" will not put you or > your issue at the front of anyone's favourite list. > > > > I don't see people telling you to go away - rather, they're (quite > politely, in my POV) telling you to follow what used to be called > "netiquette". > > > > regards > > Michael > > > > > > On Sun, 10 Jan 2021 14:19:14 +0700 Tim Mooney via oi-dev < > oi-dev@openindiana.org> wrote > > > > > In regard to: Re: [oi-dev] Shipping the nano editor alongside with > vi, Hung...: > > > > > > > Yes, it's just a single line. But why you give me a read-only > file and > > > > asked me to modified it? > > > > > > > > It's much more simpler for developer with write access to do it, > not me. > > > > And it's within a second, just a single line. > > > > > > I don't know if other languages and cultures have an equivalent, > but there > > > is a proverb[1] that applies here: > > > > > > If you give a man a fish, you feed him for a day. > > > If you teach a man to fish, you feed him for a lifetime. > > > > > > Teaching someone (or helping them learn) how to do something is > often > > > more useful than just doing something (once) for them. > > > > > > Aurélien is trying to help you to learn to fish. > > > > > > Learning how to clone oi-userland, create a branch, make a very > simple > > > change like this, and submit a pull request (PR) is very useful > knowledge > > > to have for anyone that wants to contribute to OI. There are > certainly > > > other ways to contribute, but since you're posting to the oi-dev > list, > > > it seems like you might be interested in the development process. > Knowing > > > the workflow for submitting a change is potentially beneficial to > you. > > > > > > Yes, he could do it in just a couple minutes. But then you've > missed an > > > opportunity to learn something that might allow you to contribute > to OI. > > > > > > [1] the origin of this proverb appears to be quite contested, but > it > > > seems like it might be Lao-Tzu. > > > > > > Tim > > > > > > > On Sun, 10 Jan 2021 00:49:50 +0700 Aurélien Larcher < > aurel
Re: [oi-dev] Missing locale zh_CN.GB18030
On Mon, Jan 11, 2021 at 4:37 PM Toomas Soome via oi-dev < oi-dev@openindiana.org> wrote: > > > On 11. Jan 2021, at 16:47, Nona Hansel wrote: > > Hi, > > I'm trying to update findutils. Some test are skipping because I don't > have zh_CN.GB18030 locale on my system. How can I get it? > pfexec pkg info -r doesn't work for me in this case. > Thank you in advance. > Nona > > > I think, we only do have zh_CN.UTF-8 (pkg contents zh_cn). > It seems we have it: narval> pkg search -r zh_CN.GB18030 INDEX ACTION VALUEPACKAGE basename dirusr/lib/locale/zh_CN.GB18030 pkg:/locale/zh_cn-extra@0.5.11-2020.0.1.20221 > > rgds, > toomas > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Tasks to focus on
On Sat, Jan 9, 2021 at 5:18 PM Hung Nguyen Gia wrote: > I hope you are happily to read me, too. You should remember me when we > encountered on illumos.org/issues page. > > If you want to know, my vote is: Building with GCC-10 and Updating Clang. > > Compiler tool chain is one of the weakness of OI. If you could get the > latest stable compiler working and able to building with it, it's a very > good news. > Hi, I agree that compilers should be a priority :) Usually the rule is that we do not migrate until 100% of userland builds with the new compiler. Last summer I was missing only a handful of packages (a dozen left) to do the migration to gcc-10 but then health issues got me out of the game for a few months. Hopefully with more help we can have this migration done by the next snapshot. Kind regards Aurélien > > ---- On Sat, 09 Jan 2021 20:09:40 +0700 Aurélien Larcher < > aurelien.larc...@gmail.com> wrote > > > > > > > > > Glad you are doing better. > > > > Hi Alan, > > thank you or kind message, happy to read you :) > > > > I have been a "long hauler", took 9 months to get back to (almost) > normal. > > > > > > For whatever it's worth, we've pushed our changes for some of these to > our > > github repos (though you obviously have many packages in your userland > that > > we don't, so these may not be enough to cover all of what you need). > > > > > - building oi-userland with GCC-10 (everything was built except ~10 > packages). > > > > > https://github.com/oracle/solaris-userland/search?q=gcc+10&type=commits > > > > > - providing Python 3.8 and 3.9. > > > > > https://github.com/oracle/solaris-userland/search?q=python+3.9&type=commits > > > > > - migrating pkg5 to Python 3.7. > > > > > https://github.com/oracle/solaris-ips/search?q=%22python+3.7%22&type=commits > > plus some other followup fixes you can see in the full repo history, > like > > > https://github.com/oracle/solaris-ips/commit/161a7e1e1a1683b8d72c491a853d6fb432456231 > > > > > - updating Clang. > > > > > https://github.com/oracle/solaris-userland/commits/master/components/llvm > > > > > - updating Rust. > > > > > https://github.com/oracle/solaris-userland/commits/master/components/rust > > > > > - updating libdrm to 2.4.100. > > > > > https://github.com/oracle/solaris-userland/commit/0f426b4368936ec548ef9bb89d7d27dc7d4bec5e > > Thanks again for providing guidance :) > > > > I have looked at the patchsets and I have now pushed Python 3.9.1 for > starters (I have added a few post-3.9.1 patchsets that were interesting). > > > > A big thank you to the solaris-userland team :) > > > > Kind regards, > > > > Aurelien > > > > > > > > > > > > > > -alan- > > > > > > -- > > --- > > Praise the Caffeine embeddings > > ___ > > oi-dev mailing list > > oi-dev@openindiana.org > > 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
Re: [oi-dev] Shipping the nano editor alongside with vi
On Sat, Jan 9, 2021 at 9:09 AM Hung Nguyen Gia via oi-dev < oi-dev@openindiana.org> wrote: > This should be done for none desktop OI flavors: OI text and OI minimal. > > It will help novice user like me very much. Please consider it, > developers. I have trouble using the vi editor even though I have my mobile > phone with me as a backup showing the vi tutorial. And I think many other > novice users have the same trouble as me. > > Doing as Fedora is a step too far: > https://www.phoronix.com/scan.php?page=news_item&px=Fedora-33-Nano-Is-The-Default > > I only asked for shipping nano alongside with vi. The link I put above > just to note that nano has pretty much become the default editor on the > Linux world and most of us come from Linux. It will be easier for us. > Thanks. > Hello, basically one could add the nano package to: https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/meta-packages/install-types/includes/minimal Kind regards, Aurélien > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Tasks to focus on
> Glad you are doing better. > Hi Alan, thank you or kind message, happy to read you :) I have been a "long hauler", took 9 months to get back to (almost) normal. > For whatever it's worth, we've pushed our changes for some of these to our > github repos (though you obviously have many packages in your userland that > we don't, so these may not be enough to cover all of what you need). > > > - building oi-userland with GCC-10 (everything was built except ~10 > packages). > > https://github.com/oracle/solaris-userland/search?q=gcc+10&type=commits > > > - providing Python 3.8 and 3.9. > > https://github.com/oracle/solaris-userland/search?q=python+3.9&type=commits > > > - migrating pkg5 to Python 3.7. > > > https://github.com/oracle/solaris-ips/search?q=%22python+3.7%22&type=commits > plus some other followup fixes you can see in the full repo history, like > > https://github.com/oracle/solaris-ips/commit/161a7e1e1a1683b8d72c491a853d6fb432456231 > > > - updating Clang. > > https://github.com/oracle/solaris-userland/commits/master/components/llvm > > > - updating Rust. > > https://github.com/oracle/solaris-userland/commits/master/components/rust > > > - updating libdrm to 2.4.100. > > > https://github.com/oracle/solaris-userland/commit/0f426b4368936ec548ef9bb89d7d27dc7d4bec5e Thanks again for providing guidance :) I have looked at the patchsets and I have now pushed Python 3.9.1 for starters (I have added a few post-3.9.1 patchsets that were interesting). A big thank you to the solaris-userland team :) Kind regards, Aurelien > > > > -alan- > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Python 3.7 and 3.9
Hi, just a few notes: 1) Following Apostolos message python-37 was modified to provide IDLE in a separate package: idle-37. After the next update you may need to reinstall it. 2) The library libpython3.so which provides a stable ABI was not provided by python-3X packages, this is now the case for 3.7; the link is mediated. 3) Two fixes (sendfile and sched_get_priority) were backported from 3.8/3.9; 4) Python 3.9.1 was added based on solaris-userland patchset + testsuite fixes from Andy, thanks go to them. No we need to: 1) Migrate away from 3.5 to 3.7 as the default Python implementation. 2) Provide required Python 3.9 modules for pkg5 (cherry-py, rapidjson, six, etc..). 3) Automate/simplify the update process for Python modules to reduce manual intervention. As Till pointed out, we need to be smart about it. 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] Tasks to focus on
Hi, since I have now more or less recovered from Covid I can be active to some extent. Back in March I was working on: - building oi-userland with GCC-10 (everything was built except ~10 packages). - providing Python 3.8 and 3.9. - migrating pkg5 to Python 3.7. - updating Boost. - updating Clang. - updating Rust. - updating libdrm to 2.4.100. - bringing automated rebuild of oi-userland packages and dependencies in order. However priorities should be set as I cannot dedicate too much time... - What do you think should be prioritized? - Is anybody interested in picking up one of the tasks? I can assist and provide some guidance. Kind regards, Aurelien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkg -- huge RSS
Also our pkg repository needs some belated spring cleaning... On Tue, Jun 9, 2020 at 12:39 AM Till Wegmüller wrote: > Hi Gordon > > Unfortunately yes. We included a patch on the 7th of March which should > make things a little bit better. There is still work needing to be done > though. We are approaching this from a few angles but it's going to take > time to replace components with more efficient ones. And find the things > which are causing this exactly If you want to see some detailed > benchmarks how we did it for the Update in march you can find them in > the PR here [0]. If I know which specific thing is eating RSS I can work > on replacing that with a bit of Rust code. That works well together with > python and I know some people which can help make it work. > > If you are interested in helping, I can add documentation to my quite > extensive experiments with the IPS formats. I have a almost working repo > server (only search is missing) and pkgrepo in Go [1]. And I am working > on getting it ported to Rust [2]. > > Greetings > Till > > [0] https://github.com/OpenIndiana/pkg5/pull/75 > [1] https://git.wegmueller.it/Illumos/pkg6 > [2] https://github.com/OpenFlowLabs/libips > > On 08.06.20 18:20, Gordon Ross wrote: > > Is this normal? > > > >PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP > > 1289 root 3574M 3489M cpu3600 0:07:10 2.0% pkg/1 > > > > I bumped up the RAM in this VM to 6GB and it's still struggling to > complete... > > > > root@oi-tank:/export/home/gwr# pkg info package/pkg > > Name: package/pkg > > Summary: Image Packaging System > > Description: The Image Packaging System (IPS), or pkg(5), is the > > software delivery system used on OpenIndiana. This > > package contains the core command-line components > and > > pkg.depotd server. > > Category: System/Packaging > >State: Installed > >Publisher: openindiana.org > > Version: 0.5.11 > > Branch: 2019.0.0.5528 > > Packaging Date: September 25, 2019 at 02:40:19 PM > >Last Install Time: November 6, 2019 at 09:26:38 AM > > Size: 14.30 MB > > FMRI: > > pkg://openindiana.org/package/pkg@0.5.11-2019.0.0.5528:20190925T144019Z > > Repository Changeset: a6bfc17b > > Source URL: https://github.com/OpenIndiana/pkg5/ > > > > ___ > > 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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] GCC 10: help with oi-userland fixes
Still 67 components to fix: https://www.illumos.org/issues/12722 On Thu, May 14, 2020 at 3:36 PM Aurélien Larcher wrote: > Hi, > I have updated the ticket at: > > https://www.illumos.org/issues/12722 > > As you can see there is a list of about 120 components left to fix out of > ~1650 components in total: close to 90% of the packages are now republished. > > If you are a consumer of one of these packages and have some interest in > contributing, any help will be very much appreciated :) > I added the build logs in a tarball for reference so you can decide which > component to pick in the list. > > Kind regards, > > Aurelien > > -- > --- > Praise the Caffeine embeddings > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] How to test pdns-recusor?
Hi, this PR is pending because I do not know how to test the update: https://github.com/OpenIndiana/oi-userland/pull/5757 Any ideas? Kind regards, Aurélien Larcher -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] GCC 10: help with oi-userland fixes
Hi, I have updated the ticket at: https://www.illumos.org/issues/12722 As you can see there is a list of about 120 components left to fix out of ~1650 components in total: close to 90% of the packages are now republished. If you are a consumer of one of these packages and have some interest in contributing, any help will be very much appreciated :) I added the build logs in a tarball for reference so you can decide which component to pick in the list. Kind regards, Aurelien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] GCC 10.1 build zone: first pass
The repository at http://pkg.openindiana.org/gcc-next now contains about 1500 components from the gcc-10 build zone, still ~150 to go. On Mon, May 11, 2020 at 10:52 PM Aurélien Larcher < aurelien.larc...@gmail.com> wrote: > > > On Mon, May 11, 2020 at 10:46 PM Tim Mooney wrote: > >> In regard to: [oi-dev] GCC 10.1 build zone: first pass, Aur?lien >> Larcher...: >> >> > Hi, >> > nearly 1500 republished but ~170 failures with gcc-10, including the >> > dependency issue for libssp: > > >> A few things appear in the list twice, looks like there might be something >> preventing 'uniq' from doing its job? >> >> > Probably a bad copy/paste actually... > > > >> > network/putty >> > network/proftpd >> > network/rtorrent >> > network/pdns-recursor >> > network/socat >> > network/tor >> > openindiana/ddu >> > openindiana/illumos-gcc >> > openindiana/kvm >> > openindiana/slim_source >> > perl/DBI-MySQL >> > perl/DBI >> > perl/DBI-PostgreSQL >> > perl/HTML-Parser >> > perl/DBI-SQLite >> > network/putty >> > network/proftpd >> > network/rtorrent >> > network/pdns-recursor >> > network/socat >> > network/tor >> > openindiana/ddu >> > openindiana/illumos-gcc >> > openindiana/kvm >> > openindiana/slim_source >> > perl/DBI-MySQL >> > perl/DBI >> > perl/DBI-PostgreSQL >> > perl/HTML-Parser >> > perl/DBI-SQLite >> >> 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 >> > > > -- > --- > Praise the Caffeine embeddings > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libssp misplaced in g++-X-runtime
On Mon, May 11, 2020 at 1:00 PM Thomas Wagner wrote: > Hi, > > what if as a temorary fix, the g++-X-runtime is getting a new dependency > on corresponding gcc-X-runtime? > Then every older user package requiring g++-X-runtime would get libssp > in package gcc-X-runtime through that dependency. > I tried it but unfortunately it does not seem to make a difference, the dependency already exists but is not followed. Too bad this was a good idea :S Given the rather low number of packages to fix, I'll probably just add GCC_RUNTIME_PKG to make the transition. Thank you! > > Over the time, old user packages all move to gcc-X-runtime > automatically. > > Thomas > > On Mon, May 11, 2020 at 12:03:27PM +0200, Aurélien Larcher wrote: > > Hi, > > while packaging gcc-9 I noticed that libssp had been misplaced in > > g++-X-runtime since gcc-49. > > I checked solaris-userland and moved libssp to gcc-X-runtime for > > consistency. > > Unfortunately this means that we have a bogus dependency on > GXX_RUNTIME_PKG > > in ~80 components, which should be GCC_RUNTIME_PKG. > > For the gcc-10 build zone I need to fix these dependencies: currently > about > > 1000 components republished, 130 failures. > > Putting libssp back in g++-runtime would be convenient but incorrect. > > Any idea? > > > > Kind regards, > > > > Aurélien > > > > -- > > --- > > Praise the Caffeine embeddings > > > ___ > > oi-dev mailing list > > oi-dev@openindiana.org > > 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] GCC 10 migration ticket: build failures
Hi, I have listed broken components and will add information about the cause: https://www.illumos.org/issues/12722 I added the description of 3 common problems and can also upload the logs of all the failures to ease the task. Kind regards, Aurélien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] GCC 10.1 build zone: first pass
On Mon, May 11, 2020 at 10:46 PM Tim Mooney wrote: > In regard to: [oi-dev] GCC 10.1 build zone: first pass, Aur?lien > Larcher...: > > > Hi, > > nearly 1500 republished but ~170 failures with gcc-10, including the > > dependency issue for libssp: > A few things appear in the list twice, looks like there might be something > preventing 'uniq' from doing its job? > > Probably a bad copy/paste actually... > > network/putty > > network/proftpd > > network/rtorrent > > network/pdns-recursor > > network/socat > > network/tor > > openindiana/ddu > > openindiana/illumos-gcc > > openindiana/kvm > > openindiana/slim_source > > perl/DBI-MySQL > > perl/DBI > > perl/DBI-PostgreSQL > > perl/HTML-Parser > > perl/DBI-SQLite > > network/putty > > network/proftpd > > network/rtorrent > > network/pdns-recursor > > network/socat > > network/tor > > openindiana/ddu > > openindiana/illumos-gcc > > openindiana/kvm > > openindiana/slim_source > > perl/DBI-MySQL > > perl/DBI > > perl/DBI-PostgreSQL > > perl/HTML-Parser > > perl/DBI-SQLite > > 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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] GCC 10.1 build zone: first pass
Hi, nearly 1500 republished but ~170 failures with gcc-10, including the dependency issue for libssp: archiver/arj archiver/pixz archiver/p7zip closed/sunstudio12.1 cluster/cluster-glue cluster/resource-agents cluster/pacemaker database/couchdb-21 database/libpqxx database/mariadb-101 database/pgadmin database/pgpool-II database/postgresql-10-citus database/postgresql-11-citus database/postgresql-12-citus desktop/awesome desktop/compiz-plugins-main desktop/e/enlightenment desktop/fbreader desktop/gmtp desktop/e/efl desktop/gnome3/vinagre desktop/hexchat desktop/keepassx desktop/mate/caja desktop/mate/engrampa desktop/libreoffice desktop/mate/mate-applets desktop/mate/mate-utils developer/autogen developer/binutils developer/clang-80 developer/gcc-5 developer/gcc3 developer/gcc49 developer/global developer/golang-111 developer/groovy-24 developer/openjade developer/gcc-9 developer/subversion fonts/jetbrains-mono foomatic/filters games/gnugo image/geeqie image/rrdtool library/botan library/gsoap library/java-jss library/libcouchbase library/libfreehand library/libgcrypt library/libical library/libjpeg-turbo library/libmspub library/libmtp library/libpagemaker library/librvngabw library/libsmbclient library/libsodium library/libstaroffice library/libvisual-plugins library/mpich library/mozilla-nss library/openssl/openssl-1.0.2 library/ptlib library/openmpi library/sane-frontends library/speech-dispatcher library/spidermonkey library/qt4 library/swt library/qt5 library/trousers library/tdb mail/postfix mail/thunderbird multimedia/gst-plugins-good1 network/autossh network/avahi network/dnscrypt-proxy network/irssi network/ncftp network/isc-dhcp network/openssh network/putty network/proftpd network/rtorrent network/pdns-recursor network/socat network/tor openindiana/ddu openindiana/illumos-gcc openindiana/kvm openindiana/slim_source perl/DBI-MySQL perl/DBI perl/DBI-PostgreSQL perl/HTML-Parser perl/DBI-SQLite network/putty network/proftpd network/rtorrent network/pdns-recursor network/socat network/tor openindiana/ddu openindiana/illumos-gcc openindiana/kvm openindiana/slim_source perl/DBI-MySQL perl/DBI perl/DBI-PostgreSQL perl/HTML-Parser perl/DBI-SQLite perl/authen_pam perl/net-ssleay perl/sun_solaris perl/xml-parser perl/perl-522 perl/perl-524 print/cups print/cups-filters print/psutils python/netifaces python/notify-python python/pygobject-3 python/python-rapidjson ruby/augeas runtime/ccl runtime/clisp ruby/ruby-26 ruby/ruby-23 runtime/hercules sysutils/gnupg runtime/openjdk-7 sysutils/htop sysutils/logrotate sysutils/ipmitool sysutils/mtr sysutils/ncdu sysutils/ngrep sysutils/netperf sysutils/open-vm-tools sysutils/rsyslog sysutils/snort sysutils/stunnel sysutils/net-snmp tcl/pgtcl tcl/tcl sysutils/virtualbox tcl/tcl-sqlite tcl/tcltls text/hunspell-de text/the_silver_searcher web/aget web/apache2-modules/mod_perl web/elinks web/goaccess web/icedtea-web web/webalizer web/squid x11/freeglut x11/mrxvt x11/xorg-server x11/x11vnc x11/xf86-video-intel x11/xf86-video-openchrome x11/xsel x11/mesa -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] libssp misplaced in g++-X-runtime
Hi, while packaging gcc-9 I noticed that libssp had been misplaced in g++-X-runtime since gcc-49. I checked solaris-userland and moved libssp to gcc-X-runtime for consistency. Unfortunately this means that we have a bogus dependency on GXX_RUNTIME_PKG in ~80 components, which should be GCC_RUNTIME_PKG. For the gcc-10 build zone I need to fix these dependencies: currently about 1000 components republished, 130 failures. Putting libssp back in g++-runtime would be convenient but incorrect. Any idea? Kind regards, Aurélien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] illumos-gcc (gcc 4.4.4-il)
Sorry for the delay, yes it is because it does not build with recent gcc. I did not have time to fix it and since it worked as it was I left it with gcc-49. On Monday, May 11, 2020, Toomas Soome via oi-dev wrote: > > >> On 11. May 2020, at 10:36, Toomas Soome via oi-dev < oi-dev@openindiana.org> wrote: >> >> Hi! >> >> The current illumos-gcc build is depending on gcc-49, is there some hard requirement for it, or is it just leftover? >> > > ok, this is because 4.4.4 does not build with gcc7. > > rgds, > toomas > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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] OI-Userland migrated to GCC 7.5
Hi everyone, GGC 7.5 is now the default userland compiler; it was already used as default illumos-gate compiler. The repositories (hipster and encumbered) have been rebuilt from scratch and republished. Therefore: - The update number has been incremented, current packages FMRIs should end with 2020.0.1.x, with x the component revision. - Any new pull-request to oi-userland need be built+tested in a gcc-7 environment. Had you updated to the gcc-next repository you may now reenable the hipster repository as preferred: gcc-next builds will now be scheduled with GCC 9.3. Thanks go especially to Alexander for saving the situation with the mispublished libdrm mess today, but also to Andreas, Michal, Till, Jim, Nona, Rouven, and other contributors for their continuing support. Feel free to report any upgrade issue. Kind regards, Aurelien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Userland repository rebuild issue
Hi, it seems that libdrm on the build server was upgraded by mistake to my older gcc-next repository which contained 2.4.99 (leftover files that I should have cleaned by passing options to rsync ). We need to rebuild some X11 components so you should avoid upgrading if you have an Intel adapter. Sorry about this issue... 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] OI gcc-next test images
Uploading right now: http://dlc-int.openindiana.org/users/aurelien/20200323/ Minimal images are already there and Live images being transferred (~20min to go). It seems gpg-agent is broken so I could not sign the images. -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] X11 is now essentially 64-bit
Hi, the following two pull requests: https://github.com/OpenIndiana/oi-userland/pull/5624 https://github.com/OpenIndiana/oi-userland/pull/5627 remove 32-bit Xorg and 32-bit version of most X11 applications. Libraries are still provided both in 32-bit and 64-bit versions. 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] Components to check/fix before 2020.04
Hi, in order to prepare the gcc-7 migration and the 2020.04 snapshot find below a list of components that have failed to build this week on my gcc-7 build hosts: database/mongodb-40 python/netifaces python/imaging python/psutil ruby/augeas runtime/sbcl sysutils/net-snmp sysutils/sysstat also some long standing issues: developer/subversion (wrong gcc used) cluster/pcs (trying to install tilt to system path during build) and a recent problem, probably to a build issue on my host: multimedia/totem I would appreciate if someone could help me look at the faulty components. If I have enough time I may be able to push some updates to drm and the x11 stack before 2020.04 is published. Have a nice continued week-end. Kind regards Aurelien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] GOCACHE for Jenkins jobs
Hi, it seems that MongoDB 3.4 fails to build on Jenkins because Go 1.12 requires a path used for caching files. "build cache is required, but could not be located: GOCACHE is not defined and neither $XDG_CACHE_HOME nor $HOME are defined Error building bsondump" As a workaround I defined a GOCACHE variable in the Jenkins configuration but that is probably not suitable in the long run. Kind regards, Aurelien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Components to fix
Hi, I have built oi-userland with gcc 7.5 for some time now, to the point that most of it can be published besides these components: cluster/pcs editor/emacs library/ptlib runtime/jruby web/icedtea-web I will open a PR for the few fixes I have gathered over the past weeks but any help regarding these last items would be very much appreciated as I lack knowledge and time to investigate them. 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] GCC testsuite results
Hi, every time I have rebased the illumos-gcc patchset to provide a new gcc version on OI I have run the testsuite but have not been able to upload the results. I have re-run the testsuite for each version (5-9) we deliver with both -m64 and -m64 -msave-args, and uploaded tarballs to http://ovh.to/W1tVK9v for reference. Build recipes can be found in the corresponding gcc-* subdirectory in https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/developer Now that we have the IPD I expect to upload future test results against any new -il branch to a dedicated location. Kind regards Aurélien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 64 or 32_and_64 for dependency "leaf" ?
On Tue, Sep 24, 2019 at 10:53 PM Tim Mooney wrote: > > All- > > When rebuilding or updating a component that doesn't have any shared > libraries, so it's effectively a "leaf" on the dependency tree, should > the component be built 64 bit or 32_and_64? > > The component I'm currently looking at is sound-juicer, but the same > question likely applies to any other component that is one or two > executables and support files, with no shared libraries of its own. > > I looked at both the "Building with oi-userland" and the "Existing tasks" > docs on docs.openindiana.org and don't see this discussed. Apologies if > it's documented and I missed it. > Hello, except if there is a real incentive to provide 32-bit executables, e.g if the binary performs code generation defined by the bitness, the current move is to keep 64-bit only. That has been the case for example with Python or the X11 stack. Kind regards, Aurélien > > Tim > -- > Tim Mooney tim.moo...@ndsu.edu > Enterprise Computing & Infrastructure 701-231-1076 (Voice) > Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) > North Dakota State University, Fargo, ND 58105-5164 > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] How to create an ISO correctly?
On Tue, Aug 27, 2019 at 3:16 PM Gary Mills wrote: > On Mon, Aug 26, 2019 at 11:58:42PM +0200, Aurélien Larcher wrote: > > > >If you look at: > >[4] > https://hipster.openindiana.org/distro_const/text_mode_x86-minimal.x > >ml > >pkg_repo_default_authority specifies the repository from which the > >packages are pulled and thus the image created, while > >post_install_repo_default_authority stands for the default publisher > >configured on the ISO itself. > > So, they can be different. That makes it easy for me. > > Is that the same as: > > /usr/share/distro_const/text_install/text_mode_x86_minimal.xml > > which was installed when I installed the distribution-constructor > package? > Probably fairly similar. > > What should be the publisher name? I see that it's openindiana.org in > the /usr/share/distro_const/text*.xml files. > The actual publisher name defined in the pkg repository. By default for a local repository this would be 'userland'. > > >There are packages like this that can be published from metapackage/ > >components. > >For regular Jenkins jobs `gmake -C components incorporation` is called > >after publication of new packages to generate such meta-packages. > > Thanks. I'll look into that procedure. > > >At least on x86 both usb images and cd iso are created by > distro_const. > > I suppose I'll find out the first time I run it. > > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, > Canada- > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] HEADS-UP: 11624 Use of modern nawk(1) requires update of generate-history
As a consequence to the nawk(1) update in illumos-gate, make sure that your oi-userland clone contains the following commit to ensure proper history generation, https://github.com/OpenIndiana/oi-userland/pull/5268 Aurélien -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] How to create an ISO correctly?
On Mon, Aug 26, 2019 at 11:46 PM Gary Mills wrote: > Another progress report and some questions: I have now replaced all > v9os packages with oi-userland packages. There are no v9os packages > left. My T2000 has only oi-userland packages, ones that I have built. > It boots correctly. The publisher name is oi-userland, not the usual > userland or openindiana.org . That difference raises my first > question. > > I've read the information on distribution-constructor: > > http://docs.openindiana.org/dev/distribution-constructor/ > > as well as the man page for distro_const . Neither of them answered > my questions completely. > > Will distro_const change the publisher in the ISO file, both for the > packages and the `pkg publisher' command? How do I do this? > If you look at: https://hipster.openindiana.org/distro_const/text_mode_x86-minimal.xml pkg_repo_default_authority specifies the repository from which the packages are pulled and thus the image created, while post_install_repo_default_authority stands for the default publisher configured on the ISO itself. > > If not, can the publisher be changed on the host system? Does the > publisher in `pkg publisher' have to match the one in the file > repository? > > I see that the XML file used by distro_const specifies `entire' as the > package that includes all the packages to install to the ISO file. > My system has no package `entire'. How do I create and populate it? > Will it include some packages that do not exist? Will this be a > problem? > There are packages like this that can be published from metapackage/ components. For regular Jenkins jobs `gmake -C components incorporation` is called after publication of new packages to generate such meta-packages. > > Finally, how do I create a USB image from the CD image? > At least on x86 both usb images and cd iso are created by distro_const. > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, > Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Something is weird with oi-userland
On Sat, Aug 17, 2019 at 8:21 PM Andreas Wacknitz wrote: > > 1. > ➜ libgweather git:(build) gmake publish > ... > pkg list: no packages matching the following patterns are installed: > /runtime/ruby > Adding required packages to build environment... > > > 2. > ➜ libgweather git:(build) cat Makefile > ... > # Build dependencies > REQUIRED_PACKAGES += developer/vala > > # Auto-generated dependencies > REQUIRED_PACKAGES += library/desktop/gdk-pixbuf > REQUIRED_PACKAGES += library/desktop/geocode-glib > REQUIRED_PACKAGES += library/desktop/gtk3 > REQUIRED_PACKAGES += library/glib2 > REQUIRED_PACKAGES += library/libsoup > REQUIRED_PACKAGES += library/libxml2 > REQUIRED_PACKAGES += system/library > REQUIRED_PACKAGES += system/library/math > > > 3. > ➜ ~ git:(build) pkg mediator > MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION > ... > rubyvendor2.3 vendor > ... > > > 4. > ➜ ~ pkg list|grep ruby > ... > runtime/ruby > 2.6-2018.0.0.0 i-- > runtime/ruby-232.3.7-2018.0.0.0 > i-- > > > > Summary: Our default ruby is 2.3 (see 3.) while the more generic > runtime/ruby is ruby-2.6 (see 4.). > At least one package (libgweather; see 1.) requires runtime/ruby but that > is not listed in its Makefile (see 2.). > Fun fact: "gmake publish" finds a dependency on runtime/ruby while "gmake > REQUIRED_PACKAGES" does not. > https://github.com/OpenIndiana/oi-userland/blob/681a424df01cea4df46a08efa562fa877eba9b04/make-rules/prep-unpack.mk#L65 > > How can this be enhanced? > > Regards, > Andreas > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Pecular dependancies in publishing print/cups-filters
On Wed, Aug 14, 2019 at 4:11 PM Aurélien Larcher wrote: > > > On Wed, Aug 14, 2019 at 3:58 PM Gary Mills wrote: > >> On Wed, Aug 14, 2019 at 10:39:22AM +0200, Till Wegmüller wrote: >> > >> > PKG uses it's own PATH variable to find libraries. Think of -I for GCC >> > for example. And that has been modified to include >> > usr/lib/libjpeg6-ijg/lib already but now also needs usr/gcc/6/lib to be >> > added. >> >> Are you saying that pkg does not use the runtime path from the ELF >> section at all? The runtime linker certainly uses that. >> >> /usr/gcc/6 is the default compiler for the 2018 version of OI that I'm >> using. Surely that element is already in the runtime path that's used >> by pkg. I'd expect that jpeg library path to be the one that's >> absent. >> >> > You can override that by either: >> > - Setting the dependency in the manifest manually and add >> > pkg.depend-bypass to the files that complain or >> > - Modify the Include path PKG searches. I am however unsure which exact >> > knob in oi-userland to tweak here. >> >> Do you have examples from other packages of these two techniques? >> I'd like to start with something that works. >> >> > You should see the override either in the Makefile or the Manifest look >> > for "usr/lib/libjpeg6-ijg/lib" mentioned there. >> >> There's nothing in either for the print/cups-filters package. >> > > Look in the Makefile, it should use image/library/libjpeg8-turbo not > libjpeg6-ijg. > > Probably it is not installed on your system, execute gmake env-prep. > The error tells you that no package in the REQUIRED_PACKAGES list provides a suitable dependency. > > > > >> >> >> -- >> -Gary Mills--refurb--Winnipeg, Manitoba, >> Canada- >> >> ___ >> oi-dev mailing list >> oi-dev@openindiana.org >> https://openindiana.org/mailman/listinfo/oi-dev >> > > > -- > --- > Praise the Caffeine embeddings > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Pecular dependancies in publishing print/cups-filters
On Wed, Aug 14, 2019 at 3:58 PM Gary Mills wrote: > On Wed, Aug 14, 2019 at 10:39:22AM +0200, Till Wegmüller wrote: > > > > PKG uses it's own PATH variable to find libraries. Think of -I for GCC > > for example. And that has been modified to include > > usr/lib/libjpeg6-ijg/lib already but now also needs usr/gcc/6/lib to be > > added. > > Are you saying that pkg does not use the runtime path from the ELF > section at all? The runtime linker certainly uses that. > > /usr/gcc/6 is the default compiler for the 2018 version of OI that I'm > using. Surely that element is already in the runtime path that's used > by pkg. I'd expect that jpeg library path to be the one that's > absent. > > > You can override that by either: > > - Setting the dependency in the manifest manually and add > > pkg.depend-bypass to the files that complain or > > - Modify the Include path PKG searches. I am however unsure which exact > > knob in oi-userland to tweak here. > > Do you have examples from other packages of these two techniques? > I'd like to start with something that works. > > > You should see the override either in the Makefile or the Manifest look > > for "usr/lib/libjpeg6-ijg/lib" mentioned there. > > There's nothing in either for the print/cups-filters package. > Look in the Makefile, it should use image/library/libjpeg8-turbo not libjpeg6-ijg. Probably it is not installed on your system, execute gmake env-prep. > > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, > Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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] Location for gcc testsuite results
Hi, I have been running all the gcc testsuites again to compile a more or less exhaustive database. Where could I upload the results? I used to upload them here https://wiki.openindiana.org/oi/illumos+GCC but this is not an option anymore given that we want to retire the Wiki. 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] Hello OpenIndiana!
narval> g++-9 --version g++-9 (OpenIndiana 9.1.0-OI-0) 9.1.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. narval> g++-9 main.cpp narval> ./a.out Hello OpenIndiana! narval> file a.out a.out: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped, no debugging information available -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] oi-userland rebuild failures
Hi, for reference, find the list of rebuild failures, some related to python 3 migration of userland tools and pkg: cluster/pcs -> invalid manifest after ruby update desktop/gnome3/libgweather -> broken link desktop/gnome3/seahorse -> missing dependency? Couldn't find 'usr/lib/amd64/seahorse/xloadimage' in any of the specified search directories: desktop/gnome3/evolution-data-server -> ld.so.1: EDataServer-1.2: fatal: libstdc++.so.6: version 'GLIBCXX_3.4.21' not found developer/autogen -> 64-bit build fails which: no bash in ((null)) developer/jenkins -> pkgdepend issue developer/opensp -> broken with new gettext editor/bvi -> curses issue editor/emacs -> segmentation fault library/physfs -> wrong library path network/openconnect -> obsolete required package and pkgdepend error network/lftp -> curses issue openindiana/illumos-closed -> publish does not execute prep openindiana/qemu-kvm -> ctfmerge: failed to open ../cache-utils.o: File does not contain CTF data runtime/jruby -> java internal error runtime/clisp -> missing localcharset.h probably broken with new gettext sysutils/gtkperf -> broken with new gettext sysutils/bacula -> bacula-fd not built in 64-bit web/icedtea-web -> missing #include , obsolete since npapi dropped? x11/compat-links -> fix makefile, pkgdepend issue x11/compatibility -> fix makefile, pkgdepend issue -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Toward a SPARC distro of OI
On Mon, Jun 17, 2019 at 11:59 AM Gary Mills wrote: > I'm part way through this long project now. I began with v9os > installed on a Sun T2000. v9os is a SPARC distribution that uses IPS > packages. I've been building IPS packages from oi-userland source. > This process has gotten easier now that all the build tools I need are > in IPS packages. I've been replacing v9os packages with oi-userland > packages. My goal is to replace all of them, and finally to produce a > text ISO and package repository for SPARC that's entirely based on > oi-userland. > > So far, I've built and packaged versions 5, 6, and 7 of the gcc > compiler. The commands for IPS packages are all packaged for python > 2.7. My system now has 106 packages installed from oi-userland, > versus 343 packages from v9os. Most of the oi-userland products > required very few or no changes to build and package for SPARC. > > For perl, I've removed the 5.16.1 version from v9os and installed > versions 5.22 and 5.24 from oi-userland. Likewise, for python, I've > removed 2.6 and installed 2.7 and 3.4. Perl libraries are all > packaged for 5.22. Python libraries are all packaged for 2.7. > > I'm submitting this message to the mailing list mostly as a progress > report. I would, of course, appreciate a bit of help with this > project. > Congratulations Gary this is great :) If we get to the point that we can setup a build machine this would secure your work. Kind regards Aurélien > > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, > Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] On the way to Firefox 68 ESR
On Sat, May 11, 2019 at 3:31 PM Aurélien Larcher wrote: > > > On Sat, May 11, 2019 at 2:51 PM Michal Nowak wrote: > >> On 05/11/19 02:35 PM, Aurélien Larcher wrote: >> > Hello, >> > thanks for doing this. >> > >> > with Geoffrey Weiss we started working on the next Firefox ESR: >> > >> > https://github.com/OpenIndiana/oi-userland/pull/4999 >> > >> > >> > Which clang do you use? >> >> developer/clang-40, the only one we have. ? >> > > Ah so I guess I forgot to push 6.0, that may explain some differences I > had in my zone w.r.t rust. > I'll try to push newer clang together with gcc 9.1 next week. > > > >> >> > Maybe you should mention that people should not modify gcc headers in >> > their global zone. >> >> Just updated the PR, thanks. >> >> > >> > Aurélien >> > >> > >> > >> > >> > oi-dev mailing list >> > oi-dev@openindiana.org <mailto:oi-dev@openindiana.org> >> > 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 >> > > > -- > --- > Praise the Caffeine embeddings > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] On the way to Firefox 68 ESR
On Sat, May 11, 2019 at 2:51 PM Michal Nowak wrote: > On 05/11/19 02:35 PM, Aurélien Larcher wrote: > > Hello, > > thanks for doing this. > > > > with Geoffrey Weiss we started working on the next Firefox ESR: > > > > https://github.com/OpenIndiana/oi-userland/pull/4999 > > > > > > Which clang do you use? > > developer/clang-40, the only one we have. ? > Ah so I guess I forgot to push 6.0, that may explain some differences I had in my zone w.r.t rust. > > > Maybe you should mention that people should not modify gcc headers in > > their global zone. > > Just updated the PR, thanks. > > > > > Aurélien > > > > > > > > > > oi-dev mailing list > > oi-dev@openindiana.org <mailto:oi-dev@openindiana.org> > > 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 > -- --- Praise the Caffeine embeddings ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] On the way to Firefox 68 ESR
Hello, thanks for doing this. with Geoffrey Weiss we started working on the next Firefox ESR: > >https://github.com/OpenIndiana/oi-userland/pull/4999 > Which clang do you use? Maybe you should mention that people should not modify gcc headers in their global zone. Aurélien > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] pulseaudio issues
On Tue, Apr 2, 2019 at 4:19 PM Udo Grabowski (IMK) wrote: > On 02/04/2019 15:57, Gary Mills wrote: > > On Tue, Apr 02, 2019 at 10:54:25AM +, Alexander Pyhalov wrote: > > > >> If selection of device in mate-volume-control works for you, we can > >> just make it honor AUDIODEV is it set. > > > > It may already do that, although perhaps not correctly. > > > >> Your patches make pulseaudio use mod_solaris module, and it doesn't > >> provide interfaces necessary to select device in > >> mate-volume-control. So we either fix mod_solaris to support these > >> interfaces or fix our mod_oss patches to honor AUDIODEV. > > > > Yes, mod_solaris seemed most appropriate since illumos was derived > > from Solaris. Mod_oss seems to be for the Linux version of OSS. > > > > On OI_151a versions this has always been OSS and it worked - so > if pulse audio only delivers a "Linux version" of OSS this should > be fixed. Please don't fall back to ancient mod_solaris, that was > history already ten years ago... > Agreed. I have seen patches to fix the multiple device issue in the pulseaudio OSS module about two years ago, but cannot remember where. So probably the solution is not to fiddle with configuration flags or cope with obsolete interfaces. > -- > Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT > http://www.imk-asf.kit.edu/english/sat.php > KIT - Karlsruhe Institute of Technology http://www.kit.edu > Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026 > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
Re: [oi-dev] Firefox 60esr
On Fri, Nov 9, 2018 at 8:46 PM Michal Nowak wrote: > Aurélien, > > does Firefox 60esr build from what's in your 'firefox60' branch? > > I pulled from your 'firefox60' branch but I am unable to build Firefox, > it fails with: "NSModules are not ordered appropriately". More at: > https://paste.ec/paste/u-QGkgcO#Jf182EbyHq3Zt5s8MU9VVNHp3daKhtM-+z1OSxDkIrN > > If I remove that check from firefox-60.3.0/toolkit/library/libxul.mk it > fails with missing "Undefined symbol 'sendfile'": > https://paste.ec/paste/Ov5E1DuC#s1uY-Msq9w7alg5xMgWPJLONv0kypS3yulQPjDxBh2b. > > When I fix it manually, it later hangs at: > > Executing > /export/home/newman/ws/oi-userland/components/web/firefox/build/amd64/dist/bin/shlibsign > > -v -o ../../dist/firefox/libsoftokn3.chk -i > ../../dist/firefox/libsoftokn3.so > moduleSpec configdir='' certPrefix='' keyPrefix='' secmod='' > flags=noCertDB, noModDB > > The process takes one whole core for an hour doing something. When I > make SIGN_LIBS from firefox-60.3.0/toolkit/mozapps/installer/packager.py > empty, it finally publishes, but the firefox process eventually dumps > core (which is not that surprising for me reading your IRC posts :) ): > Yeah I did not push the patches for these issues as they are a bit "piggy"... > > $ mdb core > mdb: core file data for mapping at 22fbf7c39000 not saved: Bad address > mdb: core file data for mapping at 22fbf7c59000 not saved: Bad address > Loading modules: [ libc.so.1 libnvpair.so.1 libuutil.so.1 libavl.so.1 > ld.so.1 ] > > ::status > debugging core file of firefox (64-bit) from lenovo > file: /usr/lib/amd64/firefox/firefox > initial argv: /usr/bin/firefox > threading model: native threads > status: process terminated by SIGSEGV (Segmentation Fault), pid=2975 > uid=101 code=-1 > > $C > fd7fffdfe730 libc.so.1`_lwp_kill+0xa() > fd7fffdfe760 libc.so.1`raise+0x20(b) > 000b > libxul.so`_ZN13nsProfileLock18FatalSignalHandlerEiP7siginfoPv+0xff() > > I am bit more surprised that Firefox 62 from Joyent's binary pkgsrc > dumps for me as well: > https://paste.ec/paste/xdeCYjGD#rSuQOzMOl+QmumtxpSLR1LU6WzblzSV7uroLrrua2eE It seems that there is an issue with loading the profile (32bit vs 64bit?). If you mv the directory it should start but it is still shaky. Also pkgsrc does not use some Solaris specific code, instead patches code used by BSDs... Due to the inconsistency of ifdefs (SOLARIS, OS_SOLARIS) there is a mixed bag of code used... > > > Michal > > ___ > oi-dev mailing list > oi-dev@openindiana.org > 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
