[oi-dev] rebuilding system/xvm/xvmstore ?
All- Both my workstation and my Virtualbox OI build box have system/xvm/xvmstore installed, I think because it's listed as part of the 'server_desktop_amd64' meta package. From what I can tell, system/xvm/xvmstore hasn't been rebuilt since 2013, and I haven't been able to find the component for it in oi-userland. It doesn't appear to contain any metadata for Illumos either, so I don't think it comes from illumos-gate. xvmstore is the only thing on my system that depends upon system/library/gcc-3-runtime. I would be willing to do the work to trigger a rebuild against a newer GCC runtime, if someone could clue me in on where the actual component is. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] inkscape calls gcc7 and 10
In regard to: Re: [oi-dev] inkscape calls gcc7 and 10, Udo Grabowski (IMK)...: On 04/07/2023 11:08, Udo Grabowski (IMK) wrote: On 04/07/2023 10:53, Marcel Telka wrote: On Tue, Jul 04, 2023 at 10:20:32AM +0200, Udo Grabowski (IMK) wrote: Hi, the story with the mixup continues, this time inkscape. Crashes, shows both gcc/7 and gcc/10 The inkscape's problems are basically these: Since Udo brought it up, I took a look at what's involved in updating inkscape to current latest stable (0.92.4 -> 1.2.2). The old all-in-one source is no longer a thing, so if we build from released tarballs, we'll potentially need to fetch and extract multiple components. Questions about that: 1) lib2geom is required, but it could be built and packaged separately. Nothing else (other than inkscape) that I'm aware of uses it currently. Would it be preferable to have it as a separate package, or just build it and package it in the same package as inkscape? 2) some of the extensions require low-use libraries, like the 'libwpd' that Udo mentioned. Should the inkscape extensions that require these esoteric libraries be split into separate packages, so 'image/inkscape' has fewer dependencies, but 'image/inkscape/extension/wordperfect' (or whatever) can optionally be installed to get support for that legacy format? Next, 1.2.2 actually builds without *any* of the local patches, though I still need to look through them to see if there are any OI-customization patches that we still need. Many of the existing patches are for math library functions like log(), sin(), pow(), etc. where integers rather than doubles were being passed. I can update these so they apply to 1.2.2, but they seem to be no longer required (probably because of gcc/g++ 10.x). Question: 3) is it worth updating these patches, if they're not needed to actually build any more? I'm tempted to say no, but I'm willing to update them if Andreas or others have strong feelings about keeping as many as possible. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] sqlite-3 mapfile needs API updates
All-
I think the mapfile that's being used with our sqlite-3 is out of date,
and it's causing symbols that should be part of the public API to be
tagged as 'local', rather than 'global'.
The two I've noticed that should be 'global' are
sqlite3_bind_pointer
sqlite3_result_blob64
but now that I know it's because of our mapfile, I've found many more,
and I've only begun looking. Example:
https://www.sqlite.org/bindptr.html
Those functions were added at 3.20.0 in 2017, but are being marked 'local'
by our mapfile.
If I modify our mapfile so the most recent group:
SYMBOL_VERSION sqlite_3.31.1 {
global:
sqlite3_column_origin_name;
sqlite3_column_origin_name16;
sqlite3_column_table_name;
sqlite3_column_table_name16;
sqlite3_drop_modules;
sqlite3_filename_database;
sqlite3_filename_journal;
sqlite3_filename_wal;
sqlite3_hard_heap_limit64;
sqlite3_keyword_check;
sqlite3_keyword_count;
sqlite3_keyword_name;
sqlite3_stmt_isexplain;
sqlite3_uri_key;
sqlite3_value_frombind;
} sqlite_3.19.0;
Becomes something like this:
SYMBOL_VERSION sqlite_3.31.1 {
global:
# some symbols listed here
} sqlite_3.28.0;
SYMBOL_VERSION sqlite_3.28.0 {
global:
# some symbols listed here
} sqlite_3.23.0;
SYMBOL_VERSION sqlite_3.23.0 {
global:
# some symbols listed here
} sqlite_3.22.0;
SYMBOL_VERSION sqlite_3.22.0 {
global:
# some symbols listed here
} sqlite_3.20.0;
SYMBOL_VERSION sqlite_3.20.0 {
global:
# some symbols listed here
} sqlite_3.19.0;
is that going to break everything that uses symbols in the current
sqlite_3.31.1 "block"? Obviously I would add blocks for function
additions since 3.31.1.
BTW, I looked at the Solaris userland mapfile for sqlite-3 and theirs
differs significantly from ours, but it actually appears ours is more
up to date.
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
Re: [oi-dev] libpulsecore error
In regard to: Re: [oi-dev] libpulsecore error, Gary Mills said (at 9:59pm...: On Wed, Mar 08, 2023 at 01:47:25PM -0600, Tim Mooney via oi-dev wrote: I believe what the error message is saying is that your current theme is not supplying a value for max-recent-items, but the gschema says there should be one. So, the cause could be a faulty theme. That would be my first guess. When mate-panel isn't actually crashing, doing something like - remove existing .xsession-errors # to be thorough, also removing ~/.config or using a fresh account would be # best - use the mate "Appearance" application to choose a theme - log out - log back in - check the new .xsession-errors for theme-related warnings can be used to determine which themes are outdated or have problems. glib and its theme-related code and MATE sometimes deprecate settings and layout-related CSS, and if a theme doesn't follow that lead, that will often show up as warnings or errors in the .xsession-errors. I know nothing at all about themes. Is there a way to find out which theme I'm using? It would have to be in a CLI session, since the graphic login never completes. You can do a lot of setting-related exploring using one of these 3 tools: dconf gsettings gconftool-2 There is considerable overlap between those tools, such that I'm never sure which one to start with. In this case, I was able to find an answer using 'gsettings'. *Many* of the "overall MATE" settings are going to be in the 'org.mate.Marco' "namespace", so doing gsettings list-recursively org.mate.Marco will show you a lot of your general desktop environment settings. In particular, in there you'll see one for "theme": $ gsettings list-recursively org.mate.Marco | egrep theme org.mate.Marco.general theme 'nimbus' Alternatively, is there a way to disable mate-panel, as that application seems to be the one that fails repeatedly? In theory you could replace mate-panel with some other compatible panel, but OI doesn't ship one so you would have to find one, build it, install it, and figure out how to make MATE use it. You could try renaming 'mate-panel' to e.g. 'mate-panel.BAK' and then putting a simple shell script in its place that runs and never exits. I don't think you're going to have a great desktop experience doing that, though. You might be better off just choosing "xterm" from the lightdm login screen, at least until you can further debug what's going on with your environment. 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
Re: [oi-dev] SUnit and gmake test on OpenIndiana
In regard to: Re: [oi-dev] SUnit and gmake test on OpenIndiana,...: but for Squeak it cannot find its plugin directory when started from the build directory to load loadable plugin modules. So for Squeak as a workaround it is still necessary to run gmake install to stage the plugins to the prototype area from where they can be loaded. That's atypical, and not really desirable behavior. Is there an environment variable that can be overridden during the test, to point squeak at the directory/directories that contain the *uninstalled* plugins? However in the case of Squeak the 'gmake install' should be done before the 'gmake test'. That is not how the make-rules seem to be set up. Requiring that something be "installed" (even though in this case it's being copied into a staging area for packaging) before it can be tested is backwards. The vast majority of open source software does not do that, and OI's targets are set up to assume the more common behavior of being able to test before anything has been installed. 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
Re: [oi-dev] COMPONENT_TEST_TRANSFORMS for PARI
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] perl 5.34 next steps
All- perl 5.34 was added to hipster a while ago, and I recently finished doing package rebuilds for all perl modules in oi-userland[1], so that we now have a version of each module for perl 5.22, perl 5.24, and perl 5.34. There are a number of things that need to happen before we can make perl 5.34 the default version and retire 5.22 and 5.24. I'm aware of some of the things that need to happen, but there's probably plenty of things that I'm not aware of, that need to be added to the "to do" list. In addition, even for the steps I know about, there's some question as to what order is best (safest?) to perform the steps. I'm therefore looking for input on how we proceed. If there's anyone reading this that's been through the process previously, any info you can share or missing steps you can fill in would be especially welcome. I have a saved email from Alexander from March 19 of 2014 (it didn't make it into the oi-discuss archives, sadly) where he outlines several of the steps related to perl 5.10 and 5.16, but portions of the process have changed, so I don't know how relevant it is. The steps I know about: - add 5.34 to PERL_VERSIONS and PERL_64_ONLY_VERSIONS in make-rules/shared-macros.mk. At the same time (or later), those same overrides can be removed from each perl module component. I think this should be safe to do now, or at any time. - it might be necessary (not sure) to manually change the mediator for perl on build systems, depending upon what order we pursue these steps. - change illumos-gate so that it uses perl 5.34 to build runtime/perl-534/module/sun-solaris. This involves setting echo export PERL_VERSION=\"5.34\"; \ echo export PERL_PKGVERS=\"-534\"; \ echo export PERL_VARIANT=\"-thread-multi-64\"; \ echo export BUILDPERL32=\"#\"; \ echo export BUILDPERL64=\"\"; \ in oi-userland/components/openindiana/illumos-gate/Makefile and then rebuilding illumos-gate. I'm currently getting a build error for the sun-solaris module doing that and I don't know if it's because I need to change my build system's perl mediator or if there are other problems I haven't discovered yet. Alexander also commented in [1] that there may be a chicken-or-the-egg problem, so there may be some manual steps required on the build box once the changes are committed to oi-userland. - change PERL_VERSION from 5.22 to 5.34 in make-rules/shared-macros.mk. This (I think) changes the "default" version of perl on the system. I don't know if it causes pkg to automatically change the mediator(s) on next pkg update. - identify what packages (outside of the library/perl-5/*-522 FMRI namespace) depend upon runtime/perl-522. I think (but am not certain) that we want to change PERL_VERSION to 5.34 first, and then start rebuilding any packages that depend upon 5.22, so they now depend upon 5.34. Alternately, we could potentially do what I did for each of the library/perl-5/* module rebuilds, and override PERL_VERSION directly in the component, so that component defaults to 5.34 even before the system-wide default changes. - same process for runtime/perl-524. Since it has never been the default version of perl on OI, there should in theory be a smaller set of packages that depend upon it. These will need to be rebuilt with PERL_VERSION=5.34 too - do we (?) want to modify the runtime/perl-522 and/or runtime/perl-524 packages so that they become "dummy" packages that just point to the 534 runtime? Alexander mentioned this as a possibility in the process he outlined in 2014. - retire (obsolete) 5.24. I don't know what's involved in this, but I do know it's going to be near the end of the process, so there's plenty to get done first. - retire (obsolete) 5.22. Same as perl 5.24. - after 5.22 is completely gone, we can rip out all the 32 vs. 64 code in make-rules/makemaker.mk, leaving just the settings for 64 bit builds. That should simplify makemaker.mk considerably. So what steps am I missing, and what's the safest order to apply these steps? It's OK with me if this process takes several weeks, if it can be done in a safe, careful manner. Longer term, after we've made progress on making 5.34 the default and obsoleting the older perls, the road is much easier: - update our existing perl modules, as appropriate. - specific to the SSL module(s), switch to OpenSSL 1.1 as part of updates. - add a handful of the most useful, most widely used perl modules that we don't currently ship. I've identified a few, including JSON & JSON XS YAML Text::CSV & Text::CSV_XS Socket6 IO::Socket::SSL & possibly Crypt::SSL LWP::Protocol::https a few of the Test:: modules (Test::Pod, Test::Warning, maybe more) possibly Module::Build, though that has miserable dependencies [1] alp explained that although we have a
[oi-dev] manually specifying dependencies between scripting language modules
All- My basic question is what the best practice is for how packagers should be specifying dependencies between language modules/libraries for scripting languages? Currently I'm specifically interested in perl modules, but the same idea is relevant for python, ruby, etc. As an example of one way to do it, there's oi-userland/components/perl/libwww-perl/libwww-perl-PERLVER.p5m. Alexander manually added all of the modules that are needed for libwww-perl-###, using the most obvious, "friendly" syntax for depend: depend fmri=library/perl-5/encode-locale-$(PLV) type=require depend fmri=library/perl-5/file-listing-$(PLV) type=require depend fmri=library/perl-5/html-parser-$(PLV) type=require etc. Doing it that way, though, those dependencies don't get added to Makefile when you do "gmake REQUIRED_PACKAGES", and they don't appear to be added to the "pkg5" metadata after a successful publish. The same is true if you want to make a language module depend upon the version of the perl interpreter it was built for. I first tried using this syntax: depend fmri=runtime/perl-$(PLV) type=require or variants of it as outlined in the pkg guide, like: depend fmri=pkg:/runtime/perl-$(PLV) type=require Dependencies specified that way aren't output by REQUIRED_PACKAGES. However, if you change the syntax to a "less obvious" method: depend fmri=__TBD pkg.debug.depend.file=perl \ pkg.debug.depend.path=usr/perl5/$(PERLVER)/bin type=require then REQUIRED_PACKAGES *does* add the dependency to the Makefile and the pkg5 metadata. That's a trick that Aurélien has used in some places. So what's the right thing to do here? Use the simple syntax in the .p5m file and don't care that the dependency isn't listed in the Makefile or pkg5? Use the more complicated syntax, with "fmri=__TBD" and a file and path from the dependency? Don't specify anything in the .p5m file and instead manually add the dependency in the Makefile, as you might for a build dependency? I'm happy to fix up missing inter-module dependencies when I find them, but I would like to follow whatever the best practice is for these types of dependencies. Thanks, Tim -- 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
Re: [oi-dev] some Newbie questions
In regard to: Re: [oi-dev] some Newbie questions, Friedrich Kink via oi-dev...: finally I was able to push my new package. May I ask the maintainers to check the perl module Tk (components/per/Tk) in my branch Tk. If this is not the right way for asking please let me know. Once you pushed from your build box to your fork of oi-userland in your github account, the next step is for you to open a "pull request" (PR). At least with git on my build box, when I *first* push a new branch from my build box to my forked repository in my github account, the git client actually outputs a URL that I can just cut-and-paste into a browser to go right to the new pull request. If that wasn't the case for you, that's no problem. You just need to go to your forked copy of oi-userland in github (the drop-down from your profile in the upper-right corner has a "Your repositories" selection, you can find your copy of oi-userland in that list). Once you're viewing your fork of oi-userland, there should be a bit of information near the top that talks about your "Tk" branch, with a button for you to open a pull (or merge) request. If you click that and fill in any additional information you feel is relevant, your pull request will become visible to the OpenIndiana/oi-userland, under pull requests. The rest of the review and merge workflow will happen within that pull request. PS: I'm not much ahead of you on github workflow and git, and virtually everything I've learned has been from patient coaching of OI maintainers like Alexander, Aurélien, Michal, and now Andreas. Don't be afraid to ask questions here, and don't worry about being a github "newbie". I am too, but I'll happily help when I can, as will others I'm sure. Tim Thanks a lot, Fritz Am 29.12.2021 um 20:52 schrieb Andreas Wacknitz: Am 12/29/21 um 20:46 schrieb Friedrich Kink via oi-dev: Hi David, basically I prepared the package ;-) but I'm not able to push it as described at the end at https://docs.openindiana.org/dev/userland/. I get (I did |git checkout -b Tk before) | git push origin Tk remote: Permission to OpenIndiana/oi-userland.git denied to fritzkink. You'll need to check what origin is. "git remote -v" will tell you about your configured remotes. You are only allowed to push to Github repositories that you have sufficient rights for. This is typically your own fork. When you push to your own fork (which is usually but not necessarily named origin) you can then create a PR (pull request) against the repository you have forked from on Github. which is probably ok as it most likely has to be reviewed by maintainers first. Otherwise I'm just struggling with my limited git experience. kind regards, Fritz Am 28.12.2021 um 20:19 schrieb s...@pandora.be: Personally I'd like to request a perl tk package. This can be used for TeXLive on OpenIndiana. Currently the pagehttps://tug.org/texlive/distro.html lists: Debian: aptitude install perl-tk Ubuntu: apt-get install perl-tk Gentoo: emerge dev-perl/Tk # older: dev-perl/tk ... but no OpenIndiana. However I'm sure that if there were a perl-tk package, then it'd work for TexLive install-tl. It would be nice if you could just do "pkg install perl-tk" in OpenIndiana. This is a personal opinion, I do not know whether such a package would be hard/difficult to make, and whether it would be accepted. But TCL/Tk is in the OpenIndiana repo. TCL version 8.6.12, which should be fine for TexLive as this requests TCL 8.5 or higher. In fact I am sure perl/tk works, I compile it manually for the tlmgr -gui: http://docs.openindiana.org/handbook/community/texlive/ Anyway if you would have a look at the Perl packages, I guess that would be a most welcome contribution. Regards, David Stes - Op 28 dec 2021 om 13:11 schreef oi-devoi-...@openindiana.org: Hello Tim, thank you for the warm welcome. And thank you for the very valuable answers and hints. They helped already a lot. I guess I 'll need some more time to get to the nitty-gritty details. But I hope to be able to upload a first package soon. Fritz Am 27.12.2021 um 23:11 schrieb Tim Mooney via oi-dev: In regard to: [oi-dev] some Newbie questions, Friedrich Kink via oi-dev...: Hello and welcom, Fritz! reading silently for a couple of years this mailing list I decided now to contribute to the community my extensions I made over the years to my system (at least I'd like to try ;-)). The main purpose of my system is to act as mail server supporting all modern security features like DANE, SPF, DKIM, DMARC etc (which works btw for couple of years already, basically I started with opensolaris). That's why I'll focus on those packages. Of course I've some questions after starting this endeavor. Especially when trying to build Sp
Re: [oi-dev] some Newbie questions
In regard to: [oi-dev] some Newbie questions, Friedrich Kink via oi-dev...: Hello and welcom, Fritz! reading silently for a couple of years this mailing list I decided now to contribute to the community my extensions I made over the years to my system (at least I'd like to try ;-)). The main purpose of my system is to act as mail server supporting all modern security features like DANE, SPF, DKIM, DMARC etc (which works btw for couple of years already, basically I started with opensolaris). That's why I'll focus on those packages. Of course I've some questions after starting this endeavor. Especially when trying to build Spamassassin which requires a lot of additional Perl modules. While start building these modules it turned out that the provided 64bit Perl version 5.24 is pretty outdated. So I built the current stable version 5.34 based on the existing 5.24 setup. Worked like a charm ;-). Now first question: Is there a reason/dependency for not upgrading to a newer version? It's likely a combination of - limited contributor time - contributor interest - complexity of the task I do have an update to perl planned, but there are some details to work out and I probably won't be back to looking at the perl modules until I'm done with some MATE-related stuff. Next question: Some Perl modules have odd version like 1.04 which makes publishing a package impossible because of the padding zero in the number after the dot. What is the reason for bailing out on a padding zero (just a question for me and my understanding ;-))? That reason for that is probably documented in the documentation for pkg, http://docs.openindiana.org/dev/pdf/ips-dev-guide.pdf though I would have to do some searching to find the exact section. I think it comes down to "design choice". As much as I like perl and have done lots of programming with it over the years, its module numbering system leaves a lot to be desired. The standardization on "semantic versioning" that most other software has done would be a welcome change in the perl module community, IMHO. That, of course, will never happen, but it sure would be nice if it did. Also, some packages will require a new user and/or group. Are uids/gids managed centrally or can I just choose some numbers <100 not used to my best knowledge? There is a file in oi-userland that documents the reserved IDs: https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/doc/reserved_uids_and_gids.md If you need to add to that list, starting with a PR for that file is probably the way to go. How to store test results (I haven't found the trick where the results get stored in the test directory while comparing existing packages with mine). Create the test directory and within there create (touch) results-32.master # if your component has a 32 bit build results-64.master # if your component has a 64 bit build there are other possible variants the file could be named, for special build conditions. Look through the test directories for the various components in oi-userland to get an idea of other possibilities. Then, add various COMPONENT_TEST_TRANSFORMS to your Makefile, to filter out any of the test output that will vary between build systems (PATHs, timing, etc.). Once you have (empty) results files, the test target will start outputting diffs. Incorporate the output into your results files until there are no more diffs. And finally when I think I'm ready to release my package would this list be the place to ask for integration? You can mention it here if you want, but following the "Building with oi-userland" guide has a section on preparing your Github pull request (PR). Most of the component update work happens following that guide, and the final integration piece comes via the pull request. http://docs.openindiana.org/dev/userland/ 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
Re: [oi-dev] elegant way to get leaf packages?
In regard to: Re: [oi-dev] elegant way to get leaf packages?, Till...: 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. Thanks Till! Since my initial idea was to find all leaf nodes, it didn't occur to me to start by first looking for leaf nodes only among my installed software. There are a lot of OI packages I don't have installed on either my main workstation or my build box, but your suggestion about searching locally is still a good one. Your suggestion to use oi-userland is also a good idea. I think I'm going to use that approach. I had no real idea what percent of packages were now 64-bit only, so this exercise is really just for me to get a clearer picture of what components still ship 32 bit binaries. Thanks again, 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
Re: [oi-dev] elegant way to get leaf packages?
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? -- 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] elegant way to get leaf packages?
All- Is there an elegant way using pkg (or some other method) to get all OpenIndiana "leaf" packages, i.e. packages that are not a dependency of some other package? I know how to get this using a brute-force method that is essentially all_packages=`pkg list -a | some filtering here` for p in `echo $all_packages` do pkg search -r -o pkg.name "depend:require:$p" > depends-upon-$p done I'm just wondering if there is a more clever, or perhaps less intensive on the publisher server, way to get the same info? Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Some packages did not build anymore in userland
In regard to: Re: [oi-dev] Some packages did not build anymore in userland,...: On Wed, Dec 22, 2021 at 08:58:12PM +0100, Alexander Jung wrote: i build the whole oi-userland from time to time, but in the last time there are many packages they did not build anymore. I tried a fresh install and fresh sync of oi-userland but it is the same. For example glib stops with this message ... [...] /usr/gcc/9/bin/gcc -Igio/gresource.p -Igio -I../../glib-2.66.8/gio -Igmodule -I../../glib-2.66.8/gmodule -I. -I../../glib-2.66.8 -Iglib -I../../glib-2.66.8/glib -Igobject -I../../glib-2.66.8/gobject -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 -O3 -D_GNU_SOURCE -fno-strict-aliasing -DG_DISABLE_CAST_CHECKS -Wduplicated-branches -Wimplicit-fallthrough -Wmisleading-indentation -Wstrict-prototypes -Wunused -Wno-unused-parameter -Wno-bad-function-cast -Wno-cast-function-type -Wno-pedantic -Wno-format-zero-length -Werror=declaration-after-statement -Werror=format=2 -Werror=implicit-function-declaration -Werror=init-self -Werror=missing-include-dirs -Werror=missing-prototypes -Werror=pointer-arith -m32 -O3 -Wno-error=format-nonliteral -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -MD -MQ gio/gresource.p/gresource-tool.c.o -MF gio/gresource.p/gresource-tool.c.o.d -o gio/gresource.p/gresource-tool.c.o -c ../../glib-2.66.8/gio/gresource-tool.c I've seen that behavior too. It's a bug in ninja, but the developer refuses to accept complaints about it. Ninja unconditionally defines _FILE_OFFSET_BITS=64 . The bug affects only 32-bit builds, but sometimes you need a 32-bit build. Wow, good find Gary. I'm sure I would have wasted a bunch of time debugging that. It's easily fixed on OI, by a patch that removes the offending statement. Is that something someone else has had rejected in the ninja bugtracker, or what's the provenance of that patch? Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Some packages did not build anymore in userland
In regard to: [oi-dev] Some packages did not build anymore in userland,...: i build the whole oi-userland from time to time, but in the last time there are many packages they did not build anymore. I tried a fresh install and fresh sync of oi-userland but it is the same. For example glib stops with this message ... I had the exact same problem when I was looking at building our current glib. Because of the holidays and other projects, I haven't had a chance to get back to it, but you're not the only one seeing that problem. In file included from ../../glib-2.66.8/gio/gresource-tool.c:32: /usr/include/libelf.h:43:2: error: #error "large files are not supported by libelf" 43 | #error "large files are not supported by libelf" | ^ [396/1081] Compiling C object gio/gio-querymodules.p/giomodule-priv.c.o ninja: build stopped: subcommand failed. Or another problem is that GCC-7 did not build the gobjc stuff. Do i have messed something up? I haven't tried gcc so I can't comment on that issue, but the glib issue isn't anything you're doing wrong. I'm wondering if we've incorporated a new libelf from Illumos recently and the glib issues are because of changes in that dependency? 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] upstreaming our libtool search_path patch
All- After years of being without one, libtool has a maintainer again. The first step he or she is taking is to go through the backlog of patches from the various Linux and BSD distros, to apply any that are generally useful. We're currently carrying two patches against libtool, while Oracle's solaris-userland has just one: https://github.com/oracle/solaris-userland/blob/master/components/libtool/patches/000-64-bit-sys_dlsearch_path.patch Theirs appears to be just an alternate approach to solving the same problem as our first patch. Any objection to pointing the maintainer at the solaris-userland patch and letting them know that that patch is beneficial for both commercial Solaris and for OpenIndiana? I would like to get one of the patches into upstream, and it seems easiest to vote for the solaris-userland one as acceptable to both OSes. 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] libxml2 mapfile and symbol removal
All-
I'm investigating how difficult it might be to update libxml2 and libxslt
to current latest versions.
Unfortunately, libxml2 removed a bunch of formerly public symbols at
version 2.9.10:
# emptyExp; removed in 2.9.10
# forbiddenExp; removed in 2.9.10
# xmlExpCtxtNbCons; removed in 2.9.10
# xmlExpCtxtNbNodes; removed in 2.9.10
# xmlExpDump; removed in 2.9.10
# xmlExpExpDerive; removed in 2.9.10
# xmlExpFreeCtxt; removed in 2.9.10
# xmlExpFree; removed in 2.9.10
# xmlExpGetLanguage; removed in 2.9.10
# xmlExpGetStart; removed in 2.9.10
# xmlExpIsNillable; removed in 2.9.10
# xmlExpMaxToken; removed in 2.9.10
# xmlExpNewAtom; removed in 2.9.10
# xmlExpNewCtxt; removed in 2.9.10
# xmlExpNewOr; removed in 2.9.10
# xmlExpNewRange; removed in 2.9.10
# xmlExpNewSeq; removed in 2.9.10
# xmlExpParse; removed in 2.9.10
# xmlExpRef; removed in 2.9.10
# xmlExpStringDerive; removed in 2.9.10
# xmlExpSubsume; removed in 2.9.10
At a minimum, that likely means that nearly everything that depends
upon libxml2 will need a rebuild.
My question is about what should be done to the mapfile we use with
libxml2. Most of these symbols are marked "global" at
SYMBOL_VERSION SUNW_1.6 {
Do I just comment them out of that block, or is there some other better
way to handle these now-removed symbols?
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] packaging scripts that use python3
All- I'm trying to find what the best practices are for packaging scripts that use python 3. In a couple of cases I've run into recently, configure or meson have found /usr/bin/python3 and used that in the sh-bang in the script, only to have the 'publish' target fail because ips.mk wants a specific version. What's the right thing to do here? Just pick a specific python version (like python3.9) and use that in the sh-bang? If so, which version? Are there settings that should be present in the Makefile that would help "abstract" what the preferred python version is? I know there's $(PYTHON), but that still points to 2.7. I'm just wondering if there's something like PYTHON3_PREFERRED or similar, so that different components don't have different versions of python 3 hardcoded. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Logitech C930e
In regard to: [oi-dev] Logitech C930e, s...@pandora.be said (at 12:35pm on...: Perhaps it makes more sense to capture video with "ffmpeg". I'm in the process of updating ffmpeg right now, I have 4.4.1 built and have been working on the necessary rebuilds for its dependencies. I've made relatively minor changes to how it's built, because I'm concerned about it not being "redistributable". That message is output after configure for both the current 3.2.14 version OI is shipping and the rebuild I've done with 4.4.1. Andreas and I have discussed it a bit in one of the PRs I have related to gstreamer1 plugins. He was the one that pointed out I would need to tackle ffmpeg to update gst-libav1. If the updates I've made are merged, it's probably worth looking at what other changes should be made to how ffmpeg is built. The same is probably true of VLC; the TLS connector is not currently being built for that, which limits some of its functionality. I should have the PR for ffmpeg and its deps in the next couple days. I can ping you if you want to try the updated build, but I suspect more build changes will be needed. 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
Re: [oi-dev] gstreamer1 and OpenGL/EGL
In regard to: gstreamer1 and OpenGL/EGL, Tim Mooney said (at 2:44pm on Oct...: I'm working my way through updating the gstreamer1 components to the latest version (1.16.2 -> 1.18.5). They've switched from autoconf to meson, so the biggest hurdle has been converting the Makefile to use the new configuration options. With a bunch of help from Andreas, I've made good progress on these updates. There are lots of optional things that aren't being built, but in reading through the options, there's a couple of dependencies that might be useful to add (eventually): - the modified Fraunhaufer AAC codec, fdk-aac, which is supposedly quite good: https://en.wikipedia.org/wiki/Fraunhofer_FDK_AAC It builds very easily on OI. - We already have libx264 in encumbered, but several A/V packages could also make use of OpenH264: https://www.openh264.org/ That would require some porting, though, as it currently only has knowledge of headers and such for Linux, MacOS, FreeBSD and Android. It may be difficult and not worth the effort, or it might be easy. I'll try find out in the next couple weeks. I have a couple questions about these, though. 1) both components are ostensibly codecs and we have a FMRI "namespace" for codecs, but there aren't many packages in there and some packages that I might have guessed would be under codec/ are instead in libraries/audio/ or just video/ So what defines whether codec/fdk-aac or codec/openh264 is a better fit than e.g. library/audio/fdk-aac ? What are the guidelines that would help someone decide whether these two packages should go? I personally would probably choose codec/ for both of them, but if there are some guidelines that can help clarify, I would be happy to hear them. 2) openh264 has a very open license so there are no licensing concerns with including it in OI. It wouldn't even need to go in encumbered, which is a potential "pro" for including it. I'm less certain about fdk-aac. According to the licensing section of that wikipedia article, both Red Hat's legal team and the EFF have decided fdk-aac is "open", at least for redistribution, but apparently to actually use it the end user should have a "use license". Anyone have any aversion to including this because of licensing issues? I tempted to say this wouldn't need to go in encumbered either, but it's less clear with fdk-aac. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] crypto/ca-certificates
In regard to: Re: [oi-dev] crypto/ca-certificates, s...@pandora.be said (at...: I tested building a 3.72 package but that also does not solve the problem. $ pkgrepo -s i386/repo/ list PUBLISHER NAME O VERSION userland crypto/ca-certificates 3.72-2020.0.1.0:20211028T165026Z The problem remains for both 3.71 and 3.72 that $ pkg contents ca-certificates | grep DST etc/certs/CA/DST_Root_CA_X3.pem So the expired certificate remains in the package. I am not certain how this should be solved. Red Hat's approach was to remove 'DST Root CA X3' from their packaged ca-certificates bundle. https://access.redhat.com/articles/6338021 I'm not certain how other popular Linux distros have addressed it, but only a few distros do long-term support, so those would be the ones most impacted by it. 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
Re: [oi-dev] gstreamer1 and OpenGL/EGL
In regard to: Re: [oi-dev] gstreamer1 and OpenGL/EGL, Gary Mills said (at...: On Tue, Oct 26, 2021 at 02:44:25PM -0500, Tim Mooney via oi-dev wrote: I'm working my way through updating the gstreamer1 components to the latest version (1.16.2 -> 1.18.5). They've switched from autoconf to meson, so the biggest hurdle has been converting the Makefile to use the new configuration options. Meson is somewhat broken, except when Unix=Linux. It also does not work well for 32 and 64-bit builds. One solution is to omit the 32-bit build. If it's really needed, you must find another solution. I've been able to get the current meson in OI to do both 32 and 64 bit builds without any real trouble. Most of the 32 & 64 work that Aurélien and Michal had previously done for these packages still applies and has continued to work with meson & ninja. The issue for this one package starts when it calls out to qmake, for Qt. That's its own separate build system. I'm sure that if I knew more about Qt and qmake I could set a combination of PATH.32, PATH.64, CFLAGS.32, CFLAGS.64 and probably additional settings to eventually get qmake to behave. I don't think it's worth doing in this case though; having the base set of gstreamer1 plugins depend upon Qt5 for some tiny bit of extra functionality isn't worth it. I don't personally think meson is any real improvement over autotools, but it's supplanted autotools in most of the GNOME stuff so I'm trying to learn it well enough to get by. 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
Re: [oi-dev] gstreamer1 and OpenGL/EGL
In regard to: Re: [oi-dev] gstreamer1 and OpenGL/EGL, Till Wegmüller said...:
Is there any big change if we let meson decide it itself?
Yes, unfortunately. If I don't specify anything GL-related, it also finds
Qt5 and qmake, but it gets the ABI wrong (it's using qmake to build 64 bit
Qt5-related code during the 32 bit build) and linking fails.
There is no option to just disable qt5, at least for these plugins. There
is for at least one of the later sets of plugins.
Limiting what it could select for OpenGL was the only built-in way I found
to avoid the Qt5 linking failures.
I could go back and try patch out the Qt5 code, instead, but that's likely
more work.
Usually we only disable stuff if compilation is broken, so there is no
feature limit on purpose in OI. Just things that are broken or need
additional deps nobody had the time for.
I'll keep that in mind for future components.
Thanks!
Tim
On 26.10.21 21:44, Tim Mooney via oi-dev wrote:
All-
I'm working my way through updating the gstreamer1 components to the
latest version (1.16.2 -> 1.18.5). They've switched from autoconf to
meson, so the biggest hurdle has been converting the Makefile to use
the new configuration options.
With the current 1.16.2, gst-plugins-base1 specifies
CONFIGURE_OPTIONS += --disable-gles2
but nothing else OpenGL related.
Unfortunately, gst-plugins-base1 for 1.18.5 with meson doesn't have
the same option meanings, so there's no one-to-one mapping between our
old configuration and the new. The meson_options related to OpenGL are
# OpenGL integration library options
option('gl_api', type : 'array', choices : ['opengl', 'gles2', 'auto'],
value : ['auto'],
description : 'A comma separated list of opengl APIs to enable
building against'
)
option('gl_platform', type : 'array',
choices : ['glx', 'egl', 'cgl', 'wgl', 'eagl', 'auto'],
value : ['auto'],
description : 'A comma separated list of opengl platforms to
enable building against'
)
option('gl_winsys', type : 'array',
choices : ['x11', 'wayland', 'win32', 'winrt', 'cocoa',
'dispmanx', 'egl', 'viv-fb', 'gbm', 'android', 'auto'],
value : ['auto'],
description : 'A comma separated list of opengl windows systems
to enable building against. Supported values are x11, wayland,
win32, winrt, cocoa, dispmanx, egl, viv-fb, gbm, and android'
)
option('egl_module_name', type : 'string',
value : '',
description : 'The file to pass to g_module_open to open the
libEGL library (default: libEGL)'
)
option('opengl_module_name', type : 'string',
value : '',
description : 'The file to pass to g_module_open to open the
libGL library (default: libGL)'
)
option('gles2_module_name', type : 'string',
value : '',
description : 'The file to pass to g_module_open to open the
libGLESv2 library (default: libGLESv2)'
)
#
# Feature option for opengl plugin and integration library
#
option('gl', type : 'feature',
value : 'auto',
description : 'OpenGL integration library and OpenGL plugin'
)
option('gl-graphene', type : 'feature',
value : 'auto',
description : 'Use Graphene in OpenGL plugin'
)
option('gl-jpeg', type : 'feature',
value : 'auto',
description : 'Use libjpeg in OpenGL plugin'
)
option('gl-png', type : 'feature',
value : 'auto',
description : 'Use libpng in OpenGL plugin'
)
Now, with the available meson options, what I have (so far) specified for
the
updated build is
CONFIGURE_OPTIONS += -Dgl_api=opengl
CONFIGURE_OPTIONS += -Dgl_platform=glx,egl
CONFIGURE_OPTIONS += -Dgl_winsys=x11,egl
CONFIGURE_OPTIONS += -Dgl-graphene=disabled
With those options specified, the updated manifest isn't missing anything
that was present in the 1.16.2 component.
It seems like some new stuff is being added, though:
file path=usr/lib/pkgconfig/gstreamer-gl-1.0.pc
+file path=usr/lib/pkgconfig/gstreamer-gl-egl-1.0.pc
+file path=usr/lib/pkgconfig/gstreamer-gl-prototypes-1.0.pc
+file path=usr/lib/pkgconfig/gstream
Re: [oi-dev] what target creates $(WS_TOP)/archives ?
In regard to: Re: [oi-dev] what target creates $(WS_TOP)/archives ?,...: Perhaps if you try a oi-userland from a few weeks ago (or months) it can be reproduced that "gmake setup" used to create the archives directory. I just tried this myself and there is a difference but I incorrectly stated that 'gmake setup' was creating the archives directory. What seems to explain the difference (in the past the archives directory did not have to manually created) is that if I clone oi-userland it does not contain an archives directory any longer but it seems that if I checkout to a commit from a few weeks ago, there was an archives directory : Thanks David for testing this and confirming that it didn't need to be created formerly. It seems like creating it if it doesn't exist might be a useful addition to either 'setup' or 'env-prep' (or perhaps 'download'). Otherwise, if the user must do it manually when starting out with oi-userland, the step needs to be added to the documentation. 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
Re: [oi-dev] questions about updating security/pinentry
In regard to: Re: [oi-dev] questions about updating security/pinentry,...: On Sun, 26 Sept 2021 at 20:01, Tim Mooney via oi-dev wrote: Finally, the security/pinentry uses symlinks to default /usr/bin/pinentry to the pinentry-gtk2 backend. Is there a convenient method with IPS to make that selectable by the sysadmin installing the system? Something similar to how the system-default version of python or perl can be changed. I think for this part you probably want to look at IPS Mediators: https://man.omnios.org/man5/pkg.5#MEDIATIORS Thanks Joshua, that's exactly what I was looking for. I spent some time in the ips-dev-guide.pdf (http://docs.openindiana.org/dev/pdf/ips-dev-guide.pdf) last night but while facets, actuators, and variants are all described fairly close together in the manual, mediators are described in a later section, so I missed them. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] questions about updating security/pinentry
All- There's a recent release of the security/pinentry package, that's used by components of gnupg. There's nothing security related or pressing, but I would like to package the updated version for OI. I know the workflow for the update, but I have a couple of questions about options within the package itself. The current package disables building the pinentry backends for QT and FLTK, and I wouldn't change that. There's an optional pinentry-tty that I would like to enable and include, though. It's not built by default, but does build just fine on OI. It doesn't introduce any addition package dependencies. There's also a pinentry-gnome3 that will build on current OI. Should that be packaged too, or disabled like the pinentry-qt? This one very likely does introduce additional library dependencies for security/pinentry. Finally, the security/pinentry uses symlinks to default /usr/bin/pinentry to the pinentry-gtk2 backend. Is there a convenient method with IPS to make that selectable by the sysadmin installing the system? Something similar to how the system-default version of python or perl can be changed. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] PR #184: Support for epub and pandoc version problems
In regard to: Re: [oi-dev] PR #184: Support for epub and pandoc version...: Do you use Haskell for other projects? Even having someone that can reliably test an experimental package and offer feedback increases the likelihood of getting the package into a usable state. I'm afraid that I do not use Haskell and I would not have enough experience to install the Haskell Platform. That's fine, I was mainly wondering about testing, if someone else packaged it. Sorry Benny No worries, the contributions you've already made are quite helpful. Since we don't seem to have any Haskell experts in the audience and since pandoc is the first package that's called for Haskell, I'm not too eager to spend my time packaging Haskell. I have a backlog of other stuff that I would tackle first. pandoc does seem like a useful utility, though. 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
Re: [oi-dev] PR #184: Support for epub and pandoc version problems
In regard to: [oi-dev] PR #184: Support for epub and pandoc version...: We do not have a pandoc package for OI which would ease the problem. However, pandoc is big and it might not be trivial to create such a package for OI. Size isn't going to be the most difficult issue here. It appears that pandoc is written in Haskell and uses a Haskell-specific (?) build system. AFAICT, OI doesn't currently have a Haskell package. My experience with Haskell ends at the meme level. Speaking only for myself, while it is possible to build and package a language interpreter (or compiler) for a language I do not speak or use, it always makes the packaging process much more difficult. Do you use Haskell for other projects? Even having someone that can reliably test an experimental package and offer feedback increases the likelihood of getting the package into a usable state. 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
Re: [oi-dev] OI hipster text iso image
In regard to: Re: [oi-dev] OI hipster text iso image, Reginald Beardsley...: I'd like to test the ISOs for the next release. I have a system and disks for the task. If you want to get a jump on the process, you can start by building your own images. I wanted to do the same thing, hence my question to the mailing list a few weeks ago about distribution constructor. You can find the documentation for distribution-constructor at http://docs.openindiana.org/ in the Handbook -> Developer's Corner -> Using distribution constructor section. As the docs say, it is pretty straightforward. There are a few things that the docs don't cover, that someone new to the process (like I was) might wonder about. I plan to update the docs with this info, but for people new to the process: - by default, all the XML config files are configured to build an image with the latest packages published to the repo, so if you build an image you get the latest of everything (again, by default), *not* a copy of e.g. 2020.10. You *can* modify the config in the XML to lock incorporations at a particular version, if you want. - it fetches fresh packages from the openindiana.org publisher (it doesn't try use your locally-installed packages as a "cache"), so it requires several gigabytes of disk space and a lengthy download process. Depending on network bandwidth, it can take quite a while to download. On a related note, I don't think there is a (public) mirror of the openindiana.org publisher in North America. - it will create zfs mounts (by default) for its work and output area. 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
Re: [oi-dev] Latest ksh93 changes in illumos-gate have impacts on REQUIRED_PACKAGES
In regard to: Re: [oi-dev] Latest ksh93 changes in illumos-gate have...: On Sat, Mar 27, 2021 at 09:41:12AM +0100, Andreas Wacknitz wrote: illumos-gate has recently merged the following changes 2755 split ksh93 from core package 13460 ksh93 tests should be moved out of usr/demo 518 ksh documentation should be moved out of SUNWcsr This has impacts on our REQUIRED_PACKAGES settings for many packages. Most, if not all occurrences of REQUIRED_PACKAGES += SUNWcs need to be replaced by REQUIRED_PACKAGES += shell/ksh93 Is that really true? I would have thought that all products would require SUNWcs, but only ones that included ksh scripts would require shell/ksh93 . +1, I was trying to make the same point in the email I just sent. I don't think *any* SUNWcs should be replaced. I think shell/ksh93 should be *added* in some places. 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
Re: [oi-dev] openssl and gmake REQUIRED_PACKAGES
In regard to: [oi-dev] openssl and gmake REQUIRED_PACKAGES, s...@pandora.be...: There's one specific part of this I want to comment upon: How were the upgrades of openssl done in the past ? Isn't the easiest way to use the old strategy from the past to upgrade openssl, and then (without mediator I suppose) upgrade all packages to the new openssl ? No, the new strategy is (in my opinion) a huge improvement over the old strategy. Because of the huge list of packages that depend upon openssl, in the past when there was a breaking ABI change in openssl, the only way to upgrade was to undertake a massive effort to upgrade openssl + all dependencies at once. It was a huge barrier for all but the most experienced packagers. I looked at updating openssl last year and once I saw what was involved, I gave up and went on to other tasks. With the new mediator-based approach, it's much easier to upgrade dependencies in smaller chunks. It also puts us in a better place for when OpenSSL 3.0 is released, as packages can be migrated to that slowly over time while both 1.1.x and 3.0.x are supported. I hope that a few other libraries with huge dependencies (I'm looking at you, library/icu) can eventually be converted to the mediator approach. It makes it possible to move dependencies to a new version in phases, rather than having to do it all at once. I'm very thankful that Aurélien made this improvement to our openssl package. Tim -- 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
Re: [oi-dev] OpenSSL update process
In regard to: Re: [oi-dev] OpenSSL update process, Aurélien Larcher said...: If /usr/include/openssl does not point anywhere probably the mediator is not set to a right version or openssl-11 is not installed: narval> pkg mediator openssl 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 I've just updated my build box again and something is still not correct for me. $ pfexec pkg verify -v openssl-11 PACKAGE STATUS pkg://openindiana.org/library/security/openssl-11 OK $ pkg info library/security/openssl-11 Name: library/security/openssl-11 Summary: OpenSSL - a Toolkit for Transport Layer (TLS v1+) protocols and general purpose cryptographic library Category: System/Security State: Installed Publisher: openindiana.org Version: 1.1.1.9 Branch: 2020.0.1.0 Packaging Date: February 6, 2021 at 03:06:14 AM Last Install Time: February 6, 2021 at 10:56:16 PM Size: 10.75 MB FMRI: pkg://openindiana.org/library/security/openssl-11@1.1.1.9-2020.0.1.0:20210206T030614Z Source URL: http://www.openssl.org/source/openssl-1.1.1i.tar.gz Project URL: http://www.openssl.org/ $ pkg mediator openssl MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION openssl local 1.1 local system $ ls -alh /usr/include/openssl /usr/include/openssl: No such file or directory $ pkg contents openssl-11 | egrep 'include' | egrep -v '\.h$' usr/include/openssl I'm not sure why I'm not getting /usr/include/openssl, but it's not present. I've been considering that it may be a good idea to rebuild my build box anyway, I might try that in the next couple days. I was part way through building perl 5.30.1 and updating the perl modules when the pandemic lockdown started, so my build box is in a bit of a weird state for perl. I don't see how that would be causing problems for openssl, but a fresh build box wouldn't hurt. Tim -- 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
Re: [oi-dev] OpenSSL update process
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.3i-- 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___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OpenSSL update process
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. 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
Re: [oi-dev] CVE-2021-3156 seems relevant for OI
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 -- 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
Re: [oi-dev] Shipping the nano editor alongside with vi
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 wrote > > > On Sat, Jan 9, 2021 at 9:09 AM Hung Nguyen Gia via oi-dev 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 > ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev -- 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
Re: [oi-dev] Shipping the nano editor alongside with vi
In regard to: [oi-dev] Shipping the nano editor alongside with vi, Hung...: This should be done for none desktop OI flavors: OI text and OI minimal. Nano is already packaged for OI, though it may not be getting installed by default. It's a balancing act, to decide what to include with a default/minimal install, but nano is pretty small so I personally don't think it would be bad to add it to a minimal install. 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
Re: [oi-dev] No more notification pop-up for printing
In regard to: Re: [oi-dev] No more notification pop-up for printing, Gary...: On Mon, Nov 09, 2020 at 10:33:35AM -0600, Gary Mills wrote: I recently updated OI on one of my machines from the 2018-07-01 version to the 2020-08-02 version. After the update, I noticed that the notification pop-up for printing was no longer working. Mate's Notification Settings application does appear. I have not changed any of the settings. The Preview button does work and does produce a test pop-up. Printing from firefox, mutt, or lpr works, but with no notification pop-up. I got no responses to this message. Am I the odd one out? Does everybody else get pop-ups from CUPS? Maybe nobody gets them? I do get them from nwam, just not from printing. What's wrong? I was finally in my work office and tested this. I too do *not* get a popup notification when printing. I'm not sure when it changed, but it does appear that it's not currently working. Just as for you, printing works fine, it's just the notification that is now missing. I personally can live without the notification, but it is annoying to know that it used to work and now doesn't. 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
Re: [oi-dev] Python components
In regard to: [oi-dev] Python components, Nona Hansel said (at 5:59pm on...: I'm thinking about updating two Python packages - tqdm and colorama. Currently, there is variable PYTHON_VERSIONS= 3.5 in both Makefiles which means, if I understand it correctly, that the package is build for Python 3.5. Yes, and the implicit information you should take away from that is that those packages are *not* being built for the older Python 2.7. I wonder if I should let this variable like this or should I increase Python version. If so, to what version? Or should we have more versions at the same time? OI packages and provides multiple series of Python. You can have e.g. runtime/python-27 and runtime/python-35 installed at the same time, along with modules packaged for each. You should only increase PYTHON_VERSIONS *if* OI starts shipping a newer Python series. In that case, you would probably leave 3.5 there, but add the newer version too, so that these modules continue to be built for the 3.5 series, in addition to being built for the new series. As Andreas already said, it's a good idea to look at all the other python modules, to get an idea of which modules build for just a specific Python series and which build for any and all of the options that OI currently provides. 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
Re: [oi-dev] No more notification pop-up for printing
In regard to: Re: [oi-dev] No more notification pop-up for printing, Gary...: On Mon, Nov 09, 2020 at 10:33:35AM -0600, Gary Mills wrote: I recently updated OI on one of my machines from the 2018-07-01 version to the 2020-08-02 version. After the update, I noticed that the notification pop-up for printing was no longer working. Mate's Notification Settings application does appear. I have not changed any of the settings. The Preview button does work and does produce a test pop-up. Printing from firefox, mutt, or lpr works, but with no notification pop-up. I got no responses to this message. Am I the odd one out? Does everybody else get pop-ups from CUPS? Maybe nobody gets them? I do get them from nwam, just not from printing. What's wrong? My OI workstation is in my work office, and I've been working from home for the past few months, so I haven't had an opportunity to observe if the behavior has changed for me. I'll try remember to test next time I'm in my work office. 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
