Re: [oi-dev] phasing out openssl 1.0.2 (mostly)

[Alan Coopersmith]

On 2/24/24 10:23, Marcel Telka wrote:

in any case. probably more tricky is the system stuff like wpa.


The wpa package comes from illumos-gate.  I'm not sure if it supports
newer OpenSSL than 1.0 out of the box.  If not then it should be fixed
there.  If it does, then maybe we need to adjust our
components/openindiana/illumos-gate/Makefile somehow.  Again, see above
(sit down, etc.).


The WPA supplicant code in illumos is an ancient copy of the code originally
from https://w1.fi/wpa_supplicant/ and would be desperately in need of an
update if anyone cared about secure or modern Wifi authentication on illumos.

https://github.com/illumos/illumos-gate/tree/master/usr/src/cmd/cmd-inet/usr.lib/wpad
doesn't look like it's been updated to a new version since OpenSolaris,
which shipped version 0.2.5 - you can see how much has changed between
that and the latest 2.10 release at:
https://w1.fi/cgit/hostap/plain/wpa_supplicant/ChangeLog

You can see one of the more recent items in that ChangeLog is:
* added support for using OpenSSL 3.0

-alan-

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

Re: [oi-dev] phasing out openssl 1.0.2 (mostly)

[Alan Coopersmith]

On 2/24/24 09:27, Goetz T. Fischer wrote:

having a peek at other repos shows that e.g. the solaris userland has sort of a
compromise solution. they do set the ssl version explicitly. however, their
package names only contain the major version like "openssl-3" and the same goes
for the install paths like "/usr/openssl/3/". that's not as flexible as having
$(OPENSSL_INCDIR) and $(OPENSSL_LIBDIR) only or having it sorted by the
mediator but at least allows all 3.x versions without code changes.


Note that solaris-userland only supports 2 versions of openssl, 1.0.2 & 3.0.x,
due to the support lifetimes and FIPS-140 certifications.  (While OpenSSL now
promises that all later 3.x versions will be backwards compatible with 3.0,
they are also promising a longer support life for 3.0.x than 3.1.x or 3.2.x:
https://www.openssl.org/policies/releasestrat.html )

-alan-

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

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

[Alan Coopersmith]

On 2/20/24 12:28, Marcel Telka wrote:

Unfortunately, the verify will likely fail with the following error :-(:

# pkgrepo verify -s $PATHTOREPO/publisher/openindiana.org/
Initiating repository verification.
pkgrepo: The repository at '$PATHTOREPO/publisher/openindiana.org' is version 
'3'; only version 4 repositories are supported.
#


A version 4 repo is a container for multiple version 3 repos - that error
really means "you specified a version 3 repo that's inside a version 4
repo by going too far down the hierarchy" - just use $PATHTOREPO, not any
publisher subdirectory inside of it.

--
    -Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris


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

Re: [oi-dev] Memory use with Firefox

[Alan Coopersmith]

On 1/11/24 03:17, Matthew R. Trower wrote:
What's up with your Xorg, though?  2.5GB?  Your display server is nearly as fat 
as your Firefox :O


Xorg maps VRAM from your video card, so you need to use pmap on the process
to see how much is heap allocation (regular ram) vs. memory mappings.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris


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

Re: [oi-dev] Heads-Up: Obsoletion of 39 old packages

[Alan Coopersmith]

On 1/9/24 09:07, Marcel Telka wrote:

On Tue, Jan 09, 2024 at 08:41:14AM -0800, Alan Coopersmith wrote:

A few are open source - for instance, I could point you to the sources for
x11/network/x11-network-proxies - but no one uses that in a world where
ssh X11-Forwarding is prevalent, which is why I removed that package from
Solaris and declared the upstream sources unmaintained and suggested that
distros remove them.


Thanks for insights.  This caused I looked closer at x11/network/rstart
which is still required by mate_install and I noticed it is deprecated
too, so I created https://github.com/OpenIndiana/oi-userland/pull/15571 .


I don't know why it ever would have depended on rstart - an obscure method
to start X apps remotely in the days before ssh, but it shouldn't any more.

https://lore.kernel.org/distributions/1ea25603-171c-062e-bc02-bcdfc3acd...@oracle.com/T/#u
is the advice I gave distros last year on unmaintained packages from X.Org.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris


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

Re: [oi-dev] Heads-Up: Obsoletion of 39 old packages

[Alan Coopersmith]

On 1/9/24 07:24, Marcel Telka wrote:

All of them are:
- very old - they are more than 10 years old
- not maintained - we have no knowledge how to build them (there are no
   build recipes for them in oi-userland)


A fair number of them are actually impossible for you to maintain as we
never released the sources for them (things like the Solaris CDE & Motif
packages), and are likely just repackaging of the redistributable binaries
from OpenSolaris, complete with the bugs and security holes they had back
in 2010.

A few are open source - for instance, I could point you to the sources for
x11/network/x11-network-proxies - but no one uses that in a world where
ssh X11-Forwarding is prevalent, which is why I removed that package from
Solaris and declared the upstream sources unmaintained and suggested that
distros remove them.

--
    -Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris


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

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

[Alan Coopersmith]

Yes, the "bad" one is not antialiased, possibly a bitmap font,
while the "good" one is definitely antialiased, possibly TrueType or OpenType.

-alan-

On 11/21/23 07:25, Gordon Ross wrote:

Thanks.  I've confirmed that emacs is using the system font in both builds.
Here are two screen shots (bad, good) that one can zoom in.
The bad one has visible stair step diagonals etc. so I guess
the good one has "anti-aliasing" and the bad does not?
Does that clue help in tracking this down?

On Mon, Nov 20, 2023 at 2:20 PM Alan Coopersmith
 wrote:


GTK & Pango use fonts from fontconfig, not from X11, so it's not expected
to match xfontsel (which uses X11 fonts).  Among other things, Pango 1.44
dropped support for Type 1 & bitmap fonts, which X11/xfontsel still support,
leaving TrueType & OpenType font support.  One easy to spot difference,
fontconfig uses more natural names, like "DejaVu Sans Mono", while X11 uses
the older naming format with the 14 dashes separating fields.  Visually,
if the font is anti-aliased or LCD optimized, it must be fontconfig, as
the X11 font system doesn't support either technology.

https://www.x.org/releases/current/doc/xorg-docs/fonts/fonts.html
describes the difference (using "Xft" for the fontconfig system),
but it's about a decade behind the latest changes now.

 -alan-

On 11/20/23 11:10, Gordon Ross wrote:

As far as I can tell, the "system" font for mate terminal and such is:
"DejaVu Sans Mono", or
-misc-dejavu sans mono-medium-o-normal--0-0-0-0-p-0-ascii-0

Based on what I see with xfontsel, it looks like emacs may be using:
-misc-dejavu sans light-extralight-r-normal--0-0-0-0-p-0-ascii-0

I tried playing with the options/Set Default Font in emacs.
I'm not sure why, but emacs shows a lot less than xlsfonts does.

Here's what I have (from "save options") in both builds.
(custom-set-faces
   ;; custom-set-faces was added by Custom.
   ;; If you edit it by hand, you could mess it up, so be careful.
   ;; Your init file should contain only one such instance.
   ;; If there is more than one, they won't work right.
   '(default ((t (:family "DejaVu Sans Mono" :foundry "PfEd" :slant
normal :weight normal :width normal :height 113)

There seems to be a change in either the fonts or the rendering, from
the older OI build to recent ones.
The examples shown by "xfontsel" look too light in some cases too.
I'd appreciate tips on how to track down this problem.

Thanks

On Wed, Nov 8, 2023 at 4:27 PM Gary Mills  wrote:


On Wed, Nov 08, 2023 at 05:44:42PM +0100, Andreas Wacknitz wrote:


If you are using the gtk variant of emacs


That's the one I'm using.


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


There's no indication of truetype in the list of fonts that emacs
displays.  In fact, emacs will often tell me that a font does not
exist when I select that font from its list.


--
-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





--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris


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

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

[Alan Coopersmith]

GTK & Pango use fonts from fontconfig, not from X11, so it's not expected
to match xfontsel (which uses X11 fonts).  Among other things, Pango 1.44
dropped support for Type 1 & bitmap fonts, which X11/xfontsel still support,
leaving TrueType & OpenType font support.  One easy to spot difference,
fontconfig uses more natural names, like "DejaVu Sans Mono", while X11 uses
the older naming format with the 14 dashes separating fields.  Visually,
if the font is anti-aliased or LCD optimized, it must be fontconfig, as
the X11 font system doesn't support either technology.

https://www.x.org/releases/current/doc/xorg-docs/fonts/fonts.html
describes the difference (using "Xft" for the fontconfig system),
but it's about a decade behind the latest changes now.

-alan-

On 11/20/23 11:10, Gordon Ross wrote:

As far as I can tell, the "system" font for mate terminal and such is:
"DejaVu Sans Mono", or
-misc-dejavu sans mono-medium-o-normal--0-0-0-0-p-0-ascii-0

Based on what I see with xfontsel, it looks like emacs may be using:
-misc-dejavu sans light-extralight-r-normal--0-0-0-0-p-0-ascii-0

I tried playing with the options/Set Default Font in emacs.
I'm not sure why, but emacs shows a lot less than xlsfonts does.

Here's what I have (from "save options") in both builds.
(custom-set-faces
  ;; custom-set-faces was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
  '(default ((t (:family "DejaVu Sans Mono" :foundry "PfEd" :slant
normal :weight normal :width normal :height 113)

There seems to be a change in either the fonts or the rendering, from
the older OI build to recent ones.
The examples shown by "xfontsel" look too light in some cases too.
I'd appreciate tips on how to track down this problem.

Thanks

On Wed, Nov 8, 2023 at 4:27 PM Gary Mills  wrote:


On Wed, Nov 08, 2023 at 05:44:42PM +0100, Andreas Wacknitz wrote:


If you are using the gtk variant of emacs


That's the one I'm using.


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


There's no indication of truetype in the list of fonts that emacs
displays.  In fact, emacs will often tell me that a font does not
exist when I select that font from its list.


--
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-

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


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




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

Re: [oi-dev] rebuilding system/xvm/xvmstore ?

[Alan Coopersmith]

On 10/19/23 11:35, Marcel Telka wrote:

On Thu, Oct 19, 2023 at 01:27:31PM -0500, Tim Mooney via oi-dev wrote:

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.


We do not have a recipe for this component in oi-userland.  So it needs
to be created from scratch (or the package should be obsoleted if we no
longer need it).


The source code was in the xvm gate, used for Sun's Xen port for OpenSolaris.
I don't know if anyone kept a copy of that gate around - I don't see it on
https://hg.openindiana.org/ .

The package was created by converting the SVR4 package created from that gate
to IPS using the old distro-import tool:
https://github.com/oracle/solaris-ips/blob/40deb36077c33ef6717ef5ddaf3b895e8b2ec1fd/src/util/distro-import/133/i386/system%3Axvm%3Axvmstore

I suspect it should just be obsoleted/removed now if you're not running the
Xen hypervisor from xVM, along with any other system/xvm/* packages.

-alan-

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

Re: [oi-dev] libpulsecore error

[Alan Coopersmith]

On 3/9/23 16:55, Gary Mills wrote:

The method script, /lib/svc/method/gconf-cache, seems correct.  It,
however, invokes a python3.5 script,
/usr/share/desktop-cache/find_newer, that fails on newly-installed
systems.  The error message that I got, normally not seen, is:

 Traceback (most recent call last):
   File "/usr/share/desktop-cache/find_newer", line 149, in 
 sys.exit(main())
   File "/usr/share/desktop-cache/find_newer", line 123, in main
 os.stat_float_times (True)
 AttributeError: module 'os' has no attribute 'stat_float_times'

This script should, as a minimum, be converted to use a modern version
of python.  I better fix would be to modify the method script so that
it never needed to invoke the python script.  Both scripts are part of
illumos, I assume.


No - they're part of oi-userland, via an ancient tarball from the old
OpenSolaris JDS consolidation:

https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/desktop/desktop-cache/desktop-cache.p5m
https://github.com/OpenIndiana/oi-userland/blob/7c1cd7a0dd77ba0db18bb7b513ba643de6349451/components/desktop/desktop-cache/patches/01-python.patch

Both Tribblix & Solaris got rid of find_newer:

https://ptribble.blogspot.com/2016/08/updating-desktop-caches-and-tale-of-woe.html
https://github.com/oracle/solaris-userland/commit/ba967091f5e75913a3a273291882008516c0a239

In Solaris, I also got rid of the separate desktop-cache package and moved
the various SMF scripts into the packages for the libraries that build & use
them:
https://github.com/oracle/solaris-userland/commit/9f1a882f986b35fb81575a6ec3ec674697739cd0

-alan-


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

Re: [oi-dev] hald glib https://www.illumos.org/issues/14226

[Alan Coopersmith]

On 9/28/22 10:03, Carsten Grzemba via oi-dev wrote:
I added some findings to the issue related hald and newer glib versions. hald do 
not not work  with newer glib versions than 2.63.4. because there is a change in 
g_io_channel_read_line which handles the output of the function differently if 
the string contains null character. The change seems reasonable for me. 
(https://gitlab.gnome.org/GNOME/glib/-/issues/2002 
)
But remains the question what special line/string receives 
g_io_channel_read_line for hald here and how should this handled in hald. Or 
should a better string send by DBUS (or whoever).


Does https://gitlab.freedesktop.org/alanc/hal/-/commit/8865b8583d96587c9bd
help here?

-alan-

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

Re: [oi-dev] problems publishing rust

[Alan Coopersmith]

On 6/24/22 09:19, Friedrich Kink via oi-dev wrote:

I'm making progress ;-). The only remaining problems I still have are:

builduser@userland:/usr/src/myoi-userland/components/developer/rust$ make 
REQUIRED_PACKAGES


/usr/bin/python3.9 RESOLVE_DEPS= 
/usr/src/myoi-userland/components/developer/rust/build/.resolved-i386
/usr/bin/python3.9: can't open file 
'/usr/share/src/myoi-userland/components/developer/rust/RESOLVE_DEPS=': [Errno 
2] No such file or directory
make: *** [/usr/share/src/myoi-userland/make-rules/ips.mk:516: 
REQUIRED_PACKAGES] Error 2



builduser@userland:/usr/src/myoi-userland/components/developer/rust$ make 
publish
/usr/bin/pkgdepend resolve -e 
/usr/src/myoi-userland/components/developer/rust/build/resolve.deps -m 
/usr/src/myoi-userland/components/developer/rust/build/manifest-i386-rustc.depend
/usr/src/myoi-userland/components/developer/rust/build/manifest-i386-rustc.depend has 
unresolved dependency '

     depend type=require fmri=__TBD pkg.debug.depend.file=libLLVM-13.so \
pkg.debug.depend.reason=usr/lib/librustc_driver-3267f80155f8cead.so \
     pkg.debug.depend.type=elf \
     pkg.debug.depend.path=lib/64 \
     pkg.debug.depend.path=usr/gcc/7/lib/amd64 \
     pkg.debug.depend.path=usr/lib \
     pkg.debug.depend.path=usr/lib/64'.
make: *** [/usr/share/src/myoi-userland/make-rules/ips.mk:503: 
/usr/src/myoi-userland/components/developer/rust/build/.resolved-i386] Error 1

builduser@userland:/usr/src/myoi-userland/components/developer/rust$


What that's telling you is that it can't find which IPS package to list
for the dependency on libLLVM-13.so - most commonly this means a missing
entry in the REQUIRED_PACKAGES list in the Userland Makefile - which the
first command should have resolved, but it seems to have failed for a
reason I don't recognize.  (It looks like it's missing the path to the
script to run, and I don't know why that would happen.)

-alan-


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

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

[Alan Coopersmith]

On 4/8/22 16:27, Alan Coopersmith wrote:

Something that one of our engineers has recently discovered while
looking into a different HAL issue (problems with the power button
signalling) is that HAL appears to include a NULL byte at the end
of the messages it sends, which g_utf8_get_char_validated() rejects
now, due to:

https://gitlab.gnome.org/GNOME/glib/-/commit/568720006cd1da3390c239915337ed0a56a23f2e 


https://gitlab.gnome.org/GNOME/glib/-/issues/1052

which appears to cause g_io_channel_fill_buffer() to read the message
from the pipe, but then not process it.


The fix that engineer came up with is now visible at:
https://gitlab.freedesktop.org/alanc/hal/-/commit/8865b8583d96587c9bd2f80b51996b7b0e5681bd

which only covers half of what Gary had suggested in the illumos bug:
https://www.illumos.org/issues/14227

but as noted above, they were chasing different symptoms.

-alan-

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

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

[Alan Coopersmith]

Something that one of our engineers has recently discovered while
looking into a different HAL issue (problems with the power button
signalling) is that HAL appears to include a NULL byte at the end
of the messages it sends, which g_utf8_get_char_validated() rejects
now, due to:

https://gitlab.gnome.org/GNOME/glib/-/commit/568720006cd1da3390c239915337ed0a56a23f2e
https://gitlab.gnome.org/GNOME/glib/-/issues/1052

which appears to cause g_io_channel_fill_buffer() to read the message
from the pipe, but then not process it.

-alan-

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

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

[Alan Coopersmith]

On 3/24/22 17:27, Richard Lowe wrote:

IPS (used to?) depend on this, and has lingering references to xml2po too.


It was used by the pkg GUI, and if you drop the pkg GUI as Solaris has,
you can drop gnome-doc-utils & xml2po references from IPS as well:

https://github.com/oracle/solaris-ips/commit/958f0ed9730c25a37743ec7ff17e6ab3f7b4145a

There are still some lingering Python 2.7 references in the rest of IPS
though, such as

https://github.com/oracle/solaris-ips/blob/d78e24b1e6b54372abc00165bf2b0199517c08b6/src/tests/api/t_dependencies.py

--
    -Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris

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

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

[Alan Coopersmith]

On 3/24/22 08:51, Gary Mills wrote:

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

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

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

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


Since gnome-doc-utils is not used with GNOME 3 or later, upstream has
ended development and archived the project:
https://gitlab.gnome.org/Archive/gnome-doc-utils
so no amount of waiting will ever get it ported to Python 3 by them.

Does mate still need these tools or have they moved on to something else?

-alan-

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

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

[Alan Coopersmith]

On 3/23/22 07:57, Gary Mills wrote:

On Wed, Mar 23, 2022 at 11:48:25AM +0100, Andreas Wacknitz wrote:

Solaris-userland is
at glib-2.70 so they seem to have fixed either hal or glib.


I wonder what they fixed.  It would be done with a patch, most likely.


You can see the patches we apply to glib, but none of them jump out at
me as related here:

https://github.com/oracle/solaris-userland/tree/master/components/gnome/glib2/patches

-alan-

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

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

[Alan Coopersmith]

On 3/23/22 03:48, Andreas Wacknitz wrote:

Am 22.03.22 um 22:41 schrieb Gary Mills:

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

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

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


I don't remember what issue you're discussing here, but we did apply a
simple fix to Solaris HAL to make hal-storage-mount work with newer glib
releases a while back:

https://gitlab.freedesktop.org/alanc/hal/-/commit/8953bfd08e6119368152ded0aa4d355a7609de93

But it looks like that was needed for glib 2.55.0 and later, so may be
a different issue than you're hitting now.

The only other USB device mounting bug I see us fixing in hal since then
was to workaround an issue in the Studio 12.6 compiler, which you wouldn't
be using:

https://gitlab.freedesktop.org/alanc/hal/-/commit/a3e3d718f64be8f9477019d48267001c7b91a4cd

but you can look through the list of our changes at
https://gitlab.freedesktop.org/alanc/hal/-/commits/solaris
to see if there's something I didn't notice that would help you.

You can also grab the FOSS source code from our recent CBE build release at
https://www.oracle.com/downloads/opensource/solaris-source-code-downloads.html
but that's a large download since it includes all the upstream sources for
our solaris-userland as well as the FOSS code from our ON gate that's required
to be released under the terms of its licenses.

-alan-

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

Re: [oi-dev] meld and gmake REQUIRED_PACKAGES

[Alan Coopersmith]

On 1/4/22 4:27 AM, Nona Hansel wrote:
Such errors are always hard for me to understand. Isn't it weird that it's 
looking for .pyc files which aren't part of either manifests/sample-manifest.p5m 
nor meld.p5m? Everywhere I only have.py files.


The build system is being helpful and automatically adding the compiled
.pyc file for every .py file listed in the manifest:

https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/transforms/autopy

When I check the build directory, I can see that the program installed into 
build/prototype/i386/usr/ not into build/prototype/i386/mangled like gmake is 
looking for. Is there a way to fix it?


It's doing the right thing - mangled is only for files mangled by the
userland-mangler build tool. The rest should be under build/prototype/i386
as you have (note that it's looking for usr/... as the path under there).

You might look at what the Solaris build of meld does - but it's still using
Python 3.7 (I think just because it was updated before there were 3.9 versions
of all the dependencies available in Solaris):

https://github.com/oracle/solaris-userland/blob/master/components/gnome/meld/Makefile

-alan-

___
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

[Alan Coopersmith]

On 12/22/21 4:40 PM, Gary Mills wrote:

On Wed, Dec 22, 2021 at 08:27:49PM -0300, Till Wegmueller wrote:


Can we have that Patch?


I don't have a patch for ninja.  I meant that it would be easy to
develop a patch for ninja.  All you have to do is to search the
source for _FILE_OFFSET_BITS and write a patch to delete that line.


I think you mean meson (which generates the build files used by ninja),
rather than ninja itself:
https://github.com/mesonbuild/meson/issues/1032


What I actually did for glib was to write a shell wrapper that deleted
that operand and value from the compiler command-line, and then
invoked the compiler.  That allowed me to build glib.


It looks like we took a different approach and disabled libelf in 32-bit
builds to get around this - but then we build our whole desktop as 64-bit
now, so I'm not sure if we have any programs left using 32-bit glib:

https://github.com/oracle/solaris-userland/blob/master/components/gnome/glib2/patches/17-large-file-support.patch

-alan-

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

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

[Alan Coopersmith]

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

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


Python upstream ended 3.5 support a year ago:
https://devguide.python.org/devcycle/#end-of-life-branches

Currently supported branches are listed at:
https://devguide.python.org/#status-of-python-branches


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


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


but also on
two other python libraries: pygobject-27 and pygtk2-27 .  Both of
those libraries do not have python 3.7 or 3.9 versions.


PyGObject 3.x definitely supports Python 3 - we ship that in Solaris:
https://github.com/oracle/solaris-userland/tree/master/components/gnome/pygobject3

Pygtk2 does not - it's limited to the deprecated gtk2 and obsolete Python 2,
and as you discovered, the replacement path for it is PyGObject.


As far as I can tell, OI uses both gtk+ and gtk+3 libraries.  Is this
correct? 


Not everything has finished porting from GTK+2 to GTK+3 yet, and now
the GTK maintainers have released GTK+4 and moved GTK+3 to the deprecated
(but not yet totally unsupported) list alongside GTK+2.

-alan-

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

Re: [oi-dev] gstreamer1 and OpenGL/EGL

[Alan Coopersmith]

On 10/27/21 2:50 PM, Gary Mills wrote:

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.


Meson has been working pretty well for us for building GNOME & X.Org
packages on Solaris 11.4, though admittedly we are phasing out 32-bit
builds and do carry an extra patch we've never upstreamed to help with
things:

https://github.com/oracle/solaris-userland/blob/master/components/python/meson/patches/013-environment.patch

--
    -Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc

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

Re: [oi-dev] Numpy - upgrade for Python 3.X

[Alan Coopersmith]

On 7/16/21 5:07 AM, Nona Hansel wrote:

Thank you for your insights. Any tips about this upgrade would be much 
appreciated.


You can look at
 https://github.com/oracle/solaris-userland/tree/master/components/python/numpy

as an example, though it's a more complicated Makefile as it builds numpy 1.19.0
for Python 3.7, and 1.14.2 for Python 2.7.

-alan-

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

Re: [oi-dev] Something wrong with dependancies

[Alan Coopersmith]

On 7/10/21 4:59 PM, Gary Mills wrote:

I'm trying to build a library that uses only python-3.9 .  For its
tests, it requires pytest-3.9 .  I noticed that OI has the pytest-39
package, and it includes that executable.  However, when I tried to
install that package, I got 30 packages.  What's going on?  Something
must be broken with dependancies to get that many packages.  Here's a
transcript of what I got:



   library/python/py
 None -> 1.8.2-2020.0.1.0
   library/python/py-27
 None -> 1.8.2-2020.0.1.0
   library/python/py-35
 None -> 1.8.2-2020.0.1.0
   library/python/py-37
 None -> 1.8.2-2020.0.1.0
   library/python/py-39
 None -> 1.8.2-2020.0.1.0


A lot of it comes from the python package setup assuming that if you want
a module like this, you want it installed for all the versions of Python
you have, instead of just giving you the module for one version and then
having things break when whatever else depends on it moves to a later version.

This may not be what you wanted, but would be a difference of opinion, not
a bug.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc

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

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

[Alan Coopersmith]

On 6/30/21 6:46 PM, Gary Mills wrote:

On Mon, Jun 28, 2021 at 02:55:21PM -0700, Alan Coopersmith wrote:

On 6/28/21 12:52 PM, Gary Mills wrote:

I don't know yet if the glib developers have
dropped support for solaris or illumos.


I've not seen any such moves by them, and have gotten Solaris-specific
pull requests accepted in recent years.


Okay thanks.  I'll drop that idea from my list of known unknowns,
and look elsewhere.


They don't regularly test on Solaris though, and could easily have missed
adding something we need, or broken something on our platforms without
realizing it, so those are still possibilities.

Breaking something HAL relies on is also a possibility, as outside the
world of Solaris/illumos, HAL has been abandoned, deprecated, and removed
for almost a decade as noted by the first line on:
https://www.freedesktop.org/wiki/Software/hal/
and the last commit dates in:
https://gitlab.freedesktop.org/archived-projects/hal/hal/-/commits/master

For whatever it's worth, the Solaris patches to HAL are available at:
https://gitlab.freedesktop.org/alanc/hal/-/commits/solaris
as we've still not replaced it either.

-alan-

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

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

[Alan Coopersmith]

On 6/28/21 12:52 PM, Gary Mills wrote:

I don't know yet if the glib developers have
dropped support for solaris or illumos.


I've not seen any such moves by them, and have gotten Solaris-specific
pull requests accepted in recent years.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc

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

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

[Alan Coopersmith]

On 6/6/21 10:30 AM, Gary Mills wrote:

As far as I can tell, "dbus" sends messages to "hal" about the state
of devices on the system.  However, for insertion of USB sticks, this
does not happen.  I don't know why it doesn't happen.


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

-alan-

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

Re: [oi-dev] Virtual address space and Firefox

[Alan Coopersmith]

On 3/12/21 11:58 PM, Carsten Grzemba via oi-dev wrote:
It seems that this are raised by MOZ_ASSERTION because the JS-engine 
(spidermonkey) expects that  addresses for JS Values are not in the upper memory 
area:


ptr must be a valid user-mode pointer, with the top 16 bits clear


Yes - spidermonkey expects to be able to store its own data in the top bits of
the pointer, which has known issues on Solarish kernels:
https://bugzilla.mozilla.org/show_bug.cgi?id=577056

You can read more about what spidermonkey is doing at:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals#javascript_values
https://doar-e.github.io/blog/2018/11/19/introduction-to-spidermonkey-exploitation/#jsvalues-and-jsobjects

In solaris-userland Oracle has placed a patch but only for Sparc: 
sparc-47bit-VA-space.patch

This use a mapfile with
RESERVE_SEGMENT spidermonkey_reserve {
   VADDR = 0x8000;
   SIZE = 0x7fff;
};
Illumos ld don't know the option RESERVE_SEGMENT, but it is for Sparc how I 
already stated.


This is the second version of the mapfile we've used - the first was:
CAPABILITY {
SF += ADDR32;
};
but that limits a 64-bit program to a 32-bit address space, and Firefox really
needs more than 4gb of address space these days, so we had to find a better
solution.

Fortunately, we already had added RESERVE_SEGMENT to the mapfile syntax and
ELF program headers to block out a part of the address space, and ensure that
the system wouldn't map anything in that range, even if ASLR happened to
randomly pick an address there, so we used that instead:
https://blogs.oracle.com/solaris/virtual-address-reservation-in-solaris-113-v2
https://docs.oracle.com/cd/E37838_01/html/E36783/gjpky.html#OSLLGgjpte

Do IllumOS use the whole 64bit address space and not only the expected 47bit? Or 
I am completly wrong here in the maze of physical and virtual address spaces?


The address model is different than Linux - it's effectively just 47 bits, but
they're in different subsets of the 64-bit address space than Linux uses.

To quote from one of the engineers who worked on this:
"On x86-64 they rely on the fact that Mac OS X, Windows and Linux all put the
userspace/kernelspace boundary at the VA hole. In Solaris, instead, we still
dynamically restrict it to some arbitrary (depending on amount of memory and
other factors) boundary line above the VA hole."
Another engineer just pointed to:
https://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details

This led to a workaround of putting this line in /etc/system:
set _userlimit=0x7fffc000
until the RESERVE_SEGMENT change was available.

But then we also changed the x86 kernel in Solaris 11.4 to make that the default
userlimit on x86 systems, making us match the other OS'es and no longer need to
do anything special to deal with this on x86 systems, only SPARC.

You can see this change in the address space layout diagrams for the AMD64 ABI
between the 11.3 & 11.4 docs:
https://docs.oracle.com/cd/E53394_01/html/E61689/fcowb.html#SSFDGfcpaf
https://docs.oracle.com/cd/E37838_01/html/E66175/fcowb.html#SSFDGfcpaf

-alan-

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

Re: [oi-dev] Porting of the Epiphany Browser

[Alan Coopersmith]

On 1/9/21 11:03 AM, Vincent Torri wrote:

On Sat, Jan 9, 2021 at 8:00 PM Alan Coopersmith
 wrote:

I can say that libdazzle builds on Solaris, but we apply this patch to
make it build:

https://github.com/oracle/solaris-userland/blob/master/components/gnome/libdazzle/patches/link.patch


why not doing a PR to fix upstream the compilation problem ?


I don't know why she didn't - we usually try to mention in our patch comments
if we're submitting upstream, and if not, why not.  (Sometimes it's because
we don't know how to fix it for us without breaking other platforms, sometimes
because it's a self-inflicted problem that no one else will hit, and sometimes
just because we haven't had time to do it yet.)

-alan-

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

Re: [oi-dev] Tasks to focus on

[Alan Coopersmith]

On 1/7/21 1:39 PM, Aurélien Larcher wrote:

since I have now more or less recovered from Covid I can be active to some 
extent.


Glad you are doing better.

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=commits


- providing Python 3.8 and 3.9.


https://github.com/oracle/solaris-userland/search?q=python+3.9=commits


- migrating pkg5 to Python 3.7.


https://github.com/oracle/solaris-ips/search?q=%22python+3.7%22=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


-alan-

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

Re: [oi-dev] Error from the vesa driver (Was: libdrm-2.4.75 is too old)

[Alan Coopersmith]

On 6/5/20 5:19 PM, Gary Mills wrote:

With a bit more experimentation, I discovered that I only get the
error from the vesa driver when I boot the USB image in UEFI mode with
CSM disabled.


That's what I'd expect, as the vesa driver requires legacy BIOS support,
and a pure UEFI environment doesn't support VESA graphics, but instead
requires generic video access to use UEFI's Graphics Output Protocol.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc

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

Re: [oi-dev] pkglint fails during publish

[Alan Coopersmith]

On 5/9/20 1:03 PM, Gary Mills wrote:

On Sat, May 09, 2020 at 03:03:57PM +, Andy Fiddaman wrote:

On Sat, 9 May 2020, Gary Mills wrote:

; That's the change that caused the problem.  The first line becomes
; only a comment when the file is interpreted by python.  Removing that
; option string would solve the problem in a simpler way.  I wonder why
; it was ever put there?  I see that it was added to all of the pkg
; scripts.  I wonder why?

The associated commit message is:

   29453498 pkg should ignore Python ENV and not import from site-packages

so presumably for a more consistent environment when running pkg tools.


So, that's it.  Thanks for the information.  I understand also that
the pkg tools are part of a separate consolidation, neither OI nor
illumos.

In OI, we have an example of the breakage caused by this change,
although it's only in the pkglint command.  The pkglint man page says:

-f config_file

Configure the pkglint session using the config_file configuration
file.
and:

pkglint.ext.*

The plugin mechanism of pkglint allows for additional lint modules
to be added at runtime. Any key that starts with pkglint.ext. takes
a value that must be a fully-specified Python module. See the
"Developers" section for more information.

Is there any way in the pkglint rc file to specify the location of the
additional module?  What is a fully-specified Python module anyway?
I'm not familiar with Python.


Upstream IPS fixed this by adding the -e flag to pkglint, so that consumers like
ON/illumos could just do:

PKGLINT=   /usr/bin/pkglint -e $(ONBLD_TOOLS)/lib/python

https://github.com/oracle/solaris-ips/commit/b1d64c287c4346d2c5be5fe4cee278914ea86042

As a temporary workaround without that IPS comment, they could do something
like:

PKGLINT=PYTHONPATH=$(PYTHONPATH):$(ONBLD_TOOLS)/lib/python \
/usr/bin/64/python2.7 /usr/bin/pkglint

(Substitute python path as appropriate for the version of Python used in your
 IPS builds.)

-alan-

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

Re: [oi-dev] Binary-only packages

[Alan Coopersmith]

On 3/29/20 7:12 AM, Alexander Pyhalov via oi-dev wrote:

> cde/calendar-manager-server   0.5.11-2013.0.0.0  
> i--
> cde/cde-runtime   0.5.11-2013.0.0.0  
> i--
> cde/cde-utilities 0.5.11-2013.0.0.0  
> i--
> cde/help-viewer   0.5.11-2013.0.0.0  
> i--
> consolidation/cde/cde-incorporation   0.5.11-2013.0.0.0  
> i--> library/motif 0.5.11-2013.0.0.0  
> i--
> library/tooltalk  0.5.11-2013.0.0.0  
> i--

The existing versions are binary only drops from Sun - we've obsoleted them in
11.4, but ptribble has built CDE for illumos from the open source release 
(which 
is version 2.x, while Solaris never went past version 1.x of CDE).

> library/desktop/gtk1  1.2.10-2013.0.0.0  
> i--
> library/glib1 1.2.10-2013.0.0.0  
> i--

Does anything still need those?  Last consumer I remember was Netscape.

> library/medialib  0.5.11-2013.0.0.0  
> i--

This was probably a binary drop from Sun - there's a link to a source drop on
https://en.wikipedia.org/wiki/MediaLib but the hardware acceleration in it is
going to be over a decade out of date now.

> library/motif/libdpstkxm  0.5.11-2013.0.0.0  
> i--

Might as well obsolete this - it was a connector between DPS and Motif, and DPS
is gone now.  (For sources, see the DPS library source link below.)

> system/font/truetype/arabeyes 0.5.11-2013.0.0.0  
> i--
> system/font/truetype/bpg-georgian 0.5.11-2013.0.0.0  
> i--
> system/font/truetype/indic-fonts-core 0.5.11-2013.0.0.0  
> i--
> system/font/truetype/ipafont  0.5.11-2013.0.0.0  
> i--
> system/font/truetype/ipafont-mincho   0.5.11-2013.0.0.0  
> i--
> system/font/truetype/kacst0.5.11-2013.0.0.0  
> i--
> system/font/truetype/lohit0.5.11-2013.0.0.0  
> i--
> system/font/truetype/mgopen   0.5.11-2013.0.0.0  
> i--
> system/font/truetype/sil  0.5.11-2013.0.0.0  
> i--
> system/font/truetype/thai-scalable0.5.11-2013.0.0.0  
> i--
> system/font/truetype/unifont  0.5.11-2013.0.0.0  
> i--

You can find our build recipes for all these under
https://github.com/oracle/solaris-userland/tree/master/components/fonts

> system/font/truetype/hanyang-ko   0.5.11-2013.0.0.0  
> i--
> system/font/truetype/hanyang-ko-core  0.5.11-2013.0.0.0  
> i--

These unfortunately are in our closed source tree,  so what you have probably
came from an old binary drop.

> system/kernel/hardware-cursor 0.5.11-2013.0.0.0  
> i--

This is only useful if you're running a Xsun on a SPARC, but the source was
available:
https://github.com/oracle/solaris-xorg/commit/fe7f7f509e149d1eaa5ed40fd24116f96f9b3bda

> system/library/liblayout  0.5.11-2013.0.0.0  
> i--
> text/auto_ef  0.5.11-2013.0.0.0  
> i--

That should have been in the old OpenSolaris G11N consolidation.


> system/management/cim/pegasus 2.8.0-2013.0.0.0   
> i--
> system/management/wbem/cimple 1.2.4-2013.0.0.0   
> i--
> system/management/wbem/sblim-cim-client   1.6.0-2013.0.0.0   
> i--
> system/management/wbem/wbemcli1.3.7-2013.0.0.0   
> i--
> terminal/conman   0.2.4.1-2013.0.0.0 
> i--

I think these were in the desktop consolidation, but with both java.net and
hg.openindiana.org gone now, I don't know where you find that source.

> x11/library/dps   7.5-2013.0.0.0 
> i--
> x11/library/libowconfig   0.5.11-2013.0.0.0  
> i--

These are also pretty useless without Xsun, but did have sources published:

https://github.com/oracle/solaris-xorg/commit/668ffa408af6c8be9000a7e841c3b34c1900f49e
https://github.com/oracle/solaris-xorg/commit/ecb865891b0685db5dc9d000e978242a2873ea67

> x11/network/rstart1.0.3-2013.0.0.0   
> i--
> x11/network/x11-network-proxies   7.5-2013.0.0.0 
> i--

Use ssh instead of these now that we're no longer living in the 1990's.
https://github.co

Re: [oi-dev] Where should SPARC go?

[Alan Coopersmith]

On 11/18/19 8:44 AM, ken mays via oi-dev wrote:
3. Packages built on your distro working elsewhere (i.e. DilOS, Tribblix, 
OpenSXCE, S11.x SPARC) and/or pre-existing SPARC packages

working on your distro.


Solaris 11.x & illumos are not 100% binary compatible with each other.
They maintain backwards compatibility with their common Solaris 10
heritage (but only for Solaris 10 versions from before 2010, not
necessarily with later additions to Solaris 10 after that), but since
the Solaris/illumos split each has added their own set of extensions,
and use of those may not work on the other.

-alan-


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

Re: [oi-dev] I figured out exactly why Firefox and its forks can't link libxul.so with illumos LD.

[Alan Coopersmith]

On 8/19/19 4:17 AM, Jeremy Andrews wrote:

He provides two important pieces of information here. One is that GCC
doesn't output the symbols that the Sun linker requires to do to the
proper relocation of STABs in ELF format. The other is that on Solaris,
people have been known to use a zero value to get the address from ELF
symbols. And if you look at this official Solaris Firefox repository,
you'll see they have this:

https://github.com/oracle/solaris-userland/blob/82dd4adb0eca729372074d62435e00a783d95b1f/components/desktop/firefox/patches/firefox-41-static-xul-components.patch


That's from the Firefox 38 set of patches.   I passed this note on to
the maintainer of those for Solaris, and he pointed out the patch is
gone in Firefox 60 and later, due to this upstream fix instead:

https://hg.mozilla.org/mozilla-central/rev/3fd81dad7c8b

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc

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

Re: [oi-dev] fmemopen not found for compiling samba-4.10.0

[Alan Coopersmith]

On 3/21/19 2:29 AM, Joerg Schilling wrote:

Till Wegmüller  wrote:


Hi

fmemopen Seems to be only from the newest iteration of the Posix
Standard. We do not support that yet.


It is part of the standard since > 10 years. This standard is so old that we
have been in risk of being kicked out of IEEE because there is no new major
revision of the standard since 10 years.


And it took 10 years before any OS certified compliance to that new version
of the standard, with Solaris 11.4 being the only OS to ever do so.

Realistically, GNU libc defines the set of libc API's that software expects
today much more than POSIX does.


It would be of interest whether Oracle has it now


Yes: https://docs.oracle.com/cd/E88353_01/html/E37843/fmemopen-3c.html

--
    -Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc

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

Re: [oi-dev] Packages only in the main repository

[Alan Coopersmith]

On 10/25/18 09:31 AM, Aurélien Larcher wrote:

Would you recommend still providing binaries for Motif and the old Athena 
Widgets?


I don't know of anything that still needs the old Athena Widgets.

There is some commercial software (Oracle 11g, JDK 1.5 & before, FileMerge,
etc.) that still needs the Motif Widgets, so you may want to keep them.

-alan-

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

Re: [oi-dev] Packages only in the main repository

[Alan Coopersmith]

In addition to the ones I mentioned in the other mail, here's some
notes on the rest:

On 10/24/18 05:39 AM, Aurélien Larcher wrote:

Hi,
this list contains packages installed on my system that cannot be published from 
oi-userland:


developer/macro/cpp

> system/library/c++/sunpro

These would have been in the devpro consolidation in OpenSolaris.


driver/network/ce


This was the Cassini Ethernet driver for old SPARC systems, I don't
remember if source ever got published.


library/desktop/gtk1
library/glib1


These versions have been deprecated for almost two decades now.
The last thing I remember using them was the old Netscape browser,
prior to the move to Mozilla.


library/medialib


Source was available once upon a time:
https://en.wikipedia.org/wiki/MediaLib


system/font/truetype/arphic-uming


https://github.com/oracle/solaris-userland/tree/master/components/fonts/arphic-uming


system/font/truetype/hanyang-ko-core


This is currently marked as closed source unfortunately.


system/font/truetype/ipafont


https://github.com/oracle/solaris-userland/tree/master/components/fonts/ipafont


system/font/truetype/lohit


https://github.com/oracle/solaris-userland/tree/master/components/fonts/lohit


system/font/xorg/iso8859-1
system/font/xorg/xorg-core


https://github.com/oracle/solaris-userland/tree/master/components/x11/font/xorg-core


x11/compatibility/links-svid


https://github.com/oracle/solaris-userland/blob/master/components/x11/lib/libX11/links-svid.p5m


x11/library/dps
x11/library/libowconfig
x11/library/toolkit/libxaw4
x11/library/toolkit/libxaw5
x11/network/rstart


We obsoleted all these in Solaris 11.4 - you could find sources in the
history of the solaris-xorg gate if you really wanted them, but you
probably don't unless you know of specific old Solaris binaries you
want to provide binary compatibility for (like JDK 1.0 for instance).

Alternatively you can find the history entries to obsolete them in the
current solaris-userland gate.

-alan-

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

Re: [oi-dev] Packages only in the main repository

[Alan Coopersmith]

On 10/24/18 06:14 AM, Udo Grabowski (IMK) wrote:

On 24/10/2018 14:39, Aurélien Larcher wrote:
Motif is still needed for some applications, but isn't there OpenMotif ?


Yes - but it's not binary compatible with the old Solaris Motif 1.2 or 2.1
so you'll need to recompile the apps to use it.


libXaw is still needed, but again, freedesktop.org has a free alternative.


Right - these are the X11R4 & X11R5 versions for backwards binary compatibility.
X.Org currently ships libXaw7 upstream, which is in a different OI package.


CDE is dead, and people that used it should be, too (I feel sick...).


Hey!  Just because we're old doesn't mean we're useless!


libowconfigoh my god, OpenWindows, olwm ?


That was  a badly named Xsun configuration library - I have no idea why
anything would still be using it.  We dropped it in Solaris 11.4 after
modifying fbconfig (SPARC graphics config utility) to stop using it:

https://github.com/oracle/solaris-xorg/commit/ecb865891b0685db5d


SUNWxwinc/plt are just Meta-incorporation packages for Xwindows
application groups; useful as such, they may be renamed and kept.


They were a transition aid for old SVR4 packages that depended on
the SVR4 SUNWxwplt & SUNWxwinc, which bundled all the X libraries
and clients together before we split them into individual packages
to match upstream.

If you want to publish them, the sources are in:
https://github.com/oracle/solaris-xorg/tree/1c94357064e1b34d3bcec7c43b60ba45ba3114e1/pkg/manifests

(We also dropped them in Solaris 11.4.)

-alan-

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

Re: [oi-dev] Build of gcc-7.3.0 stops with linker errors

[Alan Coopersmith]

On 05/26/18 05:26 AM, Gary Mills wrote:
> On Thu, May 24, 2018 at 11:17:35AM -0400, Richard Lowe wrote:
>>They're not different enough to be more than theoretically mechanical
>>changes, but are (just) different enough you may not be able to
>>_actually_ do it all mechanically.
>>Assembler being much more rigid, you'll have an easier time comparing
>>the outputs to make sure you're doing the same things -- and of course,
>>you having a SPARC to test really helps.
> 
> Are there reference documents that describe the Sun and GNU formats
> for SPARC assembly language?  That would make it easier to translate
> correctly from one to the other.

For the Sun format, see:

https://docs.oracle.com/cd/E37838_01/html/E61063/index.html

-alan-

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

[oi-dev] Fwd: [PATCH:xorg-macros] Update check for manpage section numbers to not rely on Solaris version

[Alan Coopersmith]

I believe this patch should not break you, and should in fact make it easier for
you to decide whether or not to follow our lead in reverting from the SysV man
page sections to the classic Bell Labs/BSD ones that everyone else uses, but 
I've only tested on Solaris 11.3 & 11.4, not OI or any other illumos distros,

so let me know if it breaks for you.

It should apply to the upstream git repo from
git://anongit.freedesktop.org/xorg/util/macros
which OI packages via 
https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/x11/util-macros


-alan-
--- Begin Message ---
Check for a specific file instead of a specific set of versions from
uname, to cope with manpage section alignment coming to 11.4 instead
of 12.0.

Signed-off-by: Alan Coopersmith <alan.coopersm...@oracle.com>
---
 xorg-macros.m4.in | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in
index 7935426..efce888 100644
--- a/xorg-macros.m4.in
+++ b/xorg-macros.m4.in
@@ -114,6 +114,17 @@ AC_DEFUN([XORG_MANPAGE_SECTIONS],[
 AC_REQUIRE([AC_CANONICAL_HOST])
 AC_REQUIRE([AC_PROG_SED])
 
+case $host_os in
+solaris*)
+# Solaris 2.0 - 11.3 use SysV man page section numbers, so we
+# check for a man page file found in later versions that use
+# traditional section numbers instead
+AC_CHECK_FILE([/usr/share/man/man7/attributes.7],
+[SYSV_MAN_SECTIONS=false], [SYSV_MAN_SECTIONS=true])
+;;
+*) SYSV_MAN_SECTIONS=false ;;
+esac
+
 if test x$APP_MAN_SUFFIX = x; then
 APP_MAN_SUFFIX=1
 fi
@@ -129,9 +140,8 @@ if test x$LIB_MAN_DIR = x; then
 fi
 
 if test x$FILE_MAN_SUFFIX = x; then
-case $host_os in
-   # Solaris 2.0 - 11 use SysV man page sections
-   solaris2.?|solaris2.1[[01]])FILE_MAN_SUFFIX=4  ;;
+case $SYSV_MAN_SECTIONS in
+   true)   FILE_MAN_SUFFIX=4  ;;
*)  FILE_MAN_SUFFIX=5  ;;
 esac
 fi
@@ -140,9 +150,8 @@ if test x$FILE_MAN_DIR = x; then
 fi
 
 if test x$MISC_MAN_SUFFIX = x; then
-case $host_os in
-   # Solaris 2.0 - 11 use SysV man page sections
-   solaris2.?|solaris2.1[[01]])MISC_MAN_SUFFIX=5  ;;
+case $SYSV_MAN_SECTIONS in
+   true)   MISC_MAN_SUFFIX=5  ;;
*)  MISC_MAN_SUFFIX=7  ;;
 esac
 fi
@@ -151,9 +160,8 @@ if test x$MISC_MAN_DIR = x; then
 fi
 
 if test x$DRIVER_MAN_SUFFIX = x; then
-case $host_os in
-   # Solaris 2.0 - 11 use SysV man page sections
-   solaris2.?|solaris2.1[[01]])DRIVER_MAN_SUFFIX=7  ;;
+case $SYSV_MAN_SECTIONS in
+   true)   DRIVER_MAN_SUFFIX=7  ;;
*)  DRIVER_MAN_SUFFIX=4  ;;
 esac
 fi
@@ -162,9 +170,8 @@ if test x$DRIVER_MAN_DIR = x; then
 fi
 
 if test x$ADMIN_MAN_SUFFIX = x; then
-case $host_os in
-   # Solaris 2.0 - 11 use SysV man page sections
-   solaris2.?|solaris2.1[[01]])ADMIN_MAN_SUFFIX=1m ;;
+case $SYSV_MAN_SECTIONS in
+   true)   ADMIN_MAN_SUFFIX=1m ;;
*)  ADMIN_MAN_SUFFIX=8  ;;
 esac
 fi
-- 
2.13.0

___
xorg-de...@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel--- End Message ---
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Xorg 1.19.5 testing

[Alan Coopersmith]

On 10/24/17 12:59 PM, Aurélien Larcher wrote:

b) why Xorg searches for protocols.txt in such strange place? Did we
miss some files?


What strange place is that?


(WW) Failed to open protocol names file /usr/lib/amd64/xorg/protocol.txt


I see that the file is only present in /usr/lib on my system, maybe I missed 
something in a patch.


We deliver it in /usr/lib/xorg/protocol.txt but then we only ship 64-bit, not
mixed 32/64-bit.  dix/registry.c in the upstream code says to look for it in:
#define FILENAME SERVER_MISC_CONFIG_PATH "/protocol.txt"


-alan-

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

Re: [oi-dev] Xorg 1.19.5 testing

[Alan Coopersmith]

On 10/24/17 11:46 AM, Alexander Pyhalov wrote:
a) why dtlogin pipe creation fails - was error silently ignored earlier? Who 
should have removed it?

Perhaps, we could just ditch all dtlogin related code from our version of xorg?


The name was set back when dtlogin was the login gui, but at least in Solaris,
we implemented the same interfaces in gdm as well:
https://github.com/oracle/solaris-userland/blob/master/components/gnome/gdm/patches/0004-sdtlogin.patch

b) why Xorg searches for protocols.txt in such strange place? Did we miss some 
files?


What strange place is that?

-alan-

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

Re: [oi-dev] The ATI video driver for OI

[Alan Coopersmith]

On 09/16/17 03:44 PM, Aurélien Larcher wrote:
There was a KMS radeon driver in Solaris but I am not sure if it is still 
maintained and it certainly supported only the ATI cards provided with Sun HW.


It predated KMS and was dropped in the switch to KMS instead of updating it.
(It actually supported the ATI chipsets in the Acer Ferrari laptops popular
 with Sun developers at the time, but not anything you'd have found on the
 market in the past 5+ years.)

-alan-

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

Re: [oi-dev] Change in video driver ABI

[Alan Coopersmith]

On 06/ 6/17 07:23 AM, Aurélien Larcher wrote:



On Tue, Jun 6, 2017 at 12:08 PM, Alexander Pyhalov > wrote:


On 06/ 5/17 12:51 PM, Aurélien Larcher wrote:

On Mon, Jun 5, 2017 at 11:32 AM, Jean-Pierre André <
jean-pierre.an...@wanadoo.fr > 
wrote:

Aurélien Larcher wrote:


xtsol is not provided anymore.


Are there any issues with xtsol? We provide x11/trusted/trusted-xorg . I
suppose, it has no use cases on OI, but at least it's shipped (however I
suppose nobody has tested it).


The code was dropped by upstream on Nov 18 2015 so I did not port it.


Right - it depends on unstable internal interfaces of the Xorg server, so if
you wanted to keep providing it, you would need to take on the work of porting
it to each new version yourself since we're not doing that any more.

Fortunately, the only effect this should have on anyone who is not using a
multi-level trusted desktop (of which the Trusted Extensions version of
GNOME 2.30 was the last produced) is that they'll no longer be confused by
"missing extension module xtsol" messages in the Xorg log files that don't
actually affect them beyond causing confusion.

-alan-

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

Re: [oi-dev] Change in video driver ABI

[Alan Coopersmith]

On 06/ 5/17 12:24 AM, Jean-Pierre André wrote:

[   312.529]  WARNING WARNING WARNING WARNING 
[   312.529] This server has a video driver ABI version of 20.0 that is not
supported by this NVIDIA driver.  Please check
http://www.nvidia.com/ for driver updates or downgrade to an X
server with a supported driver ABI.
[   312.529] =

Are the recent changes in the video ABI in line with the
changes to Solaris ?


The ABI in question is entirely controlled by the Xorg server and changes
between Xorg releases.  Neither Solaris nor OpenIndiana controls it
independently - it's a matter of matching Nvidia versions to Xorg versions
regardless of the underlying OS.

-alan-

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

Re: [oi-dev] Update Rampage

[Alan Coopersmith]

On 05/28/17 02:21 PM, Aurélien Larcher wrote:

Hello,
since I like this page at Repology:

https://repology.org/metapackages/outdated-in-repo/openindiana/

and cannot get my eyes off of:

https://repology.org/repository/openindiana

I decided to update a bunch of multimedia and x11 packages today.
Every version update was tested on my workstation before being pushed but if you
have any problem, please do not hesitate to ping me.


That's a neat site.  Several of us at work have been using a similar site,
https://release-monitoring.org/
but it just tracks the upstream releases, and leaves it to the user to generate
their own reports about how out of date they are.  You may have noticed this in
the Makefiles in the solaris-userland gate - they have lines such as:
components/nethack/Makefile: COMPONENT_ANITYA_ID=8309
which you can lookup the latest release of at
https://release-monitoring.org/project/8309/

-alan-

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

Re: [oi-dev] Glade

[Alan Coopersmith]

On 05/16/17 08:47 AM, Alexander Pyhalov wrote:

On 05/16/17 05:54 PM, Dariusz Sendkowski wrote:

Hi,

It seems that Glade can be bumped to 3.19 (already checked), which is the
highest version that does not require bumping GTK+.

I see that current Glade is built only for 32 arch. Should the new version
be also built only for 32, both 32 and 64 or maybe only 64?


Hi.
There are a lot of components, dependent on libglade, so it should be preserver
for both bits. Also check that our glade generates gtk2 interfaces and should
continue doing so until gtk3 is not default gtk version.


Be careful to distinguish between libglade, which loads Glade version 2 files &
has been deprecated upstream for over a decade, and the Glade 3.x application
which generates GtkBuilder files, read by the GtkBuilder API's in libgtk 2.12
and later:

https://developer.gnome.org/gtk2/stable/gtk-migrating-GtkBuilder.html
https://www.simple-is-better.org/gtk/
https://en.wikipedia.org/wiki/Glade_Interface_Designer

(Things I all had to learn when figuring out how to deal with this on our side,
 in which I recently removed libglade altogether as it's not needed in GNOME 3.)

-alan-

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

Re: [oi-dev] unexpected syntax errors :|

[Alan Coopersmith]

On 05/16/17 05:45 AM, Dariusz Sendkowski wrote:

Hi,

Has anyone ever encountered such weird errors during build?:

/usr/include/iso/stddef_iso.h:61: syntax error, unexpected INTEGER in '# 71' at 
'71'
/usr/include/iso/stddef_iso.h:65: syntax error, unexpected INTEGER in '# 80' at 
'80'
/usr/include/iso/stddef_iso.h:71: syntax error, unexpected INTEGER in '# 91' at 
'91'
/usr/include/stddef.h:61: syntax error, unexpected INTEGER in '# 74' at '74'
/usr/include/limits.h:176: syntax error, unexpected INTEGER in '# 289' at '289'
/usr/include/limits.h:179: syntax error, unexpected INTEGER in '# 292' at '292'
/usr/include/float.h:45: syntax error, unexpected INTEGER in '# 54' at '54'
/usr/include/float.h:47: syntax error, unexpected INTEGER in '# 58' at '58'


That sounds like something is expecting "cpp -P" output and getting cpp output
generated without the -P instead.

-alan-

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

Re: [oi-dev] Can I still install older perl and python?

[Alan Coopersmith]

On 05/12/17 07:01 AM, Gordon Ross wrote:

Admittedly, this one of the things about IPS that has
long bother me.  It's very "opinionated".
IPS "knows better" than I do what packages should
be installed, and in what versions, etc. and if I don't
happen to agree (i.e. in this case, please don't just
remove Python 2.5) well, that's just too bad.


It was designed by employees of a company who wanted to ensure that you
always ended up in a supportable configuration unless you specifically
opted out in a way that support folks could detect, such as by changing
the version-lock facets, using "pkg freeze" to stop packages from changing,
using pkgrecv | pkgsend to republish your own package versions, etc.

Definitely different design goals than most community-developed FOSS
package managers.

-alan-


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

Re: [oi-dev] x11 keyboard layouts

[Alan Coopersmith]

On 04/27/17 03:29 AM, Joerg Schilling wrote:

Alan Coopersmith <alan.coopersm...@oracle.com> wrote:


Sorry - I never learned how multiple keyboard layout groups work in XKB.


Does this mean that you believe it should be possible to have more than one
keyboard layout available at the same time?


Yes - but being a simple English speaker who doesn't know how to type in any
other layouts, I don't know how, I just expect that you'd be able to do the
same in Xorg on Solaris/illumos as you can in Xorg on any other platform,
and hope the answers are found somewhere under https://www.x.org/wiki/XKB/ .

--
    -Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] x11 keyboard layouts

[Alan Coopersmith]

On 04/26/17 06:10 AM, Alexander Pyhalov wrote:

Hello.

I'm a bit confused.
I'm trying to get keyboard layout from xscreensaver-lock and see unexpected
results.

I have a function which returns current layout (see below), which works fine
when compiled standalone. But when I compile it as part of xscreensaver-lock , I
suddenly find out that it sees two XKB groups
'English (US)' instead of 'English (US)' and 'Russian'.
So I see that we use group number 0 or 1, but their names are masked.

Do you have any suggestions where xscreensaver-lock can manage to do it? :)


Sorry - I never learned how multiple keyboard layout groups work in XKB.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Gnome 3

[Alan Coopersmith]

On 11/ 4/16 07:49 PM, Franklin Ronald wrote:

Hi team,

Gnome 3 has been ported to Solaris
(https://java.net/projects/solaris-userland/sources/gate/show/components/gnome).
My question is: We can port it to OpenIndiana based on Oracle work?


Everything we published to the solaris-userland gate should be covered by an
acceptable Open Source license.  You probably want to replace the Oracle
trademarked logo images with your own of course, but that's just as much
an issue of promoting your own work as avoiding trademark issues.

We did need some changes to other components & consolidations.  I've
probably forgotten some, but we needed at least:

 - FreeType 2.12 (X gate)
 - Enabling the llvmpipe backend in Mesa (X gate) which of course
   required a suitable LLVM (Userland gate)
 - IBus 1.5 (G11N gate)
 - libxkbcommon (X gate)
 - libepoxy (X gate)
 - ld -Bsymbolic-functions (ON gate)
 - xkeyboard-config.pc in x11/keyboard/data-xkb package (G11N gate)
 - pthread_getattr_np() in libc (ON gate)
 - XIAllowTouchEvents() in libXi (X gate)

plus pretty much everything in components/desktop in the solaris-userland
gate.  (components/gnome is purely GNOME stuff, other things it depends
on from freedesktop.org, mozilla, etc. ended up in components/desktop.)

We did not port either Sun Ray support or Trusted Desktop support to
GNOME 3, but I didn't think OI ported those to MATE either.

-alan-

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

Re: [oi-dev] clang open source packages and nightly binaries

[Alan Coopersmith]

On 10/22/16 07:49 PM, C Bergström wrote:

Thoughts
--
I'd like to setup an official Solaris 11 or 12 (or someone can get me
access) and I'll do my best to see if we can make 1 clang package
which works across both and produces binaries that are portable by
default.


I believe you can get access to Solaris 11 VM's in the software development
cloud: https://swisdev.oracle.com/SWiSDev_faq.php  (I've never tried myself,
as I use an internal developer cloud instead.)

Solaris 12 is not yet publicly available, though customers with sales reps
can have those reps nominate them for a private early access program.

-alan-

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

Re: [oi-dev] libEGL library

[Alan Coopersmith]

On 09/13/16 08:36 AM, Alexander Pyhalov wrote:

On 09/13/16 06:31 PM, Alan Coopersmith wrote:

On 09/13/16 04:55 AM, Alexander Pyhalov wrote:

Hi.
Both mesa and nvidia driver can provide libEGL.so.1. Does somone know why
libEGL.so.1 library is not managed using ogl-select service?


Because neither provided it when ogl-select was created and since we still
build our Mesa packages with --disable-egl we've not had a need to add it.



Did you have any particular reason to disable it?


I didn't set that flag, but I don't remember any particular reason
beyond not needing it at the time, and not having time then to deal
with figuring out how to integrate it correctly (ogl-select, package
manifest, ARC review, etc.).

-alan-

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

Re: [oi-dev] libEGL library

[Alan Coopersmith]

On 09/13/16 04:55 AM, Alexander Pyhalov wrote:

Hi.
Both mesa and nvidia driver can provide libEGL.so.1. Does somone know why
libEGL.so.1 library is not managed using ogl-select service?


Because neither provided it when ogl-select was created and since we still
build our Mesa packages with --disable-egl we've not had a need to add it.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Apache OpenOffice retirement - all contributors fled to LibreOffice after Oracle Sun takeover Fwd: Broken components

[Alan Coopersmith]

On 09/ 9/16 01:52 PM, Lionel Cons wrote:

On 9 September 2016 at 22:45, Alan Coopersmith
<alan.coopersm...@oracle.com> wrote:

On 09/ 9/16 01:24 PM, Lionel Cons wrote:


Sigh. What should I say? Was this not the expected outcome? I could
argue Oracle has to learn about managing communities, but I'd say no
one there would listen. Or not?



Oracle turned the whole thing over to Apache years ago, and Apache has
been managing that community ever since.


And why did things go south that fast then? Didn't Oracle also pull
the plug on the in house dev team - which in turn then went to work on
Libreoffice instead?


Yes, Oracle killed the product, got out of the office suite market, laid off
the team, and instead of leaving the code to rot, donated it to Apache.  It
wasn't trying to grow a community, just let the community have a chance to
continue without it.

-alan-

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

Re: [oi-dev] Apache OpenOffice retirement - all contributors fled to LibreOffice after Oracle Sun takeover Fwd: Broken components

[Alan Coopersmith]

On 09/ 9/16 01:24 PM, Lionel Cons wrote:

Sigh. What should I say? Was this not the expected outcome? I could
argue Oracle has to learn about managing communities, but I'd say no
one there would listen. Or not?


Oracle turned the whole thing over to Apache years ago, and Apache has
been managing that community ever since.

-alan-

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

Re: [oi-dev] Broken components

[Alan Coopersmith]

On 09/ 9/16 02:20 AM, Andrey Sokolov wrote:

desktop/openoffice


Just FYI:
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201609.mbox/%3C008d01d204a9%24bd37caa0%2437a75fe0%24%40apache.org%3E
https://lwn.net/SubscriberLink/699755/fe3dd84135390d60/

-alan-

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

Re: [oi-dev] vmware driver for xorg broken? (spaces replace much of what I type)

[Alan Coopersmith]

On 09/ 8/16 09:47 AM, Michael Kruger wrote:

On 09/08/2016 11:38 AM, Gordon Ross wrote:
I don't mean to highjack your thread, but am curious how you have managed to
load the vmware driver.
On a fresh install in VMware player, when I run the modinfo command, I only see
the vga driver loaded.

 92 f7ccc000   4898 276   1  vgatext (VGA text driver)

The vmware(7) man page suggests the vmware video adapter should be auto-detected
and automatically load the vmware driver.
This however does not seem to be the case.


modinfo only shows kernel drivers, not Xorg drivers, since Xorg drivers are just
*.so's dlopen'ed by a userspace process, not loaded into the kernel address 
space.

To see what drivers Xorg loaded, either check Xorg.0.log or run pldd on the Xorg
process.

-alan-

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

Re: [oi-dev] vmware driver for xorg broken? (spaces replace much of what I type)

[Alan Coopersmith]

On 09/ 8/16 08:38 AM, Gordon Ross wrote:

Next I guess I'll want instructions for building and debugging that.
Any tips for that?


If you want the latest from upstream, minus any OI patches & packaging, see:

https://www.x.org/releases/individual/driver/xf86-video-vmware-13.1.0.tar.bz2
https://cgit.freedesktop.org/xorg/driver/xf86-video-vmware/

Fairly standard GNU autoconf build process (./configure --prefix=/usr ; make;
sudo make install).

-alan-

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

Re: [oi-dev] X packages to deprecate

[Alan Coopersmith]

On 8/28/2016 3:17 AM, Udo Grabowski (IMK) wrote:

On 28/08/2016 12:15, Volker A. Brandt wrote:

Udo Grabowski (IMK) writes:

On 27/08/2016 20:30, Alan Coopersmith wrote:

pkg:/x11/library/toolkit/libxaw4@0.5.11,5.11-2013.0.0.0
pkg:/x11/library/toolkit/libxaw5@0.5.11,5.11-2013.0.0.0


These provide backwards binary compatibility for Xaw apps compiled
on older
Solaris releases - libXaw4 for those built on Solaris 2.2 or prior
(yes,
1992ish), libXaw5 for those build on Solaris 2.3 through 10.

libXaw7 is the current version of this, introduced to OpenSolaris in
2008.




There are a few programs out there needed that use this library,
xfig being the most prominent of these.


The xdvi viewer from the TeXlive system also (still) uses libXaw.



Indeed, I forgot that, this is also used here heavily,
so libXaw is indeed an important package to keep.


But if you're building them from source today, then you're using 
libxaw7, not libxaw4 or libxaw5 right?   I only saw 4 & 5 on the

proposed deprecation list, not 7.

-alan-

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

Re: [oi-dev] X packages to deprecate

[Alan Coopersmith]

On 08/27/16 04:40 AM, Aurélien Larcher wrote:

Are we able to simply and effectively deprecate these packages or are
there issues to foresee?


You can probably guess my opinion based on how many of them I've already
obsoleted in  https://hg.java.net/hg/solaris-x11~x-s12-clone/ but since
others asked what these do, I can provide some background.


pkg:/compatibility/packages/SUNWxwinc@0.5.11,5.11-2013.0.0.0
pkg:/compatibility/packages/SUNWxwman@0.5.11,5.11-2013.0.0.0
pkg:/compatibility/packages/SUNWxwopt@0.5.11,5.11-2013.0.0.0
pkg:/compatibility/packages/SUNWxwplr@0.5.11,5.11-2013.0.0.0
pkg:/compatibility/packages/SUNWxwplt@0.5.11,5.11-2013.0.0.0
pkg:/compatibility/packages/SUNWxwpmn@0.5.11,5.11-2013.0.0.0
pkg:/compatibility/packages/SUNWxwslb@0.5.11,5.11-2013.0.0.0


These were a transition aid for our package refactoring, when we
went from "Put all the headers for all libraries in SUNWinc,
all the libraries & programs in SUNWplt, all the man pages for
all the programs in SUNWxwman and for all the libraries in SUNWxwpmn"
to following the upstream groupings & IPS model of keeping headers,
man pages, etc. with the software they are for, to allow people
following S10 instructions or using SVR4 packages with old
dependencies to get the same sets of files those used to provide.

I've not deleted them mostly because they're low cost - there's
little to maintain as they're just dependencies on other packages,
but someday the transition will probably end.


pkg:/library/motif/libdpstkxm@0.5.11,5.11-2013.0.0.0


This lets you use DPS (see below) in a Motif application.
Two ancient bits mixed together makes something far more obscure!
I have no idea if anything ever used it.


pkg:/system/kernel/hardware-cursor@0.5.11,5.11-2013.0.0.0


This module provides hardware cursor acceleration for Xsun on SPARC fb
drivers.  It's actually a clever little streams module you push on the
mouse stream that causes it to update the cursor directly on the fb driver,
all without ever leaving the kernel to context switch in the X server.
But cleverness isn't useful if you have nothing to use it with, so we
dropped it once Xsun was gone.


pkg:/x11/compatibility/links-svid@0.5.11,5.11-2013.0.0.0


Long long ago, Sun put all of X in /usr/openwin.
The System V Interface Definition standard needed a vendor independent path,
so said to use /usr/X and allowed Sun to make it a symlink to /usr/openwin.


pkg:/x11/library/dps@7.5,5.11-2013.0.0.0


This is the Display Postscript (DPS) client library for old software written
to use this X11 extension.   Unless you're displaying to an ancient server
like Xsun that has this deeply proprietary extension, all it does today is
let your software run without complaining the library is missing and query
the server to find the extension isn't there.

Removing this breaks the ancient OpenWindows AnswerBook display tool that
was obseleted by "point a web browser at docs.sun.com" 2 decades ago, and
the Java SE runtime environment for Java 1.4 and before.   Preventing people
from running Java code that hasn't gotten security patches since 2008 seems
like a public service to me.


pkg:/x11/library/libowconfig@0.5.11,5.11-2013.0.0.0


This reads and writes config files for the Xsun server.
If you ever ship the openXsun sources I released shortly before OpenSolaris.org
died you need it, if not, you don't.


pkg:/x11/library/toolkit/libxaw4@0.5.11,5.11-2013.0.0.0
pkg:/x11/library/toolkit/libxaw5@0.5.11,5.11-2013.0.0.0


These provide backwards binary compatibility for Xaw apps compiled on older
Solaris releases - libXaw4 for those built on Solaris 2.2 or prior (yes,
1992ish), libXaw5 for those build on Solaris 2.3 through 10.

libXaw7 is the current version of this, introduced to OpenSolaris in 2008.


pkg:/x11/network/rstart@1.0.3,5.11-2013.0.0.0


This is an old solution for using rsh to start X11 apps remotely.
It was superseded by "ssh -X" in the mid-90's.


pkg:/x11/network/x11-network-proxies@7.5,5.11-2013.0.0.0


This package contains the lbxproxy, xfwp, xfindproxy, and proxymngr utilities
for proxying the X11 protocol over low-bandwidth connections or through a 
firewall.

Over a decade ago, Keith Packard & Jim Gettys compared lbxproxy to ssh with
X11 Forwarding & Compression and found ssh provided equivalent or better
performance and latency to lbxproxy, and concluded:
  "LBX does not solve either the authentication and security problems that
   SSH solves. We saw little evidence of LBX ever helping. At least as
   implemented, LBX looks to have been a bad idea."
   - http://keithp.com/~keithp/talks/usenix2003/

As a result X.Org deprecated LBX and dropped support for it from Xorg 1.2
and later releases, so the Xorg servers in Solaris 10 & later do not have
any LBX support, only older servers like Xsun do.   I've never seen anyone
use the others, since SSH X11 tunneling is far easier to setup and more secure.

-alan-

___
oi-dev mailing list

Re: [oi-dev] OpenIndiana Code of Conduct

[Alan Coopersmith]

On 08/ 1/16 03:01 PM, WebDawg wrote:

On Mon, Aug 1, 2016 at 5:31 PM, Alan Coopersmith <alan.coopersm...@oracle.com
<mailto:alan.coopersm...@oracle.com>> wrote:

On 08/ 1/16 07:13 AM, WebDawg wrote:

Do you really want a group of people assigned to disciplining people, 
in the
dark?  How about anonymous complaints, but on an open forum?  There
should be a
POC to complain, but if you want the project to be 'open' should not
every thing
be open?


Not necessarily.  You don't want people afraid to report because they're 
going
to be publicly exposed, and you don't want people threatening the project
claiming they've been publicly defamed over accusations.   Sometimes 
privacy is
the best policy, and not everything needs to be open to the world.

I could just see it being used to report things that now someone cannot defend.


The team handling the abuse complaints can ask the accused to respond privately,
without involving the rest of the world.

--
    -Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] OpenIndiana Code of Conduct

[Alan Coopersmith]

On 08/ 1/16 07:13 AM, WebDawg wrote:

Do you really want a group of people assigned to disciplining people, in the
dark?  How about anonymous complaints, but on an open forum?  There should be a
POC to complain, but if you want the project to be 'open' should not every thing
be open?


Not necessarily.  You don't want people afraid to report because they're going
to be publicly exposed, and you don't want people threatening the project
claiming they've been publicly defamed over accusations.   Sometimes privacy is
the best policy, and not everything needs to be open to the world.

-alan-

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

Re: [oi-dev] Mate 1.14

[Alan Coopersmith]

On 08/ 1/16 01:43 PM, Alexander Pyhalov wrote:

BTW, does someone know why policykit wasn't ported? Was it considered needless
in presence of proper RBAC?


When HAL was integrated into ON, an implementation of the policykit API as a
wrapper around RBAC was included, as you can see in:
https://github.com/illumos/illumos-gate/tree/master/usr/src/lib/policykit

Unfortunately, upstream killed off policykit a few years back in favor of
their new polkit API: https://en.wikipedia.org/wiki/Polkit

-alan-

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

Re: [oi-dev] OpenIndiana Code of Conduct

[Alan Coopersmith]

On 07/21/16 07:47 PM, Nikola M wrote:

Or someone really thinking that fascist autocracy is a good thing to try
on OI people.



Intentionally not seeing any problems in it induces the question of
using a brain at all.


So everyone who disagrees with you is a brainless fascist and that's why
you've unilaterally decided to ignore all of their opnions and replace the
webpage they'd reached consensus on with yours that has no other support?

You do realize that sort of anti-social, disruptive, obstructionist
behavior is exactly why this was proposed and continuing to act that
way is just convincing more and more people the original proposal is
necessary to allow people to work on OI without having to have these
horrible fights all the time that just chase people away?

-alan-



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

Re: [oi-dev] OpenIndiana Code of Conduct

[Alan Coopersmith]

On 07/19/16 02:57 AM, Nikola M wrote:

What will not be tolerated:

  * Open hostility, and or abusive language.
  * Repeated complaining (rehashing) of closed (decided) issues.
  * Participants who disrupt the collaborative space, or participate in a
pattern of behavior which could be considered harassment.
  * Filibustering – (replying with negative or opposing viewpoints to every
post in a mailing list thread).




This whole 'not tolerated' section is void and made with unprecise language.
It is simply not needed having in mind 'Core principles' section'.
In this state whole section should be deleted.


It is widely recognized that Codes of Conduct for communities need to explicitly
state what behavior is not allowed to make sure everyone has the same 
understanding.

https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/
https://gigaom.com/2014/10/25/why-companies-that-rely-on-open-source-projects-must-insist-on-a-strong-enforceable-code-of-conduct/


And actualy 'not be tolerable' is NOT in a sense of OI community.


http://www.plausiblydeniable.com/opinion/gsf.html - see fallacy #1.
http://www.slideshare.net/dberkholz/assholes-are-killing-your-project
https://www.safaribooksonline.com/library/view/team-geek/9781449329839/ch04.html
https://www.youtube.com/watch?v=-F-3E8pyjFo


  * Adopted from the Project-FiFo Code of Conduct
.
  * Further inspiration derived from the FreeBSD Code of Conduct
.



I don't know for anyone's inspiration, but it is not needed here to mention
direct competition in a way that we are not part of FreeBSD nor ever will be,
unless all BSDs accept copyleft licensing/CDDL .


Crediting sources is a cornerstone of open source.  And if you view BSD projects
as competition instead of potential allies, you'll make it harder to get other
projects to support OI - people from different distros often have to work 
together, and in both X11 & GNOME, I've been grateful for cooperation with BSD

maintainers in helping get non-Linux support issues resolved to benefit both
the BSDish and Solarish OS'es.

-alan-

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

Re: [oi-dev] OpenIndiana Docs - updated

[Alan Coopersmith]

On 05/16/16 11:28 PM, Nikola M wrote:

On 05/17/16 05:46 AM, Michael Kruger wrote:

In regards to the PDL, to whom does one submit a signed contributor agreement?


To Openindiana and illumos surely.


Neither OI nor illumos have any legal entity to assign copyright to - no 
foundations or non-profit corporations were ever formed.


You could only assign to individuals like Garrett or Alasdair, or to a
commercial company like Joyent, Everycity, or Oracle.

I suspect after what happened to OpenSolaris though, no one is interested
in further assignments to commercial entities of the right to make things
proprietary.

Fortunately, none of the licenses involved require such agreements.

-alan-

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

Re: [oi-dev] Specifying GCC as a compiler in a Makefile for simple library

[Alan Coopersmith]

On 05/15/16 05:32 PM, Reginald Beardsley via oi-dev wrote:

FWIW I have NEVER ever seen a makefile that used a variable named COMPILER.


Then you've never looked at any of the Userland makefiles that build with gcc.
It's used by the userland shared-macros.mk to set CC, CXX, CFLAGS, etc. to
appropriate defaults.

If you were doing a build that used configure scripts, the Userland makefiles
pass CC/CXX/etc. to configure automatically, but I don't think it does that
for "justmake" since there is no configure script.

-alan-

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

Re: [oi-dev] demonstration docs website

[Alan Coopersmith]

On 05/ 1/16 10:48 PM, Nikola M wrote:

*You aether accept open documentation license including Contributor agreement to
OI or you contribute your time at somewhere else.*


Why don't you let the people who run the project decide whether or not to accept
contributions before you chase everyone away?

-alan-

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

Re: [oi-dev] issues with dir action in IPS

[Alan Coopersmith]

On 04/19/16 03:15 AM, Nikola M wrote:

I would also like to hear more input from someone else regarding no-scripting
philosophy in IPS.


See the links in the "Background Reading" section on the bottom of
 https://java.net/projects/ips/pages/Home
and the blogs at:
 https://timsfoster.wordpress.com/2011/11/09/ips-self-assembly-part-1-overlays/

https://timsfoster.wordpress.com/2011/11/09/self-assembly-part-2-multiple-packages-delivering-configuration/
and the docs at:
 http://docs.oracle.com/cd/E53394_01/html/E54820/pkgconcepts.html#scrolltoc

-alan-

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

Re: [oi-dev] pkgdepend can not find existing file

[Alan Coopersmith]

On 03/23/16 12:33 PM, Till Wegmüller wrote:

Hi

While Packaging mate-screensaver i stumbled upon a funny error message

pkgdepend says:

 
>/root/workspace/oi-userland/components/mate/mate-screensaver/build/manifest-i386-mate-screensaver.depend
 has unresolved dependency '
 >depend type=require fmri=__TBD pkg.debug.depend.file=libGL.so.1 \
 > pkg.debug.depend.reason=usr/libexec/mate-screensaver-gl-helper \
 >pkg.debug.depend.type=elf \
 >pkg.debug.depend.path=lib \
 >pkg.debug.depend.path=usr/lib'.

So as far as i understand it it cannot find libGL.so.1
Funny is that, this file exists in /usr/lib


It's not saying that it can't find the file, but rather that it cannot find a
package containing /lib/libGL.so.1 or /usr/lib/libGL.so.1 (as either a link or
a file).


Side note usr/lib/libGL is linked to usr/lib/GL/libGL which is linked to
var/run/opengl/lib/libGL which finaly links to usr/lib/mesa/libGL.
Why do those links not directly link to usr/lib/mesa/libGL?


Because the ogl-select runtime service sets the links to the nvidia or mesa
version as needed for the system.   This is also why they're not packaged -
the package can't set the link differently based on the hardware installed
on the system.

This is why xscreensaver has a workaround for this in its manifest:

# pkgdepend can't follow the runtime generated symlinks to libGL
set name=pkg.depend.bypass-generate value=libGL\.so\.1

[... all the files in the package ...]

# Second half of workaround for pkgdepend not handling libGL's magic properly
depend type=require fmri=__TBD pkg.debug.depend.file=usr/lib/mesa/libGL.so.1

https://hg.java.net/hg/solaris-userland~gate/file/0416d82f7f55/components/desktop/xscreensaver/xscreensaver-hacks-gl.p5m

--
    -Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Update on XNV and JDS consolidation migrations

[Alan Coopersmith]

On 02/ 7/16 05:09 PM, Aurélien Larcher wrote:

- there are 24 components left for packaging in x-S12, some of them not present
in OI, I do not know if some of them are irrelevant:

./accessx


This is a motif client for configuring accessibility settings - the GNOME
preferences panel does a better job of this for GNOME users.


./appres

> ./editres
> ./listres
> ./viewres

These are tools for working with the resources used by old libXt based clients,
not very useful with gtk or Qt+ clients, but not entirely irrelevant since there
are still some of those old programs around.


./build-tools


These are build tools specific to the X gate infrastructure, irrelevant (or
duplicate) for building in Userland.  (The time.c file is a local copy of
Userland's tools/time.c.)


./compat-links


This just makes symlinks for backwards compatibility with old Solaris releases
that had X under /usr/openwin or /usr/X11.


./drm


That's kinda important, though you may still be using the older code from the
illumos gate instead.


./dsession


That's probably entirely useless to you, unless someone added SPARC M7 support
when I wasn't looking.


./fbconfig


This tool is for configuring SPARC frame buffers - useful in a SPARC port,
utterly irrelevant on x86.


./intel-gpu-tools


This is handy for debugging problems with the Intel DRM/KMS drivers.


./libepoxy (some fixes needed)
./libxkbcommon (some fixes needed)
./libxshmfence


Those are newer libraries, needed by some new things like mutter & gnome-shell.


./makedepend


Some other programs like having this around to keep makefile dependencies up to 
date.



./rasterfile


Headers & man page describing the ancient Sun rasterfile graphics support.
I don't remember if anything you ship requires them.


./sun-aliases


Font aliases for old Solaris fonts that are helpful for backwards compatibility
of old apps/configs, but not very relevant to new users.


./synergy


A neat program that lets users with multiple computers side-by-side share
a mouse and keyboard across them, instead of having a separate one for each.


./transset


Handy little tool for setting window transparency when using a compositor.


./workspace-patterns


Highly irrelevant ancient set of OpenWindows background tiled patterns.


./xorg-cf-files


Data files for Imake, sadly still relevant to a small number of programs that 
haven't given up and moved to something better like automake yet.



./xorg-docs
./xorg-sgml-doctools


Docs are good, as are tools to build them, but if your users just had to go to
www.x.org instead to read the online copies it wouldn't be the end of the world.


./xserver-common


Those are various SMF & RBAC bits you'd want to have that are shared by Xorg, 
Xvnc, etc.



and about 70 font-related packages which I do not know if they are all 
meaningful:


Most are only meaningful to older programs which use the old X11 bitmaps, not to 
modern GNOME/KDE/etc. software.  The main exceptions are:



./dejavu-fonts-ttf
./google-droid-fonts
./liberation-fonts-ttf


Those are TrueType fonts useful to modern desktop users.

-alan-

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

Re: [oi-dev] FAQ update

[Alan Coopersmith]

On 01/ 7/16 01:11 PM, Aurélien Larcher wrote:

Hi,
If someone wants to give it a shot, this page needs love:

http://www.openindiana.org/documentation/faq/

because it is fairly outdated...


Most of the OpenSolaris consolidation links pointing to hub.opensolaris.org
can be replaced with links to the appropriate projects on
https://solaris.java.net/ or https://java.net/projects/solaris/
(though some like Caiman are not available there either, and SFW was replaced
 by Userland).

-alan-

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

Re: [oi-dev] OI User documentation

[Alan Coopersmith]

On 12/31/15 02:36 AM, Michael Kruger wrote:

On 12/26/2015 12:46 PM, Alan Coopersmith wrote:

On 12/26/15 01:36 AM, Nikola M wrote:

I have just found this as the documentation reference.
https://www.illumos.org/projects/documentation/wiki/Existing_OpenSolaris_documentation



Which seems to need updates to point to http://illumos.org/books/
instead of
the long dead hub.opensolaris.org.

 -alan-



Thanks for providing this link Alan,

There is some great stuff here, and the editors did a fine job of reworking
things for the Illumos project.

I am curious however, where on illumos.org one can find the link to these books.
If you hadn't provided it, I'm not sure I would have ever discovered these for
myself.


On illumos.org, click "About illumos" in the left nav bar.

Either scroll down to "Documentation & Resources" or click the link in the
table of contents to jump down there.

Look for the link "illumos books".

-alan-

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

Re: [oi-dev] OI User documentation

[Alan Coopersmith]

On 12/25/15 08:40 AM, Aurélien Larcher wrote:

On the contrary since oi-userland, pkg and slim_source reside on Github, I do
not see the point in reinventing the wheel or incur additional maintenance.


Also https://github.com/rmustacc/illumos-docbooks since you're not the first
to go there.

-alan-

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

Re: [oi-dev] OI User documentation

[Alan Coopersmith]

On 12/26/15 01:36 AM, Nikola M wrote:

I have just found this as the documentation reference.
https://www.illumos.org/projects/documentation/wiki/Existing_OpenSolaris_documentation

Which seems to need updates to point to http://illumos.org/books/ instead of
the long dead hub.opensolaris.org.

-alan-

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

Re: [oi-dev] [OpenIndiana-discuss] Sun/Oracle China's DRM//KMS Sol11.2 port backported to function on old-style gfxp_private from pre-2010 era but still immediatedly PANICS

[Alan Coopersmith]

On 12/11/15 10:39 AM, Aurélien Larcher wrote:

Hi Martin,
thanks for the update!
The manual page mentions that support concerns:

"[...] the Intel i845, i865, i915, i945, i965 and G33 series integrated graphics 
controllers."

while ThinkWiki mentions that, for Linux, the i915 driver may be used with Intel
HD Graphics.
Do you know if it is also the case ?


The man page, even in Solaris, is out of date.   The driver supports some 
generations of Intel HD graphics, but there's been 5 or 6 completely different

generations so far, so "Intel HD graphics" is too vague - it's like claiming to
support all Intel CPU's & ISA extensions without knowing which CPU models.

https://en.wikipedia.org/wiki/Intel_HD_and_Iris_Graphics

--
    -Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Thunderbird 38.4.0 integration

[Alan Coopersmith]

On 11/29/15 11:52 AM, Мартин Бохниг wrote:

gcc was also supported by gate after gate, then almost all gates.

Oracle broke with that design for no reason


[Before reading the following, please remember the always present disclaimer
that I am not an Oracle spokesman and cannot speak for Oracle, so if anyone
quotes this as "Oracle says..." you are lying and jeopardizing my ability to
continue being here.]

An obvious reason was that the time & effort could be better spent elsewhere
once Oracle was no longer following Sun's goals of making a complete open
source OS that could be built with free tools such as gcc & ported to platforms
that Studio didn't support.

Similarly, the commit I pointed to, in which the Oracle builds of Firefox switch
from applying a ton of patches just to get Studio to build to a smaller number
of patches & using gcc instead is also about choosing how to prioritize effort,
and deciding that for Firefox, the benefits of building with Studio were not
worth the substantial costs (including slower & more painful updates to new
upstream releases to rebase all those patches to the new upstream code).

That publishing a recipe to build Firefox for Solaris with gcc is also helpful
to OI is just a happy bonus side effect for OI.


BTW, did you see my request for help with gfxp_alloc_kernel_space() ?
I really only need to find out, if my local implementation is wrong (causing the
TRAP on S11.0 and Illumos, while working fine on 11.1, 11.2 and 11.3), or if
there is any other reason.


I did, but I have no idea.  Unfortunately, I'm not sure if any of the small
handful of people in the world who know about gfx_private are on this mailing
list or if they were checking their email over the 4-day holiday weekend we
just had in the US (Thursday was a public holiday for Thanksgiving, Friday
was a bonus day off at Oracle and many other non-retail companies).

-alan-

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

Re: [oi-dev] Thunderbird 38.4.0 integration

[Alan Coopersmith]

On 11/29/15 05:45 AM, Мартин Бохниг wrote:

good work, but is it correct that I can only see patches for 24.2 and 31.7.0
which are normaly highly (too much) Studio-specific becaus Oracle only uses
Studio for everything now (while Sun at least maintained a status from 2006 to
its end)?


Not always: https://hg.java.net/hg/solaris-desktop~spec-files/rev/1ca45beec8c3

-alan-

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

Re: [oi-dev] [OpenIndiana-discuss] Personal announcement: update on donations and good News: Can directly continue with DRM/GEM/KMS without interruption due to having to serve pizza

[Alan Coopersmith]

On 11/19/15 11:29 PM, Martin Bochnig wrote:

I will require some days to write a worthy ANNOUNCE file with explanations and
all the trouble I went through in summer of 2013  at a time before Sun published
their KMS port and when nobody could imagine, that Sun/Oracle would be so cool
to give us their port (big thanks to Ken for bugging Alan Coopersmith long
enough and hard enough, and to Mr. Alan Coopersmith for being once again on our
side [after the same took already place with openXsun in summer 2010 ]).


Thanks - but while I supported the publication of the DRM/KMS sources, I didn't
actually do any work for it - that was all done by Randy, with the primary goal
of better cooperation & sharing with upstream & with other OS'es shipping those
drivers - whether Linux, BSD, or illumos based.

--
    -Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] hack 5800

[Alan Coopersmith]

On 08/29/15 01:29 PM, Bruce Lilly wrote:

Vnc native protocol (RFB or remote frame buffer) uses port 5900 by default.
If http connections are enabled for vnc, port 5800 is activated as an http
interface to a Java applet that launches a Java-based vnc viewer.


When we integrated this code into Solaris, to conform with Solaris security
policy, we patched it to only listen on port 5800 if you requested it with
the -http option, where upstream enabled it by default:

https://hg.java.net/hg/solaris-x11~x-s12-clone/file/570c86581dc8/open-src/xserver/xvnc/vnc-nohttpd.patch

I've not checked the OI fork of the code to see if they kept this up or
dropped it.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Building pkg

[Alan Coopersmith]

On 06/ 7/15 06:26 AM, G B via oi-dev wrote:

When attempting to build pkg I get:

user@host:/export/builds/pkg$ hg clone
http://hg.opensolaris.org/sustaining/oi_151a/pkg-gate/ pkg-gate
real URL is https://solaris.java.net/
abort: requirement '!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0
Transitional//EN' not supported!


What is causing this to fail?


Looks like you typed opensolaris.org where you meant openindiana.org.

opensolaris.org never hosted oi 151a repos, even before it was shut
down and replaced with redirects to html pages instead of hg repos.

http://hg.openindiana.org/sustaining/oi_151a/pkg-gate/ on the other
hand looks like a valid hg repo.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Update/addition of XCB components

[Alan Coopersmith]

On 01/12/15 02:59 AM, Aurélien Larcher wrote:

Hi Alan,
Ken asked me to bump glproto to 1.4.17: do you see any difficulty or is it
expected to be straightforward ?


I'd expect it to be straightforward - I don't know of any incompatibilities
there.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Stats

[Alan Coopersmith]

On 12/17/14 08:32 AM, ken mays via oi-dev wrote:

The current analogy is:

1. Solaris 10/11 - production
2. OpenIndiana - development/testing (but CAN be used in 24/7 production)


That's a weird analogy since they're different forks - it'd be like saying
RHEL is production, Debian sid is testing - you're not testing what's going
to be in production in the future, but something quite different.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Miass OpenSolaris User Group

[Alan Coopersmith]

On 12/ 2/14 05:52 AM, Nikola M. wrote:

I would like to understand why distribution that was already in some snv_134 or
something, after 111b/2009.06 release, could not just be renamed and moved on
like nothing happened?


That is exactly what OpenIndiana tried to do.


OpenIndiana came after that and I don't see too much of people previously inside
Opensolaris community stepping up, _except_ those great people that actually
made Openindiana possible.


OpenIndiana found out making that distro is hard without the hundreds of people
Sun was paying to work on it. The number of community participants from outside
Sun never even came close to matching the amount Sun was assigning to do the
work (and which Oracle then kept working on Solaris 11 instead).

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Miass OpenSolaris User Group

[Alan Coopersmith]

On 12/ 1/14 06:06 AM, Joerg Schilling wrote:

In late 2004 or early 2005, there was a community decision that there can never
be a distro with the name OpenSolaris.


There was no community framework to make such a decision then - just a limited
number of people in the pilot program until we went public in June 2005.

And any decision in a project like this would not be this can never happen,
but just this is not going to happen for now - you can't restrict future
leadership from changing their minds when circumstances change.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Resignation

[Alan Coopersmith]

On 09/ 7/14 12:24 AM, Peter Firmstone wrote:

   1. Document your governance model, I'm a member of an Apache project,
  we have clear rules that assist in resolving differences


Unfortunately, OpenSolaris adopted the Apache governance model and it was
a poor fit (Apaches rules for governing a large body of loosely related
projects didn't map well to a community trying to generate a single unified
OS) and too heavy-weight at the time it was introduced.  A big problem was
driving things the wrong way around - we built out all this governance
structure and then hoped people would show up to use it, and they saw more
overhead than benefit and were turned off by it.

That's left the OpenSolaris offshoots wary of governance and refusing to
admit that some level is necessary for ensuring decisions get made, and
thus left them floundering and directionless.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] [OpenIndiana-discuss] F*ck Yahoo, AOL get us back our mailing lists

[Alan Coopersmith]

On 05/24/14 07:56 AM, Nikola M. wrote:

On 05/23/14 02:09 AM, Reginald Beardsley via oi-dev wrote:

May I suggest that the original From:  email address be added to the CC list?
That would solve the How do I email  privately? problem.

Thanks,
Reg

I see that From: consists from 'Name username at password' 
mailingl...@adress.com
Maybe one can replace 'at' with '@' and that's it.


Or simply look in the Reply-To field, where the unmolested e-mail address 
appears.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] [OpenIndiana-discuss] F*ck Yahoo, AOL get us back our mailing lists

[Alan Coopersmith]

On 05/24/14 08:05 AM, Sriram Narayanan wrote:

I see :

from:   Alan Coopersmith alan.coopersm...@oracle.com
mailto:alan.coopersm...@oracle.com
reply-to:   OpenIndiana Developer mailing list oi-dev@openindiana.org
mailto:oi-dev@openindiana.org
to: OpenIndiana Developer mailing list oi-dev@openindiana.org
mailto:oi-dev@openindiana.org


Because I'm not mailing from a provider that uses DMARC and thus required
hiding my real address in the From: line.   Look instead at a e-mail from
a yahoo user that puts the mailing list address in the From: line and the
real users address in the Reply-To: line.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] oi_151a9 roadmap planning

[Alan Coopersmith]

On 02/12/14 11:42 PM, Jean-Pierre André wrote:

Hi,

Alan Coopersmith wrote:

On 02/12/14 12:41 PM, Peter Tribble wrote:

(Ideally, you want other communities to build and distribute software
for you. That's one area where IPS is a huge obstacle - all this
repository stuff is an intolerable burden on third parties,


Nearly all package systems have repositories, what makes IPS more
intolerable
than the rest?   (Or had you just not noticed that support for package
archives,
basically tarball versions of IPS packages, was added to IPS in years past?


Oh, great, I did not know.

I have three computers, but the hardware for two of them is
not supported by OI. I can only install OI on third one,
but the WiFi network access is not supported.

So, basically I have to download through Windows or Linux,
but I do not known how to ftp or wget an update, or
anything which is not available in an ISO, from an IPS ?

I am the maintainer of ntfs-3g. How should I deposit an IPS
package on a plain web server I do not control ?
(see http://jp-andre.pagesperso-orange.fr/openindiana-ntfs-3g.html)


Follow the instructions in the link I provided to use pkgrecv to
generate a .p5p archive on the machine you're using to create the
package:


http://docs.oracle.com/cd/E26502_01/html/E21383/pkgcreate.html#gluem


Figuring out how you post a file on a web site you do not control is
your problem to solve - I can't help you there.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] [developer] GSoC? Decision time....

[Alan Coopersmith]

On 02/13/14 07:20 PM, Alexander Pyhalov wrote:

4) at last, port your favorite software.


Remember that GSoC projects are intended to be a full-time job for ~12 weeks
for a student - most ports of software will take a fraction of that time, and
I don't think Google cares much for Port as many packages as you can in a
summer type projects.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] oi_151a9 roadmap planning

[Alan Coopersmith]

On 02/12/14 12:41 PM, Peter Tribble wrote:

(Ideally, you want other communities to build and distribute software
for you. That's one area where IPS is a huge obstacle - all this
repository stuff is an intolerable burden on third parties,


Nearly all package systems have repositories, what makes IPS more intolerable
than the rest?   (Or had you just not noticed that support for package archives,
basically tarball versions of IPS packages, was added to IPS in years past?
It wasn't there in the 0.1 version used in the initial OpenSolaris releases,
but that was what the kids today call Minimum Viable Product not the intended
final state of features.)

http://docs.oracle.com/cd/E26502_01/html/E21383/pkgcreate.html#gluem

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Enlightenment and XCB libraries

[Alan Coopersmith]

On 11/20/13 01:23 PM, Aurélien Larcher wrote:

For instance, Ken Mays and/or Alan Coopersmith, do you possibly have an
input on that ?


Nope - I work upstream from OI, but not on the OI packaging.  I know there
has been work to move OI from the xnv gate to packaging the X11 components
into OI's userland tree, but have not followed it that closely.

All those should build fine from X.Org tarballs - let me know if they don't.
They're all also included in the Solaris (formerly OpenSolaris) releases of
the X gate, though only at 1.9.1 for libxcb, since we haven't brought in 1.9.3
yet:   https://hg.java.net/hg/solaris-x11~x-s12-clone

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] [OpenIndiana-discuss] Studio future in OI (Re: )

[Alan Coopersmith]

On 10/11/13 06:15 AM, Laurent Blume wrote:

Too bad that Sun was not there - but as it happens, some actually good standards
were Not Invented By Sun and yet are useful.


There are mentions of Sun though on the ABI committee page, so it wasn't
completely out of the picture:

http://mentorembedded.github.io/cxx-abi/

Solaris Studio 12.3 dropped support for the oldest of the incompatible C++
ABI's, the one left from Sun Workshop 4, which couldn't work for C++98 standard
compliant programs:

http://docs.oracle.com/cd/E24457_01/html/E21986/ossrn.html#gljqx

And has announced future versions will similarly drop support for pre-C++98
libraries:

http://docs.oracle.com/cd/E24457_01/html/E21986/ossrn.html#gljri

So hopefully the ABI's will continue converging more as time goes on.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] sigcpp issue

[Alan Coopersmith]

On 10/ 9/13 10:34 AM, Thomas Wagner wrote:

Hi Alexander,

[...]

  As always, I'm the one to blame for it. However, this particular conflict
  could be caused by directory permission.


True, permissions differ. the pkg contents dump of pkg:/sfe/library/g++/sigcpp
prints what we default to.  It should be in sync with what is in /usr.


I don't know how to specify it in RPM spec files, but in native IPS manifests
you can simply choose not to list any directory that's either already created
by another package or is okay to create with the system defaults, and then
you'll never conflict.   If you look in the Solaris 12 branches from Userland
 X11 upstreams, you'll see we've removed many dir lines from manifests
already.

That won't work if you need to set world-writable permissions, sticky bits,
setid bits, etc. but if all you need is 755 root and don't care about the
group because group perms=world perms, it's fine.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Notes on marking python-24 obsolete

[Alan Coopersmith]

On 08/15/13 10:05 PM, Alexander Pyhalov wrote:

Need comments and hints - especially on xvm and SUN VTS. Where do these
consolidations come from?


If I recall correctly, those were both provided only as binary packages,
not sources you could rebuild.   xVM was Sun's Xen hypervisor for Solaris.
SunVTS is the hardware Validation Test Suite, now known as Oracle VTS:
http://docs.oracle.com/cd/E19719-01/index.html

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Copyright for contributors - not in files, OI branded zones, binary compatibility

[Alan Coopersmith]

On 07/22/13 07:30 AM, Garrett D'Amore wrote:

unless it had explicit approval to do so from any joint contributors.


Remember the terms of the Sun Contributor Agreement granted Sun co-ownership
and the right to release the code under any license of Sun's choosing, such
as a proprietary license in any Solaris 10 backport.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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

Re: [oi-dev] Copyright for contributors - not in files, OI branded zones, binary compatibility

[Alan Coopersmith]

On 07/22/13 09:19 AM, Joerg Schilling wrote:

Well, the CDDL does not mention unmodifyable parts,


http://opensource.org/licenses/CDDL-1.0 section 3.3:

   You must include a notice in each of Your Modifications that identifies
   You as the Contributor of the Modification. You may not remove or alter
   any copyright, patent or trademark notices contained within the Covered
   Software, or any notices of licensing or any descriptive text giving
   attribution to any Contributor or the Initial Developer.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

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