Re: [oi-dev] Errors from distro constructor

2019-10-05 Thread Gary Mills
On Wed, Oct 02, 2019 at 08:03:44PM +0200, Michal Nowak wrote:
> 
> We had to put a workaround in place couple weeks ago:
> https://github.com/OpenIndiana/oi-userland/pull/5272/files#diff-0ae6c3c34f4c69bd3afbca4a2db7c821.
> Perhaps you need to pull the fix locally? (My DC build using the
> openindiana.org publisher succeeds.)

The bug is in:

/usr/share/distro_const/boot_archive_archive.py

It builds the boot archive differently for SPARC and non-SPARC
hardware.  The problem is that the python script uses os.system(), in
many places, which re-parses the previously-built command line by the
shell.  The shell does this incorrectly when the file name contains
characters that need to be quoted.  The parsing can be corrected by
surrounding the file names with single quote characters, assuming that
it doesn't already contain quote characters.  A better solution would
be to avoid invoking the shell at all.  After all, the file names are
already correct.

> The better way is to fix our Python 3 pkg:
> https://www.illumos.org/issues/11636.

The python 2.7 script is built and installed as part of the distro
constructor consolidation.  Fixes are difficult for this old version
of python.


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

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


[oi-dev] Errors from distro constructor

2019-10-02 Thread Gary Mills
When I ran distro_const the other day I got these errors:

# distro_const build text_mode_sparc.xml
...
 ba-config: Boot archive configuration 
ln: 
/mnt/misc/etc/certs/CA/T\xc3\x9c\x42\xC4\xB0TAK_UEKAE_K\xC3\xB6k_Sertifika_Hizmet_Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1_-_S\xC3\xBCr\xC3\xBCm_3.pem:
 cannot link to 
etc/certs/CA/T\xc3\x9c\x42\xC4\xB0TAK_UEKAE_K\xC3\xB6k_Sertifika_Hizmet_Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1_-_S\xC3\xBCr\xC3\xBCm_3.pem
 [File exists]
ln: /mnt/misc/etc/certs/CA/AC_Ra\xC3\xADz_Certic\xC3\xA1mara_S.A..pem: 
cannot link to etc/certs/CA/AC_Ra\xC3\xADz_Certic\xC3\xA1mara_S.A..pem [File 
exists]
 plat-setup: Platform specific setup 
 ba-arch: Boot archive archiving 
342288 blocks
fiocompress: cannot open 
./etc/certs/CA/Txc3x9cx42xC4xB0TAK_UEKAE_KxC3xB6k_Sertifika_Hizmet_SaxC4x9Flayxc4xb1x63xc4xb1sxc4xb1_-_SxC3xBCrxC3xBCm_3.pem
 - No such file or directory
/usr/share/distro_const/boot_archive_archive.py: error compressing file 
./etc/certs/CA/T\xc3\x9c\x42\xC4\xB0TAK_UEKAE_K\xC3\xB6k_Sertifika_Hizmet_Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1_-_S\xC3\xBCr\xC3\xBCm_3.pem:
 Unknown error
fiocompress: cannot open 
./etc/certs/CA/AC_RaxC3xADz_CerticxC3xA1mara_S.A..pem - No such file or 
directory
/usr/share/distro_const/boot_archive_archive.py: error compressing file 
./etc/certs/CA/AC_Ra\xC3\xADz_Certic\xC3\xA1mara_S.A..pem: Unknown error
sh: syntax error at line 1: `(' unexpected
/usr/share/distro_const/boot_archive_archive.py: error compressing file 
./etc/certs/CA/NetLock_Arany_(Class_Gold)_Főtanúsítvány.pem: No such process
Traceback (most recent call last):
  File "/usr/share/distro_const/boot_archive_archive.py", line 445, in 

compress(BA_BUILD, BA_LOFI_MNT_PT)
  File "/usr/share/distro_const/boot_archive_archive.py", line 185, in 
compress
"compressed boot_archive files")
Exception: /usr/share/distro_const/boot_archive_archive.py: Error 
processing compressed boot_archive files
Child returned err 1
Build completed Tue Oct  1 15:21:35 2019
Build failed.

As far as I can tell, the python script reinterprets the manifests,
but does it incorrectly.  In fact, the shell seems to be involved too.
Enclosing the file name in single quotes allows `ls -l' to find it.

I can correct the problem by omitting the relevant lines from the
crypto-ca-certificates.p5m manifest, but is there a better way?


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

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


Re: [oi-dev] Download error for dlc.openindiana.org

2019-09-01 Thread Gary Mills
On Sun, Sep 01, 2019 at 05:15:49PM -0400, Richard Lowe wrote:
> Something seems wrong with the DLC host.  And, more annoying for you,
> the upstream seems to have deleted or moved that source so the build
> was falling back to DLC.

Yes, that's what I suspected.  It's also why it only happens sometimes.

> A workaround would be to find an alternate source for the
> cracklib-2.9.6 tarball.

That's what I've done.


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

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


[oi-dev] Download error for dlc.openindiana.org

2019-09-01 Thread Gary Mills
Lately, I've been getting this error:

$ gmake download
.../oi-userland-jan/tools/userland-fetch --file
.../oi-userland-jan/archives/cracklib-2.9.6.tar.gz --url

https://github.com/cracklib/cracklib/releases/download/cracklib-2.9.6/cracklib-2.9.6.tar.gz
--hash
sha256:17cf76943de272fd579ed831a1fd85339b393f8d00bf9e0d17c91e972f583343
Source .../oi-userland-jan/archives/cracklib-2.9.6.tar.gz... not found, 
skipping file copy
Source 
https://github.com/cracklib/cracklib/releases/download/cracklib-2.9.6/cracklib-2.9.6.tar.gz...
 
downloading... I/O Error: Can't open url 
https://github.com/cracklib/cracklib/releases/download/cracklib-2.9.6/cracklib-2.9.6.tar.gz:
 
HTTP Error 404: Not Found
failed
Source 
http://dlc.openindiana.org/oi-userland/source-archives/cracklib-2.9.6.tar.gz... 
downloading... I/O Error: Can't open url 
http://dlc.openindiana.org/oi-userland/source-archives/cracklib-2.9.6.tar.gz: 

failed
gmake: *** [.../oi-userland-jan/make-rules/prep-download.mk:76: 
.../oi-userland-jan/archives/cracklib-2.9.6.tar.gz] Error 1

What's gone wrong?


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

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


Re: [oi-dev] How to create an ISO correctly?

2019-08-27 Thread Gary Mills
On Tue, Aug 27, 2019 at 10:06:11AM +0300, Toomas Soome via oi-dev wrote:
>On 27 Aug 2019, at 00:46, Gary Mills <[1]gary_mi...@fastmail.fm> wrote:
> 
> >  Finally, how do I create a USB image from the CD image?
> 
>it is generated from iso with help of
>/usr/share/distro_const/create_usb, which in turn is using /bin/usbgen,
>but at this time, it is all about x86. So the SPARC updates have to be
>implemented still. The code is
>in [4]https://github.com/OpenIndiana/slim_source.

I built slim_source on SPARC, except for the GUI parts.  I see both
create_iso and create_usb scripts in /usr/share/distro_const .  The
only platform-specific code is in create_iso .  I'll find out how they
work when I run distro_const, I suppose.


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

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


Re: [oi-dev] How to create an ISO correctly?

2019-08-27 Thread Gary Mills
On Tue, Aug 27, 2019 at 08:56:54AM +0200, Volker A. Brandt wrote:
> 
> Have you looked at the XML files in the /usr/share/distro_const tree?
> Maybe it is enough just to replace the current publisher and origin
> with the values of your new repository?

Yes, that apparently works.

> Not sure if I understand this... you have installed lots of oi-userland
> packages but your publisher is still v9os?  Surely you *also* have 
> oi-userland as a publisher.  Just delete all references to v9os.

This is my publisher on the host system now:

# pkg publisher
PUBLISHER   TYPE STATUS P LOCATION
oi-userland origin   online F 
file:///export/home/mills/Downloads/code/oi-userland/sparc/repo/
v9os   (non-sticky) origin   online F file:///data/ips/

Yes, I can delete the v9os publisher now, leaving only oi-userland .
It's still not the same as the publisher on the ISO, though.  I
understand that the two being different is quite normal.

> If all else fails you can manually edit the "master" file located in
> /var/pkg/pkg5.image, clean all the caches and do a "pkg refresh --full".
> That might kill your kitten^WT2000 though.  YMMV :-)

I understand that there are pkg commands that will make changes to the
file repositories with less risk to the kitten.  I do want to publish
the repository along with the ISO, just as done with v9os.  The two of
them have to work together.  That's why I enquired about changing the
publisher that's stated in the file repostory.


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

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


Re: [oi-dev] How to create an ISO correctly?

2019-08-27 Thread Gary Mills
On Mon, Aug 26, 2019 at 11:58:42PM +0200, Aurélien Larcher wrote:
> 
>If you look at:
>[4]https://hipster.openindiana.org/distro_const/text_mode_x86-minimal.x
>ml
>pkg_repo_default_authority specifies the repository from which the
>packages are pulled and thus the image created, while
>post_install_repo_default_authority stands for the default publisher
>configured on the ISO itself.

So, they can be different.  That makes it easy for me.

Is that the same as:

/usr/share/distro_const/text_install/text_mode_x86_minimal.xml

which was installed when I installed the distribution-constructor
package?

What should be the publisher name?  I see that it's openindiana.org in
the /usr/share/distro_const/text*.xml files.

>There are packages like this that can be published from metapackage/
>components.
>For regular Jenkins jobs `gmake -C components incorporation` is called
>after publication of new packages to generate such meta-packages.

Thanks.  I'll look into that procedure.

>At least on x86 both usb images and cd iso are created by distro_const.

I suppose I'll find out the first time I run it.


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

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


[oi-dev] How to create an ISO correctly?

2019-08-26 Thread Gary Mills
Another progress report and some questions: I have now replaced all
v9os packages with oi-userland packages.  There are no v9os packages
left.  My T2000 has only oi-userland packages, ones that I have built.
It boots correctly.  The publisher name is oi-userland, not the usual
userland or openindiana.org .  That difference raises my first
question.

I've read the information on distribution-constructor:

http://docs.openindiana.org/dev/distribution-constructor/

as well as the man page for distro_const .  Neither of them answered
my questions completely.

Will distro_const change the publisher in the ISO file, both for the
packages and the `pkg publisher' command?  How do I do this?

If not, can the publisher be changed on the host system?  Does the
publisher in `pkg publisher' have to match the one in the file
repository?

I see that the XML file used by distro_const specifies `entire' as the
package that includes all the packages to install to the ISO file.
My system has no package `entire'.  How do I create and populate it?
Will it include some packages that do not exist?  Will this be a
problem?

Finally, how do I create a USB image from the CD image?


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

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


Re: [oi-dev] Pecular dependancies in publishing print/cups-filters

2019-08-16 Thread Gary Mills
On Thu, Aug 15, 2019 at 07:54:08AM -0500, Gary Mills wrote:
> On Thu, Aug 15, 2019 at 03:52:23AM +, Alexander Pyhalov via oi-dev wrote:
> > What are RUNPATH and RPATH of usr/lib/cups/filter/pdftopdf file ?
> 
> They are both /usr/gcc/6/lib:/usr/lib/libjpeg6-ijg/lib .  The jpeg
> element is not used in the case of the three filters that appeared
> in the publish error messages.  I can remove it with elfedit if this
> will solve the problem.

Well, that worked.  I got a successful publish operation when I used
elfedit to replace RUNPATH and RPATH in those three files.


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

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


Re: [oi-dev] Pecular dependancies in publishing print/cups-filters

2019-08-15 Thread Gary Mills
On Thu, Aug 15, 2019 at 03:52:23AM +, Alexander Pyhalov via oi-dev wrote:
> What are RUNPATH and RPATH of usr/lib/cups/filter/pdftopdf file ?

They are both /usr/gcc/6/lib:/usr/lib/libjpeg6-ijg/lib .  The jpeg
element is not used in the case of the three filters that appeared
in the publish error messages.  I can remove it with elfedit if this
will solve the problem.


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

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


Re: [oi-dev] Pecular dependancies in publishing print/cups-filters

2019-08-14 Thread Gary Mills
On Wed, Aug 14, 2019 at 04:14:51PM +0200, Aurélien Larcher wrote:
>On Wed, Aug 14, 2019 at 4:11 PM Aurélien Larcher
><[1]aurelien.larc...@gmail.com> wrote:
> 
>The error tells you that no package in the REQUIRED_PACKAGES list
>provides a suitable dependency.

Well, that's what it usually means.  In this case:

depend type=require fmri=__TBD \
pkg.debug.depend.fullpath=usr/lib/libjpeg6-ijg/lib/libgcc_s.so.1 \
pkg.debug.depend.reason=usr/lib/cups/filter/pdftopdf \
pkg.debug.depend.type=elf'.

what is pkg looking for?  Is it libgcc_s.so.1?  That's in the
system/library/gcc-6-runtime package, which is in the
REQUIRED_PACKAGES list.  Or, is it
usr/lib/libjpeg6-ijg/lib/libgcc_s.so.1?  That is not in any package.


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

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


Re: [oi-dev] Pecular dependancies in publishing print/cups-filters

2019-08-14 Thread Gary Mills
On Wed, Aug 14, 2019 at 04:11:47PM +0200, Aurélien Larcher wrote:
>On Wed, Aug 14, 2019 at 3:58 PM Gary Mills <[1]gary_mi...@fastmail.fm>
>wrote:
> 
>Look in the Makefile, it should use image/library/libjpeg8-turbo not
>libjpeg6-ijg.

I've already changed JPEG_IMPLEM in shared-macros.mk to be
libjpeg6-ijg .  I also added both image/library/libjpeg6 and
image/library/libjpeg6-ijg to REQUIRED_PACKAGES in the Makefile.

>Probably it is not installed on your system, execute gmake env-prep.

I built both jpeg packages but only installed the libjpeg6-ijg package.

The publish transcript I submitted was from after I made all of those
changes.

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

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


Re: [oi-dev] Pecular dependancies in publishing print/cups-filters

2019-08-14 Thread Gary Mills
On Wed, Aug 14, 2019 at 10:39:22AM +0200, Till Wegmüller wrote:
> 
> PKG uses it's own PATH variable to find libraries. Think of -I for GCC
> for example. And that has been modified to include
> usr/lib/libjpeg6-ijg/lib already but now also needs usr/gcc/6/lib to be
> added.

Are you saying that pkg does not use the runtime path from the ELF
section at all?  The runtime linker certainly uses that.

/usr/gcc/6 is the default compiler for the 2018 version of OI that I'm
using.  Surely that element is already in the runtime path that's used
by pkg.  I'd expect that jpeg library path to be the one that's
absent.

> You can override that by either:
> - Setting the dependency in the manifest manually and add
> pkg.depend-bypass to the files that complain or
> - Modify the Include path PKG searches. I am however unsure which exact
> knob in oi-userland to tweak here.

Do you have examples from other packages of these two techniques?
I'd like to start with something that works.

> You should see the override either in the Makefile or the Manifest look
> for "usr/lib/libjpeg6-ijg/lib" mentioned there.

There's nothing in either for the print/cups-filters package.


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

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


[oi-dev] Pecular dependancies in publishing print/cups-filters

2019-08-13 Thread Gary Mills
I'm attempting to publish the print/cups-filters package.  The build
and install were successful, but I get these peculiar errors with the
publish stage:

.../components/print/cups-filters/build/manifest-sparc-cups-filters.depend has 
unresolved dependency '
depend type=require fmri=__TBD \
pkg.debug.depend.fullpath=usr/lib/libjpeg6-ijg/lib/libgcc_s.so.1 \
pkg.debug.depend.reason=usr/lib/cups/filter/pdftopdf \
pkg.debug.depend.type=elf'.
.../components/print/cups-filters/build/manifest-sparc-cups-filters.depend has 
unresolved dependency '
depend type=require fmri=__TBD \
pkg.debug.depend.fullpath=usr/lib/libjpeg6-ijg/lib/libgcc_s.so.1 \
pkg.debug.depend.reason=usr/lib/cups/filter/rastertopdf \
pkg.debug.depend.type=elf'.
.../components/print/cups-filters/build/manifest-sparc-cups-filters.depend has 
unresolved dependency '
depend type=require fmri=__TBD \
pkg.debug.depend.fullpath=usr/lib/libjpeg6-ijg/lib/libgcc_s.so.1 \
pkg.debug.depend.reason=usr/lib/cups/filter/urftopdf \
pkg.debug.depend.type=elf'.

The RUNPATH for all three filters is like this:

/usr/gcc/6/lib:/usr/lib/libjpeg6-ijg/lib

The libgcc_s.so.1 module is, of course, in /usr/gcc/6/lib .  The
runtime linker finds it there.  Only libjpeg.so.62 and friends are in
/usr/lib/libjpeg6-ijg/lib , but the three filters are not using any
jpeg libraries.  That particular element of the path is unused.  The
GCC libraries are certainly not there.

So, what is this error message really telling me?  I can remove the
unused path element with elfedit, if that will help.  Will it?


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

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


Re: [oi-dev] Am I stuck?

2019-07-01 Thread Gary Mills
On Tue, Jun 25, 2019 at 08:42:41PM -0400, Richard Lowe wrote:
> Reason:  No version for 'require' dependency on system/mta can be found
> 
> Seems a leaf failure, does one really not exist?

Yes, that was the problem.  Package system/mta was missing.  When I
built and installed, it the update looked much better:

# pkg update -n   
Packages to remove:   3
   Packages to install:  10
Packages to update: 300
Packages to change:   1
   Mediators to change:   1
   Create boot environment: Yes
Create backup boot environment:  No

However, I was stymied by the next error when I tried an update in
the usual manner:

# pkg update --be-name oi-20190626

pkg update: Boot environment naming during package install is not supported 
on this
version of OpenSolaris. Please update without the --be-name option.

When I tried it as suggested, I got this error:

# pkg update 
Packages to remove:   3
   Packages to install:  10
Packages to update: 299
Packages to change:   1
   Mediators to change:   1
   Create boot environment: Yes
Create backup boot environment:  No

DOWNLOADPKGS FILESXFER (MB)   
SPEED
Completed313/313 8647/8647  111.4/111.4
0B/s

pkg: Unable to clone the current boot environment.

Finally, I used `beadm create' to do the clone, and `pkg -R /mnt
update' to do the update on the newly-created BE.  After I rebuilt the
boot archive on the clone and activated it, it booted nicely.  All of
the illumos-gate packages had been replaced with newly-published
versions.

I don't know what caused the boot environment naming problem.


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

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


Re: [oi-dev] Am I stuck?

2019-06-26 Thread Gary Mills
On Tue, Jun 25, 2019 at 08:42:41PM -0400, Richard Lowe wrote:
> Reason:  No version for 'require' dependency on system/mta can be found
> 
> Seems a leaf failure, does one really not exist?

Indeed, the package system/mta does not exist in either publisher.  I
just published it to oi-userland and installed it.  My next task is to
see if that missing package was preventing the update.


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

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


Re: [oi-dev] Am I stuck?

2019-06-25 Thread Gary Mills
On Tue, Jun 25, 2019 at 11:01:31PM +0200, Volker A. Brandt wrote:
> 
> So it appears that pkg does not recognize the fact that version
> 0.5.11-2018.0.0.0:20190623T223519Z is newer than version
> 0.5.11-0.151100:20160727T071237Z -- correct?

I don't think that that is the problem.  Consider this transcript:

# pkg update -nv
...
Changed packages:
...
v9os -> oi-userland
  archiver/gnu-tar
1.28-0.151100 -> 1.29-2018.0.0.0
  compress/bzip2
1.0.6-0.151100 -> 1.0.6-2018.0.0.3
  compress/gzip
1.6-0.151100 -> 1.9-2018.0.0.0

The version numbers were the same for the last two packages.

> > When I tried to remove the incorporation with pkg, I got this result:
> [...]
> 
> I don't think that you are supposed to be able to remove the package
> altogether.  You should, hovewer, be able to update it.

That's close to working.  I should be able to make it work.
Here's this one:

# pkg update -nv pkg://oi-userland/consolidation/osnet/osnet-inco...
Creating Plan (Solver setup): \
pkg update: No matching version of consolidation/osnet/osnet-incorporation 
can be installed:
  Reject:  
pkg://oi-userland/consolidation/osnet/osnet-incorporation@0.5.11-2018.0.0.0
  Reason:  No version matching 'incorporate' dependency 
SUNWcs@0.5.11-2018.0.0.0 can be installed

Reject:  pkg://oi-userland/SUNWcs@0.5.11-2018.0.0.0
Reason:  No version matching 'require' dependency 
system/network/mailwrapper can be installed
  
  Reject:  
pkg://oi-userland/system/network/mailwrapper@0.5.11-2018.0.0.0
  Reason:  No version for 'require' dependency on system/mta can be 
found
  Reject:  pkg://v9os/system/network/mailwrapper@0.5.11-0.151100
  Reason:  Excluded by proposed incorporation 
'consolidation/osnet/osnet-incorporation'
  


> Do you also have an "entire" package?  If so, what version does it
> have?

No, I don't have that package.


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

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


[oi-dev] Am I stuck?

2019-06-25 Thread Gary Mills
These are my publishers:

# pkg publisher  
PUBLISHER   TYPE STATUS P LOCATION
oi-userland origin   online F 
file:///export/home/mills/Downloads/code/oi-userland/sparc/repo/
v9os   (non-sticky) origin   online F file:///data/ips/

I just published all of illumos-gate to the oi-userland repository.
There are now two copies of the
consolidation/osnet/osnet-incorporation package.  This is the
installed one:

# pkg info consolidation/osnet/osnet-incorporation
  Name: consolidation/osnet/osnet-incorporation
   Summary: OS/Net consolidation incorporation
   Description: This incorporation constrains packages from the OS/Net
consolidation.
 State: Installed
 Publisher: v9os
   Version: 0.5.11
Branch: 0.151100
Packaging Date: Wed Jul 27 07:12:37 2016
  Size: 0.00 B
  FMRI: 
pkg://v9os/consolidation/osnet/osnet-incorporation@0.5.11-0.151100:20160727T071237Z

This is the new one:

# pkg info -r consolidation/osnet/osnet-incorporation
  Name: consolidation/osnet/osnet-incorporation
   Summary: OS/Net consolidation incorporation
   Description: This incorporation constrains packages from the OS/Net
consolidation.
 State: Not installed
 Publisher: oi-userland
   Version: 0.5.11
Branch: 2018.0.0.0
Packaging Date: Sun Jun 23 22:35:19 2019
  Size: 0.00 B
  FMRI: 
pkg://oi-userland/consolidation/osnet/osnet-incorporation@0.5.11-2018.0.0.0:20190623T223519Z

I expected that `pkg update -nv' would offer to remove the installed
incorporation and replace all of the old illumos-gate packages, over
200 of them, with the new illumos-gate packages.  It didn't do that.
It did report that it would replace ten packages from the v9os
publisher with newer versions from the oi-userland publisher, but this
list didn't include any of the illumos-gate packages.

When I tried to remove the incorporation with pkg, I got this result:

# pkg uninstall -nv consolidation/osnet/osnet-incorporation
Creating Plan (Solver setup): -
pkg uninstall: Unable to remove 
'consolidation/osnet/osnet-incorporation@0.5.11-0.151100' due to the following 
packages that depend on it:
  SUNWcs@0.5.11-0.151100
  SUNWcsd@0.5.11-0.151100
  compatibility/ucb@0.5.11-0.151100
  developer/astdev@0.5.11-0.151100
...
  system/zones@0.5.11-0.151100
  system/zones/internal@0.5.11-0.151100
  text/doctools@0.5.11-0.151100
  text/locale@0.5.11-0.151100

Have I run into a dead end, or is there a way out of this dilemma?


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

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


Re: [oi-dev] Toward a SPARC distro of OI

2019-06-24 Thread Gary Mills
On Mon, Jun 17, 2019 at 01:26:59PM +0200, Aurélien Larcher wrote:
> 
>Congratulations Gary this is great :)
>If we get to the point that we can setup a build machine this would
>secure your work.

Thanks.  That will be a big help.  I'd recommend weekly builds, rather
than daily builds.  I'm sure that will be adequate.  My build, when
it's completed, will be at least a year behind the current state of
OI.


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

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


[oi-dev] Toward a SPARC distro of OI

2019-06-17 Thread Gary Mills
I'm part way through this long project now.  I began with v9os
installed on a Sun T2000.  v9os is a SPARC distribution that uses IPS
packages.  I've been building IPS packages from oi-userland source.
This process has gotten easier now that all the build tools I need are
in IPS packages.  I've been replacing v9os packages with oi-userland
packages.  My goal is to replace all of them, and finally to produce a
text ISO and package repository for SPARC that's entirely based on
oi-userland.

So far, I've built and packaged versions 5, 6, and 7 of the gcc
compiler.  The commands for IPS packages are all packaged for python
2.7.  My system now has 106 packages installed from oi-userland,
versus 343 packages from v9os.  Most of the oi-userland products
required very few or no changes to build and package for SPARC.

For perl, I've removed the 5.16.1 version from v9os and installed
versions 5.22 and 5.24 from oi-userland.  Likewise, for python, I've
removed 2.6 and installed 2.7 and 3.4.  Perl libraries are all
packaged for 5.22.  Python libraries are all packaged for 2.7.

I'm submitting this message to the mailing list mostly as a progress
report.  I would, of course, appreciate a bit of help with this
project.


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

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


Re: [oi-dev] Importing data from wiki to oi-docs

2019-05-15 Thread Gary Mills
On Tue, May 14, 2019 at 03:44:56PM +, Alexander Pyhalov via oi-dev wrote:
> 
> I'm asking everyone, creating significant amount of content on wiki
> to look through their pages and - either convert them to markdown,
> update and create corresponding PRs for oi-docs and oi-userland; -
> or mark them as obsolete.

Could you provide instructions on how to do this, for people who
have never created a PR?  Also, how do I locate my pages?


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

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


Re: [oi-dev] pulseaudio issues

2019-04-20 Thread Gary Mills
On Thu, Apr 18, 2019 at 06:26:55AM +, Alexander Pyhalov wrote:

> Thank you for your work. Can you open GitHub pull request against
> http://github.com/OpenIndiana/oi-userland/ with proposed changes?

I've filed a bug report against the newly-discovered permissions
error.  This change can be applied at any time, as it does not affect
any other changes.  See:

Bug #10830: Helper files in pulseaudio-12.2 are not executable
https://www.illumos.org/issues/10830


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

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


Re: [oi-dev] pulseaudio issues

2019-04-18 Thread Gary Mills
On Thu, Apr 18, 2019 at 06:26:55AM +, Alexander Pyhalov wrote:

> Thank you for your work. Can you open GitHub pull request against
> http://github.com/OpenIndiana/oi-userland/ with proposed changes?

I'm not finished yet and not satisfied yet.  All I can do now is to
file a bug report for the newly-discovered bug.


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

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


Re: [oi-dev] pulseaudio issues

2019-04-17 Thread Gary Mills
On Sun, Apr 07, 2019 at 08:47:17PM -0500, Gary Mills wrote:
> 
> Then I tried changing some settings in that GUI application.  When I
> changed Sound theme to `Default', it changed back to `No sounds'.  I
> also tried increasing the output volume.  This display was curious
> because the 100% mark was about 2/3 of the way along the slider.  I
> was able to set it above 100%.  When I checked, the audio had
> disappeared.  Something happened, but I don't know what.  Even when I
> logged out, killed the pulseaudio daemon, and logged in again, I still
> didn't have audio.  So far, I haven't been able to get it back.

I discovered part of the problem.  The commands
usr/lib/pulse/gsettings-helper and its 64-bit equivalent were not
executable.  This omission caused the fork() to succeed but the exec()
to fail in pa_start_child_for_read().  Because there was no logging of
that failure, I was unaware of the problem for some time.  Those
commands read the MATE configuration, in particular the settings in
the Sound Preferences GUI, and pass them on to pulseaudio.  For
example, they are how pulseaudio discovers your volume changes.

I added some code to modules/gsettings/module-gsettings.c that
verifies that the helper command is present and is executable.  This
code solves the visibility problem.  For a temporary fix, I changed
permission on the installed files.  A permanent fix requires appending
`mode=0555' to the two lines of the manifest.

If this bug hasn't already been reported, I'll be happy to file a bug
report and include my patches.


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

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


Re: [oi-dev] pulseaudio issues

2019-04-07 Thread Gary Mills
On Wed, Apr 03, 2019 at 07:11:47AM +, Alexander Pyhalov wrote:

> It seems reasonable. The issue I see is that our mod_oss is almost
> a complete fork of pulseaudio mod_oss. Solaris somehow manages to
> use module_oss without patches, and I honestly don't understand how
> this works.

Here's what I did so far, all in module-detect.  I modified it so that
it obtains the device name from the AUDIODEV contents, defaulting to
/dev/audio .  It then calculates the corresponding dsp device name.
That's because module-oss only works with a dsp device.  Instead of
loading module-solaris, it loads module-oss with the `device='
argument.  I also removed module-oss from the /etc/pulse/default.pa
file.  Pulseaudio had formerly loaded module-oss with no arguments.
I didn't want two copies running.  I tested these changes without
AUDIODEV set in my environment.  They seemed to work, although I
couldn't tell because it defaults to the wrong audio device.

Then I added:

AUDIODEV=/dev/sound/1

and tested it again.  With `tput bel' in a terminal window, I did hear
the beep in my speakers.  It worked.  When I looked at the Sound
Preferences GUI application, it showed the Sound theme set to `No
sounds' and both Input and Output set to /dev/dsp1.  So far, so good.

Then I tried changing some settings in that GUI application.  When I
changed Sound theme to `Default', it changed back to `No sounds'.  I
also tried increasing the output volume.  This display was curious
because the 100% mark was about 2/3 of the way along the slider.  I
was able to set it above 100%.  When I checked, the audio had
disappeared.  Something happened, but I don't know what.  Even when I
logged out, killed the pulseaudio daemon, and logged in again, I still
didn't have audio.  So far, I haven't been able to get it back.


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

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


Re: [oi-dev] pulseaudio issues

2019-04-02 Thread Gary Mills
On Tue, Apr 02, 2019 at 04:19:29PM +0200, Udo Grabowski (IMK) wrote:
> 
> On OI_151a versions this has always been OSS and it worked - so
> if pulse audio only delivers a "Linux version" of OSS this should
> be fixed. Please don't fall back to ancient mod_solaris, that was
> history already ten years ago...

So, the consensus is that I chose the wrong horse to ride.  The
problem begins with the OI Makefile, which contains:

CONFIGURE_OPTIONS += --enable-oss-output
CONFIGURE_OPTIONS += --enable-solaris

It indirectly enables two output modules.  These options only set two
preprocessor variables: HAVE_OSS_OUTPUT and HAVE_SOLARIS,
respectively.  It's module-detect.c that first uses these variables.
That module calls both detect_oss() and detect_solaris() to determine
the device names.  detect_oss() always fails because of an error
reading the status device.  detect_solaris() succeeds by setting the
device name to the contents of AUDIODEV or to /dev/audio if it's
empty.  It loads module-solaris as the active output module.

I'm willing to fix module-detect.c so that it determines the device
name correctly on illumos/OI and that it loads module-oss instead.  I
can test module-oss on a system with one audio device, and on one that
has two devices.  The first change will have to be the OI Makefile, of
course.  No doubt there will be changes to module-oss as well.  Is
that what people want?  There's no simple solution.


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

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


Re: [oi-dev] pulseaudio issues

2019-04-02 Thread Gary Mills
On Tue, Apr 02, 2019 at 12:48:03PM +, Alexander Pyhalov wrote:

> I've looked through libmatemixer and pulseaudio sources once again
> to recollect exact issue. Now I see, the original issue is the
> following: mod_solaris doesn't have means to set device volume (it
> gets volume via AUDIO_GETINFO sysctl, and this has no any relation
> to real audioctl volume setting, controlled via /dev/mixer.

On illumos, /dev/mixer is simply a symlink to /dev/sndstat .  Here's
what I get by reading that device:

$ cat /dev/mixer  
SunOS Audio Framework

Audio Devices:
0: audiohd#0 onboard1, a (DUPLEX)
1: audiohd#1 onboard1, a (DUPLEX)

Mixers:
0: audiohd#0 onboard1, a
HD codec: ATI R600 HDMI
1: audiohd#1 onboard1, a
Unknown HD codec: 0x10ec0887

The hardware mixers are /dev/mixer0 and /dev/mixer1 on my system.

The relevant man page for /dev/mixer is MIXER(7I).  It says, in part:

   The /dev/mixer pseudo-device is provided for two purposes:

   o  The first purpose is for applications that wish to learn
  about the list of audio devices on the system, so that they
  can select (or provide for users to select) an appropriate
  audio device. The /dev/mixer pseudo-device provides
  interfaces to enumerate all of the audio devices on the
  system.

   o  The second purpose is for mixer panel type applications
  which need to control master settings for the audio hardware
  in the system, such as gain levels, balance, port
  functionality, and other device features.

and:

   The /dev/sndstat device supports read(2), and can be read to retrieve
   human-readable information about the audio devices on the system.
   Software should not attempt to interpret the contents of this device.

The IOCTLs for /dev/mixer are also described in detail in this man page.

PS: There is a patch to the audiohd driver up for review that enables
HDMI audio devices to work.


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

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


Re: [oi-dev] pulseaudio issues

2019-04-02 Thread Gary Mills
On Tue, Apr 02, 2019 at 10:54:25AM +, Alexander Pyhalov wrote:

> If selection of device in mate-volume-control works for you, we can
> just make it honor AUDIODEV is it set.

It may already do that, although perhaps not correctly.

> Your patches make pulseaudio use mod_solaris module, and it doesn't
> provide interfaces necessary to select device in
> mate-volume-control. So we either fix mod_solaris to support these
> interfaces or fix our mod_oss patches to honor AUDIODEV.

Yes, mod_solaris seemed most appropriate since illumos was derived
from Solaris.  Mod_oss seems to be for the Linux version of OSS.

The second of the two was what my patch did.

> Sorry, I don't remember details about what interfaces are needed,
> but one should start digging from libmatemixer pulse backend.

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

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


Re: [oi-dev] pulseaudio issues

2019-04-01 Thread Gary Mills
On Mon, Apr 01, 2019 at 08:04:00AM +, Alexander Pyhalov wrote:

> Gary, I've opened
> https://github.com/OpenIndiana/oi-userland/pull/4922 to discuss your
> proposed changes to pulseaudio.

Thanks.  That will help.

> I honestly don't understand them. I mean, if we accept these
> changes, what use do we have from mod_oss (and our giant patch to
> it)?

My changes are in addition to that patch and modify the same file.

> I've resurrected this patch from JDS when understood that
> current mod_solaris have no means to enumerate and select audio
> devices and just uses AUDIODEV (or /dev/audio). How user is supposed
> to change audio device?

It is possible to enumerate audio devices.  They are all called
/dev/sound/[0-9], where the number is the instance number.  The other
devices have that number embedded in the name.  /dev/audio is simply a
symlink to /dev/sound/0 .

That's the way to select them, with the AUDIODEV environment variable.
It's explained in two existing man pages.  audio(7i) says this:

   Because some systems may contain more than one audio device,
   application writers are encouraged to query the AUDIODEV environment
   variable. If this variable is present in the environment, its value
   should identify the path name of the default audio device.

audioctl(1) says:

   AUDIODEV
   The full path name of the default audio device to use if
   one is not specified on the command line.  If this variable
   is not set, /dev/audio is used.

The login GUI sources several files to set the environment for
application GUIs.  The .profile file is the usual place for the user
to set environment variables.


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

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


Re: [oi-dev] Sendmail logging to wrong facility

2018-09-20 Thread Gary Mills
On Tue, Sep 18, 2018 at 03:57:13PM -0500, Gary Mills wrote:
> 
> Yes, I thought of dtrace too, but that's as far as I got.  I'm not
> at all familiar with dtrace.

I found out that dtrace is one of my friends.

> I need something that would enable the MTA service and then display
> the openlog() function calls, showing me the calling function for each
> of them.  That should tell me what is changing the syslog facility.

The culprit seems to be usr/src/lib/pkcs11/pkcs11_tpm/common/apiutil.c
in illumos.  Yes, it's an illumos bug that's doing it.


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

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


Re: [oi-dev] Sendmail logging to wrong facility

2018-09-18 Thread Gary Mills
On Tue, Sep 18, 2018 at 10:26:12PM +0300, Toomas Soome wrote:
> 
> > On 18 Sep 2018, at 22:24, Gary Mills  wrote:
> > 
> > On Tue, Sep 18, 2018 at 09:57:40PM +0300, Toomas Soome via oi-dev wrote:
> >> 
> >>   var/log/daemon.6:Aug  1 12:48:19 beastie sendmail[1189]: [ID 702911
> >>   [7]daemon.info] starting daemon (8.14.4+Sun): SMTP+queueing@00:15:00
> > 
> >>   apparently the daemon part is logging using daemon facility.
> > 
> > Yes, that's the problem.  How do I determine what's causing it?
> > It's likely not sendmail itself.
> > 
> 
> daemon() call? I guess dtrace would help.

Yes, I thought of dtrace too, but that's as far as I got.  I'm not
at all familiar with dtrace.

I need something that would enable the MTA service and then display
the openlog() function calls, showing me the calling function for each
of them.  That should tell me what is changing the syslog facility.


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

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


Re: [oi-dev] Sendmail logging to wrong facility

2018-09-18 Thread Gary Mills
On Tue, Sep 18, 2018 at 09:57:40PM +0300, Toomas Soome via oi-dev wrote:
> 
>var/log/daemon.6:Aug  1 12:48:19 beastie sendmail[1189]: [ID 702911
>[7]daemon.info] starting daemon (8.14.4+Sun): SMTP+queueing@00:15:00

>apparently the daemon part is logging using daemon facility.

Yes, that's the problem.  How do I determine what's causing it?
It's likely not sendmail itself.


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

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


Re: [oi-dev] Sendmail logging to wrong facility

2018-09-18 Thread Gary Mills
On Tue, Sep 18, 2018 at 06:03:48PM +0100, Jonathan Adams wrote:
>add this to your syslog.conf:
>mail.info;daemon.info�  �  �  �  �  � ifdef(`LOGHOST',
>/var/log/syslog, @loghost)

So, you had the same problem.  Good.  It exists.  Thanks for that
information.

>I found it out by adding every possible log format to the file until I
>could work out what had changed.

I don't like your workaround, however:

$ grep sendmail /var/adm/messages | wc -l
  56
$ grep daemon.info /var/adm/messages | wc -l
   11624

I'm mainly trying to work out what had changed.

My original question was:

How do I determine the caller?  I need to examine the startup of the
MTA, as that's where the openlog() calls occur.


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

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

Re: [oi-dev] Sendmail logging to wrong facility

2018-09-18 Thread Gary Mills
On Tue, Sep 18, 2018 at 05:57:07PM +0200, Udo Grabowski (IMK) wrote:
> On 18/09/2018 17:15, Gary Mills wrote:
> > I'm using the sendmail supplied with OI-hipster with my own
> > configuration files.  It works correctly except that the MTA daemon
> > logs to the wrong facility.  Specifically, the client sendmail logs to
> > the mail facility, which syslog sends to /var/log/syslog, but the
> > sendmail MTA logs to the daemon facility, which syslog sends to
> > /var/adm/messages .  Has anyone else noticed this anomaly?  The entire
> > sendmail logging should be in /var/log/syslog .

> Have a look into /etc/syslog.conf, there are rules affecting the
> mail client and server logging:

That's the first place I looked.  It's not the cause of this problem.
Something is changing the syslog facility.


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

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


[oi-dev] Sendmail logging to wrong facility

2018-09-18 Thread Gary Mills
I'm using the sendmail supplied with OI-hipster with my own
configuration files.  It works correctly except that the MTA daemon
logs to the wrong facility.  Specifically, the client sendmail logs to
the mail facility, which syslog sends to /var/log/syslog, but the
sendmail MTA logs to the daemon facility, which syslog sends to
/var/adm/messages .  Has anyone else noticed this anomaly?  The entire
sendmail logging should be in /var/log/syslog .

The sendmail source contains two instances of this code:

openlog(SM_LOG_STR, LOG_PID, LOG_MAIL);

That code sets the facility that will be used by subsequent syslog()
calls by storing it into a static structure.  The same sendmail source
is used for both the client and MTA servers.  It looks correct.

My suspicion is that something is calling openlog() again with the
wrong facility.  I used truss to show the openlog() function like
this:

7411/1@1: -> libc:openlog(0x80f62a1, 0x1, 0x10, 0x8064d4c)

but it only shows the called function in libc.  How do I determine the
caller?  I need to examine the startup of the MTA, as that's where the
openlog() calls occur.


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

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


[oi-dev] What to do about missing aclocal and automake versions?

2018-06-24 Thread Gary Mills
While building openindiana/illumos-gcc, I noticed these errors during
the build of the mpfr component:

WARNING: `aclocal-1.11' is missing on your system.  You should only need it if
 you modified `acinclude.m4' or `configure.ac'.  You might want
 to install the `Automake' and `Perl' packages.  Grab them from
 any GNU archive site.
...
WARNING: `automake-1.11' is missing on your system.  You should only need it if
 you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
 You might want to install the `Automake' and `Perl' packages.
 Grab them from any GNU archive site.

These versions are not available in the oi-userland repository.  The
expected reconfigure is not done.

The version number comes from the first field of this line in
configure.ac:

AM_INIT_AUTOMAKE([1.11 no-define dist-bzip2 dist-xz dist-zip])

It's supposed to be the minimum auto tools version needed to build
the product.  However, it seems to be used as the required version,
according to these lines in configure:

ACLOCAL=${ACLOCAL-"${am_missing_run}aclocal-${am__api_version}"}
AUTOMAKE=${AUTOMAKE-"${am_missing_run}automake-${am__api_version}"}

The corresponding lines in Makefile are:

ACLOCAL = ${SHELL} 
/export/home/mills/Downloads/code/oi-userland/components/openindiana/illumos-gcc/illumos-gcc-0f5ed4c/mpfr/missing
 --run aclocal-1.11
AUTOMAKE = ${SHELL} 
/export/home/mills/Downloads/code/oi-userland/components/openindiana/illumos-gcc/illumos-gcc-0f5ed4c/mpfr/missing
 --run automake-1.11

What is the correct solution here?


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

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


Re: [oi-dev] GCC error building pkg on SPARC

2018-06-06 Thread Gary Mills
On Tue, Jun 05, 2018 at 10:51:49AM -0500, Gary Mills wrote:
> I'm attempting to build the pkg package on a T2000 (SPARC).  I get
> this error on the first compile:
[...]
> gcc: may not use both -m32 and -m64
> 
> Apparently, x86 builds do not have this problem because gcc on x86
> allows both architecture arguments, even though they conflict.
[...]
> It should be removing the first `-m32' when it adds `-m64' to the
> command line, and restoring it afterwards.

This turns out to be the wrong place to make this change.  That's
because the `-m32' argument is not in the ext.extra_compile_args
list.  It's in the initial portion of the command line, which is
taken from the 32-bit python Makefile.  I suppose that distutils
should be using the 64-bit Makefile instead.

I don't know how to accomplish this either.


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

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


[oi-dev] GCC error building pkg on SPARC

2018-06-05 Thread Gary Mills
I'm attempting to build the pkg package on a T2000 (SPARC).  I get
this error on the first compile:

/usr/gcc/4.4.4/bin/gcc -fno-strict-aliasing -m32 -O3 -mno-app-regs
-fPIC -DPIC -std=c99 -D_XOPEN_SOURCE=600 -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -fPIC -DPIC -Imodules -I/usr/include/python2.7 -c
modules/actions/_actions.c -o

/dpool/export/home/mills/Downloads/code/oi-userland-apr/components/openindiana/pkg/pkg/proto/build_sparc/temp64.solaris-2.11-sun4v.32bit-2.7/modules/actions/_actions.o
-O3 -D__EXTENSIONS__ -Werror -m64

gcc: may not use both -m32 and -m64

Apparently, x86 builds do not have this problem because gcc on x86
allows both architecture arguments, even though they conflict.  The
extra argument is added by this code in pkg/src/setup.py:

# Set up for 64-bit
old_build_temp = self.build_temp
d, f = os.path.split(self.build_temp)

# store our 64-bit extensions elsewhere
self.build_temp = d + "/temp64.{0}".format(
os.path.basename(self.build_temp).replace("temp.", ""))
ext.extra_compile_args += ["-m64"]
ext.extra_link_args += ["-m64"]
self.build64 = True

# Build 64-bit
_build_ext.build_extension(self, ext)

# Reset to 32-bit
self.build_temp = old_build_temp
ext.extra_compile_args.remove("-m64")
ext.extra_link_args.remove("-m64")
self.build64 = False

It should be removing the first `-m32' when it adds `-m64' to the
command line, and restoring it afterwards.

What do I need to change to accomplish this?  I have no experience
in writing Python code.


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

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


Re: [oi-dev] Python 2.7 SPARC build needs an adjusted patch and a new patch

2018-06-04 Thread Gary Mills
On Mon, Jun 04, 2018 at 02:59:40AM +0200, Aurélien Larcher wrote:
> 
>Why not just activate GNU extensions with -std=gnu99?
>Python 2.7 was probably compiled with them until I added -std=c99.

I didn't want to do anything that might affect the x86 build.


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

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


[oi-dev] Python 2.7 SPARC build needs an adjusted patch and a new patch

2018-06-03 Thread Gary Mills
In an attempt to build python2.7 on a T2000 (SPARC), I received this
error:

/usr/gcc/4.4.4/bin/gcc -m32 -O3 -mno-app-regs -fPIC -DPIC -std=c99 
-D_XOPEN_SOURCE=600 -m32 -fPIC -DPIC -R/usr/gnu/lib -L/usr/gnu/lib  -o python \
Modules/python.o \
-L. -lpython2.7 -lsocket -lnsl -ldl-lm  
Undefined   first referenced
 symbol in file
asm ./libpython2.7.so
ld: fatal: symbol referencing errors. No output written to python
collect2: ld returned 1 exit status

This happens because Python/ceval.c contains two instances of code
like this:

  #if defined(__sparc)
+   asm("nop");
  #endif

This code was inserted by a patch called 05-dtrace.patch .  The file
dtrace.patch.diff, attached to this message, shows the changes I made
to the patch.  These changes fix the problem.

One of the modules also failed to build, producing these errors:


/export/home/mills/Downloads/code/oi-userland/components/python/python27/Python-2.7.14/Modules/_ctypes/libffi/src/sparc/ffi.c:526:
 error: 'asm' undeclared (first use in this function)

/export/home/mills/Downloads/code/oi-userland/components/python/python27/Python-2.7.14/Modules/_ctypes/libffi/src/sparc/ffi.c:526:
 error: expected ';' before 'volatile'

The new patch 31-sparc.patch, also attached, fixes this problem.
Finally, I updated COMPONENT_REVISION in the Makefile to signal the
presence of the adjusted patch and the new one as in the file
Makefile.diff, also attached.

These changes only affect the SPARC build.  Later python versions
likely require the same changes, but I haven't checked.

I'd appreciate it if somebody could verify that these changes are
correct.  I assume they are.  The build completes after these changes
are made.


-- 
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-
--- ../05-dtrace.patch-orig:: 
+++ 05-dtrace.patch:: 
@@ -96,7 +96,7 @@
 +   * Disable the tail call here.
 +   */
 +#if defined(__sparc)
-+  asm("nop");
++  __asm__ __volatile__("nop");
 +#endif
 +}
 +
@@ -117,7 +117,7 @@
 +   * Disable the tail call here.
 +   */
 +#if defined(__sparc)
-+  asm("nop");
++  __asm__ __volatile__("nop");
 +#endif
 +}
 +#else
--- Makefile-orig  :: 
+++ Makefile   :: 
@@ -18,6 +18,7 @@
 #
 # CDDL HEADER END
 #
+# Copyright 2018 Gary Mills
 # Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights reserved.
 
 #
@@ -25,7 +26,7 @@
 
 COMPONENT_NAME=Python
 COMPONENT_VERSION= 2.7.14
-COMPONENT_REVISION=1
+COMPONENT_REVISION=2
 COMPONENT_PROJECT_URL= http://python.org/
 COMPONENT_SRC= $(COMPONENT_NAME)-$(COMPONENT_VERSION)
 COMPONENT_ARCHIVE= $(COMPONENT_SRC).tar.xz
--- Python-2.7.14/Modules/_ctypes/libffi/src/sparc/ffi.c-orig  :: 
+++ Python-2.7.14/Modules/_ctypes/libffi/src/sparc/ffi.c   :: 
@@ -437,10 +437,10 @@
  call_struct[6] = 0x81c7e008;   /* ret 
 */
  call_struct[7] = 0xbe100017;   /* mov   %l7, %i7  
 */
 #ifdef __GNUC__
- asm volatile ("iflush %0; iflush %0+8; iflush %0+16; iflush 
%0+24" : :
+ __asm__ __volatile__ ("iflush %0; iflush %0+8; iflush %0+16; 
iflush %0+24" : :
"r" (call_struct) : "memory");
  /* SPARC v8 requires 5 instructions for flush to be visible */
- asm volatile ("nop; nop; nop; nop; nop");
+ __asm__ __volatile__ ("nop; nop; nop; nop; nop");
 #else
  ffi_flush_icache (call_struct, 32);
 #endif
@@ -523,11 +523,11 @@
   /* Flush the Icache.  closure is 8 bytes aligned.  */
 #ifdef __GNUC__
 #ifdef SPARC64
-  asm volatile ("flush %0; flush %0+8" : : "r" (closure) : "memory");
+  __asm__ __volatile__ ("flush %0; flush %0+8" : : "r" (closure) : "memory");
 #else
-  asm volatile ("iflush%0; iflush %0+8" : : "r" (closure) : "memory");
+  __asm__ __volatile__ ("iflush%0; iflush %0+8" : : "r" (closure) : 
"memory");
   /* SPARC v8 requires 5 instructions for flush to be visible */
-  asm volatile ("nop; nop; nop; nop; nop");
+  __asm__ __volatile__ ("nop; nop; nop; nop; nop");
 #endif
 #else
   ffi_flush_icache (closure, 16);
___
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

2018-05-26 Thread Gary Mills
On Sat, May 26, 2018 at 03:32:55PM +0300, Igor Kozhukhov wrote:
> 
> we have tried to do some research for GNU AS replacement with
> illumos build on SPARC - but GNU binutils (GAS) should be updated a little.
> i have filed som bugs and they was resolved, but not at all.

Are you saying that gas for SPARC is not a general-purpose assembler,
that it's only designed to handle the output from the compiler?

Files written in assembler would be a problem then.

> we have used very old SUN AS doc - found by google.

Yes, I've found that.  It should be adequate.

> GNU AS for sparc documented in sources.

In the gas source, do you mean?

> but - not finished updates - still need additional work.
> i can try to found a branch on dilos-illumos with updates,
> but it is outdated and should be rebased to latest.
> I have no time right now for this work.

Even knowing the remaining bugs in gas would be useful


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

___
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

2018-05-26 Thread Gary Mills
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.


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

___
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

2018-05-24 Thread Gary Mills
On Sat, May 19, 2018 at 09:10:26PM -0500, Norm Jacobs wrote:
>It looks like
>developer/gcc-7/patches/0008-sol2-enable-full-__cxa_atexit-support.patc
>h may need work for SPARC, particularly in libgcc/config.host.  Without
>looking too far into it, I would guess that changing the diffs for
>libgcc/config.host in the patch to
[...]
>sparc*-*-solaris2.1[0-9]*)
>  # Solaris 10+/SPARC lacks crt1.o and gcrt1.o.
>  extra_parts="$extra_parts crt1.o gcrt1.o"
> +extra_parts="$extra_parts crtbeginS.o crtendS.o"
>  ;;
>  esac
>fi
> 
>might resolve the issue, but I don't have a SPARC system setup to
>verify.

Yes, that seems to work.  I put the file names all in one line.  At
least, the compiler builds those missing files now:

$ find build -name 'crt*S.o' -ls
232206863 -rw-r--r--   1 millsstaff2520 May 22 15:15 
build/sparcv7/prev-sparc-sun-solaris2.11/libgcc/crtbeginS.o
232206882 -rw-r--r--   1 millsstaff 692 May 22 15:15 
build/sparcv7/prev-sparc-sun-solaris2.11/libgcc/crtendS.o
232202265 -rw-r--r--   1 millsstaff3592 May 22 15:01 
build/sparcv7/prev-sparc-sun-solaris2.11/sparcv9/libgcc/crtbeginS.o
232202282 -rw-r--r--   1 millsstaff 952 May 22 15:01 
build/sparcv7/prev-sparc-sun-solaris2.11/sparcv9/libgcc/crtendS.o
232202602 -rw-r--r--   1 millsstaff 952 May 22 15:01 
build/sparcv7/prev-gcc/sparcv9/crtendS.o
232202595 -rw-r--r--   1 millsstaff3592 May 22 15:01 
build/sparcv7/prev-gcc/sparcv9/crtbeginS.o
232207182 -rw-r--r--   1 millsstaff 692 May 22 15:15 
build/sparcv7/prev-gcc/crtendS.o
232207173 -rw-r--r--   1 millsstaff2520 May 22 15:15 
build/sparcv7/prev-gcc/crtbeginS.o

The build of gcc-7 gets past that point now, but stops later with a
segmentation fault.  I assume that's unrelated to the earlier error.


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

___
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

2018-05-21 Thread Gary Mills
On Mon, May 21, 2018 at 02:41:50PM +, ken mays via oi-dev wrote:
>@Gary,
>DilOS mentioned: "SPARC: illumos build still with gcc 4,x because have
>to work on transitions of Sun AS -> GNU AS for sparc sources."
>I just wrote about a move to either GCC 6.x/7.x moving forward, then I
>remember this from DilOSdarn

The real problem is that we don't have source for the Sun assembler,
meaning that we can't change it.  GCC on OI does invoke the Sun
assembler for SPARC but the GNU assembler for x86 hardware.  It can,
of course, invoke the GNU assembler on SPARC hardware too.  The
assembly languages are somewhat different, though.  I don't know how
different they are, but all the assembly language source files in
illumos are written for the Sun assembler.

So, we have a few options.  The easiest one may be to create a
translator and use it to convert the source files.  It doesn't have
to be efficient as it will be used only once.  It does have to be
accurate.

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

___
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

2018-05-20 Thread Gary Mills
On Sat, May 19, 2018 at 09:10:26PM -0500, Norm Jacobs wrote:
>It looks like
>developer/gcc-7/patches/0008-sol2-enable-full-__cxa_atexit-support.patc
>h may need work for SPARC, particularly in libgcc/config.host.  Without
>looking too far into it, I would guess that changing the diffs for
>libgcc/config.host in the patch to
[...]

I was suspicious of that patch too, but I didn't know where it fit
in in the build process.  I'm testing your suggested change now.

Unfortunately, the build stops at an earlier point, complaining
that AX_PTHREAD is not defined.  I'm investigating that problem.
I seem to need /usr/share/aclocal/ax_pthread.m4 on this system,
or perhaps the whole package that contains it.


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

___
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

2018-05-19 Thread Gary Mills
On Sat, May 19, 2018 at 09:08:32PM -0400, Richard Lowe wrote:
>I would not be surprised, if enabling crt*S is still an illumos patch,
>if that patch was not somehow wrong.�  I don't have a SPARC to actually
>check it.

I haven't tracked it down completely, but it seems that the main
problem is that gcc has not built those files, even though it requires
them later in the build.

I have learned a few things in my reading, though.  The crtbeginS.o
and crtendS.o files are special versions of crtbegin.o and crtend.o
that are compiled with -fPIC .  They are needed by C++ shared
libraries for global constructors and destructors.  The file names are
passed by the compiler on the linker command line.  That'll be why
I got the error messages I did.

I'm currently building gcc-4.9.4 from the oi-userland source.  As far
as I can tell, it doesn't use those files.  I expect it will build.

Those files are included with the gcc-5, gcc-6, and gcc-7 binary
packages of oi-userland for x86.


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

___
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

2018-05-19 Thread Gary Mills
On Sat, May 19, 2018 at 10:47:05PM +0200, Aurélien Larcher wrote:
> 
>Are you sure there is no crtbeginS.o at all in the directory?

Quite sure:

$ find build -name 'crt*.o' -ls
227005892 -rw-r--r--   1 millsstaff1416 May 19 10:40 
build/sparcv7/gcc/sparcv9/crt1.o
227005874 -rw-r--r--   1 millsstaff3232 May 19 10:40 
build/sparcv7/gcc/sparcv9/crtbegin.o
227005882 -rw-r--r--   1 millsstaff 952 May 19 10:40 
build/sparcv7/gcc/sparcv9/crtend.o
227005915 -rw-r--r--   1 millsstaff3928 May 19 10:40 
build/sparcv7/gcc/sparcv9/crtfastmath.o
227005845 -rw-r--r--   1 millsstaff3928 May 19 10:40 
build/sparcv7/sparc-sun-solaris2.11/sparcv9/libgcc/crtfastmath.o
227005782 -rw-r--r--   1 millsstaff 952 May 19 10:40 
build/sparcv7/sparc-sun-solaris2.11/sparcv9/libgcc/crtend.o
227005764 -rw-r--r--   1 millsstaff3232 May 19 10:40 
build/sparcv7/sparc-sun-solaris2.11/sparcv9/libgcc/crtbegin.o
227005802 -rw-r--r--   1 millsstaff1416 May 19 10:40 
build/sparcv7/sparc-sun-solaris2.11/sparcv9/libgcc/crt1.o

>Should they not be created already from stage-1?

That's what I expected.

>You should be able to set the ld path to them using boot-ldflags.

They don't exist anywhere on the system.

>Also I do not remember if multilib is considered as a native build. If
>not, you may need to --enable-bootstrap explicitly.

Okay, thanks.

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

___
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

2018-05-19 Thread Gary Mills
On Sat, May 19, 2018 at 10:02:49PM +0200, Aurélien Larcher wrote:
>On Sat, May 19, 2018 at 9:56 PM, Gary Mills <[1]gary_mi...@fastmail.fm>
>wrote:
> > 
> >  I'm attempting to build the developer/gcc-7 source package from a
> >  recent version of oi-userland.�  The build stops with these error
> >  messages:
[...]
> >  �  �  ld: fatal: file crtbeginS.o: open failed: No such file or
> >  directory
> >  �  �  ld: fatal: file crtendS.o: open failed: No such file or
> >  directory
> >  �  �  ld: fatal: file processing errors. No output written to
> >  sparcv9/libgcc_s.so.1.tmp

>Why do you use gcc-4.4.4-il instead of the userland compiler?

What's the userland compiler?  I'm using gcc-4.4.4-il because that's
the only one I got to build so far.


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

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

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

2018-05-19 Thread Gary Mills
I'm attempting to build the developer/gcc-7 source package from a
recent version of oi-userland.  The build stops with these error
messages:


/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/xgcc

-B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/
-B/usr/gcc/7/sparc-sun-solaris2.11/bin/
-B/usr/gcc/7/sparc-sun-solaris2.11/lib/ -isystem
/usr/gcc/7/sparc-sun-solaris2.11/include -isystem
/usr/gcc/7/sparc-sun-solaris2.11/sys-include -O2 -g -O2 -DIN_GCC -W
-Wall -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC
-g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared
-nodefaultlibs -Wl,-h,libgcc_s.so.1 -Wl,-z,text -Wl,-z,defs
-Wl,-M,libgcc.map -o sparcv9/libgcc_s.so.1.tmp -g -O2 -m64 -B./
_muldi3_s.o _negdi2_s.o ... unwind-sjlj_s.o unwind-c_s.o emutls_s.o
libgcc.a -lc && rm -f sparcv9/libgcc_s.so && if [ -f
sparcv9/libgcc_s.so.1 ]; then mv -f sparcv9/libgcc_s.so.1
sparcv9/libgcc_s.so.1.backup; else true; fi && mv
sparcv9/libgcc_s.so.1.tmp sparcv9/libgcc_s.so.1 && ln -s libgcc_s.so.1
sparcv9/libgcc_s.so
ld: fatal: file crtbeginS.o: open failed: No such file or directory
ld: fatal: file crtendS.o: open failed: No such file or directory
ld: fatal: file processing errors. No output written to 
sparcv9/libgcc_s.so.1.tmp
collect2: error: ld returned 1 exit status
Makefile:977: recipe for target 'libgcc_s.so' failed
make[6]: *** [libgcc_s.so] Error 1
make[6]: Leaving directory 
'/dpool/export/home/mills/Downloads/code/oi-userland-apr/components/developer/gcc-7/build/sparcv7/sparc-sun-solaris2.11/sparcv9/libgcc'

It seems to be building the runtime shared library.  However, the
files crtbeginS.o and crtendS.o do not exist in the build directory.
Neither do they exist in libgcc.a .  The directory /usr/gcc/7 also
does not exist, as the compiler has not been installed yet.  I'm using
gcc-4.4.4-il-4 to build it.

What's gone wrong?


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

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


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

2017-09-16 Thread Gary Mills
On Sun, Sep 17, 2017 at 12:44:47AM +0200, Aurélien Larcher wrote:
> 
>What you mention is the Xorg module which is already present here
>(which I tested when I bumped Xorg to 1.18.x):
>[2]https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/component
>s/x11/xf86-video-ati
>Unfortunately newer versions require KMS support which requires actual
>kernel work at:
>[3]https://github.com/illumos/gfx-drm
>but also in illumos-gate itself.

So, what you are saying, and Martin also said, is that using the
ATI and Radeon drivers is much more complicated than it seems at
first.  OI needs KMS support for these newer drivers to work.

>Ideally if someone decided to work on it the code would reside under
>the radeon directory here:
>[4]https://github.com/illumos/gfx-drm/tree/master/usr/src/uts/intel

It won't be me.  I know almost nothing about kernel code or graphics
hardware.

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

I don't think that its still present.  I notice that Xorg.0.log on
Solaris 11.3, where I have a Radeon card installed, says this:

[   302.632] (II) GPU only supported with KMS, using vesa instead.



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

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


[oi-dev] The ATI video driver for OI

2017-09-15 Thread Gary Mills
What is required to integrate the ATI video driver with OI?

I notice that the ATI video driver is present in Freebsd.  It comes
from X.org, and supports a long list of AMD/ATI/Radeon GPUs.  The
Freebsd package is called `xf86-video-ati'.  It provides two shared
libraries, ati_drv.so and radeon_drv.so, that are loaded by the X
server.

Could we do the same thing with the X server in OI?  What do we need
to change?


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

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


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

2017-09-14 Thread Gary Mills
On Mon, Jun 05, 2017 at 09:24:26AM +0200, Jean-Pierre André wrote:
> Yesterday I upgraded a Hipster installation from April 2016
> to the latest state (by starting a pkg update).
> 
> I apparently could not boot beyond the single user mode, but
> the real reason appears to lie in a change in the video driver
> ABI.

I had a similar problem, and have partially solved it.  I had an AMD
Athlon system with an NVIDIA GeForce 6200 LE video card.  It was
running OI Hipster installed from the 20160421 ISO.  I had installed
NVIDIA-Solaris-x86-304.132 to get it to recognize the video card.
When I upgraded to the current Hipster in a new BE, the BE failed to
boot.

I couldn't find a way to uninstall the Nvidia software I had
installed, but I was able to boot an old BE that I made before I
installed the software.  It was using the VESA driver for that video
card, but otherwise everything ran normally.

Then I replaced the video card with a new low-end one that seemed
current.  It was an Nvidia card with a GT730 GPU.  The cost was less
than $100.  Hipster recognized that card.  It described my monitor
correctly and set the resolution to the monitor's default.  The Nvidia
X Server Settings GUI worked.

That system is still running Hipster from 2016, but I'm ready to try
the upgrade again.


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

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


[oi-dev] What is Checker exception from pkglint?

2017-08-07 Thread Gary Mills
When I'm publishing some oi-userland components on a SPARC machine, I
get an error message like this:

ERROR lint.error Checker exception from userland.manifest1001 on
pkg:/x11/library/libglew@1.13.0,5.11-2016.0.1.0: Illegal FMRI
'pkg:/SUNWcs@0.5.11-0.152': No build version provided in Version
constructor: (0.5.11-0.152, None)

followed by several warnings like this:

WARNING pkglint.action005.1 obsolete dependency check skipped: unable
to find dependency pkg:/SUNWcs@0.5.11-0.152 for
pkg:/x11/library/libglew@1.13.0,5.11-2016.0.1.0

What does this all mean?  What should I do to correct the error?


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

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


Re: [oi-dev] Plan for Hipster SPARC edition

2017-07-23 Thread Gary Mills
On Thu, Jun 22, 2017 at 07:06:16PM +0200, Adam Števko wrote:
> 
>On 21 Jun 2017, at 23:30, Gary Mills <[1]gary_mi...@fastmail.fm> wrote:
> 
>>We need a few facilities to proceed with this plan.  One is a set of
>>instructions for creating ISOs, particularly the text ISO, along with
>>a list of packages to be included.
> 
>Distribution constructor files for hipster are available at
> 
>[2]https://hipster.openindiana.org/distro_const/,

Those are the XML files.  They should be fine

>how to build ISOs can be found on the wiki.

The only instructions I could find were for oi-148, from 2011.  Is
that it, or is there something more recent?


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

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

Re: [oi-dev] Errors building libdtrace_jni on hipster

2017-07-03 Thread Gary Mills
On Mon, Jul 03, 2017 at 10:04:17PM +0100, Peter Tribble wrote:
>On Mon, Jul 3, 2017 at 9:34 PM, Gary Mills <[1]gary_mi...@fastmail.fm>
>wrote:
> 
>  �  �  .../usr/src/lib/libdtrace_jni/java/src/org/opensolaris/os/
>  dtrace/Aggregate.java:233: error: unknown tag: AggregationRecord
>  �  �  �  �  � * List  records =
>  aggregate.getRecords();
> 
>Do you have
>export BLD_JAVA_8=
>in your illumos.sh? I would guess not, by that error.

No I didn't have that.  I am running a recent version of Hipster.  I
see that symbol is used in java/Makefile to disable doclint.  I'm
doing a build now to see if that addition solves my problem.

>See the hipster section in:
>[2]https://wiki.illumos.org/display/illumos/How+To+Build+illumos

I didn't have any of those things.  I wonder if they are all still
necessary.  Perhaps I'll find out when the build completes.


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

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

Re: [oi-dev] Plan for Hipster SPARC edition

2017-06-24 Thread Gary Mills
On Thu, Jun 22, 2017 at 07:06:16PM +0200, Adam Števko wrote:
> 
>I will keep this short as I will be repeating what disccused the last
>time. I am not very happy about this because it evolved exactly like I
>thought it would. More message are inline.

What you said before inspired me to move the project along while at
the same time providing opportunities for cooperation between SPARC
developers.

I intend what I add below to be new information.

>On 21 Jun 2017, at 23:30, Gary Mills <[1]gary_mi...@fastmail.fm> wrote:
> 
>I've now completed my build of oi-userland on SPARC hardware, at least
>to the extent that was possible with oi_151a8 .  Yes, the latest OI
>SPARC ISO is version oi_151a8 .  This is a major obstacle to Hipster
>development on the SPARC platform.
> 
>Great job! However, how does it help if there are no up-to-date SPARC
>illumos bits available? The plan was to get minimal illumos up and
>running, so we could self-host Jenkins on SPARC. What happened with
>this? Instead of SPARC people working together, we get multiple SPARC
>initiatives with no major milestone achieved anywhere.

That's what these proposals are intended to provide: an operating
system that you can use to construct a build system for Hipster on
SPARC.  It will take a few iterations, but it will be done.

>I propose, first of all, to create a Hipster ISO.  It won't be
>current, but it will be a much better base for further development.
>With this as a base, I and other developers will be able to build many
>more oi-userland packages.
> 
>You can build the ISO yourself and share it. I will be able to host
>undet contrib/ section on DLC and mirror it worldwide.

That'll be fine.  One of the other SPARC developers may do this part.
I'm only using myself as an example.

>I also propose to create a SPARC package repository to go along with
>the ISO.  Any SPARC developer will be able to contribute to this
>repository.  I haven't built illumos-gate, but perhaps other
>developers have already done this, and can contribute packages.  If
>not, I can do it.
> 
>With no build host, no build platform we are not able to self-host
>SPARC Jenkins and cannot do builds. Setting up a repository and blindly
>accepting built packages from people is not a very good approach from
>security point of view and I wouldn't recommend it. With the current
>setup, we are getting reviews from people and are able to spot
>potentionaly suspicious things at least.

I thought you already had a SPARC build host.  I thought that what
you were missing was an operating system to run on it.  That's what
this project aims to provide.  As for security, there are only three
SPARC developers, as far as I know.  You should be able to trust us.
We trust you.  The packages are built from the same source.  It's the
source that gets the reviews.

>Distribution constructor files for hipster are available at
> 
>[2]https://hipster.openindiana.org/distro_const/, how to build ISOs can
>be found on the wiki.

Thanks.  I'll review that information as soon as I can.

>Why not provide with the illlumos SPARC first and then go for
>oi-userland? We tried to put you, SPARC guys, in touch and create a
>joint effort for SPARC version of OpenIndiana, so we could release a
>reasonsble and instead we got fragmentation again. I don't think a lot
>can be achieved without SPARC build host, build platform and people
>willing to maintain SPARC version.

Isn't illumos just part of an operating system?  We, the SPARC
developers, can each build illumos-gate.  Some of us have already done
that.  That's the easy part.  But, we also need some oi-userland
packages to make a complete operating system, even just for the text
ISO.  That build takes me several months.  Fortunately, we each can
build and contribute oi-userland packages.  I'd call that cooperation.
I don't know of any other way to have a joint effort.


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

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

[oi-dev] Plan for Hipster SPARC edition

2017-06-21 Thread Gary Mills
I've now completed my build of oi-userland on SPARC hardware, at least
to the extent that was possible with oi_151a8 .  Yes, the latest OI
SPARC ISO is version oi_151a8 .  This is a major obstacle to Hipster
development on the SPARC platform.

I propose, first of all, to create a Hipster ISO.  It won't be
current, but it will be a much better base for further development.
With this as a base, I and other developers will be able to build many
more oi-userland packages.

I also propose to create a SPARC package repository to go along with
the ISO.  Any SPARC developer will be able to contribute to this
repository.  I haven't built illumos-gate, but perhaps other
developers have already done this, and can contribute packages.  If
not, I can do it.

We need a few facilities to proceed with this plan.  One is a set of
instructions for creating ISOs, particularly the text ISO, along with
a list of packages to be included.

We also need a repository for SPARC packages, with a mechanism to
permit any SPARC developer to upload packages to this repository.

Finally, we need storage for a few ISO files.

The ultimate goal, of course, is an automatic procedure for building
SPARC packages from the same code base as the current x86 packages.


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

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


[oi-dev] Where should espeak guile and openal go?

2017-05-01 Thread Gary Mills
I have small patches for three oi-userland components: espeak guile
openal .  I understand if I touch them, I have to move them to a
category directory.  Which one should that be?  All of them have an
FMRI that begins with `library'.  Is that a good choice?

`espeak' is described as: compact open source software speech
synthesizer.  `guile' is described as: GNU Ubiquitous Intelligent
Language for Extensions.  `openal' is described as: cross-platform 3D
audio API.  Are those any help?


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

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


[oi-dev] How do I update shared-macros.mk on github?

2017-04-07 Thread Gary Mills
What is the trick to updating shared-macros.mk in oi-userland on
github?  I thought I knew how to do it, but it didn't work.

I have a fork of oi-userland on github that I made in November and a
local clone of the fork that I made just afterwards.  Recently, I
modified shared-macros.mk locally, did a commit in a new branch, and
did a push of that branch to my fork on github.  Then, I created a PR
for that change; it was integrated into oi-userland.  So far,
everything worked nicely.

Now I need to make another change to shared-macros.mk.  I kept copies
of the original file and the file after the first change.  This time,
when I did a push to my fork on github, the commit there contained
both changes.  Consequently, the PR doesn't work because of conflicts.
I was expecting it to contain only the second change.

What can I do now to make it work?


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

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


[oi-dev] Faulty PR initiated for oi-userland

2017-04-04 Thread Gary Mills
I see that I somehow created a PR for oi-userland that contains three
commits.  I only wanted the third one to be included, the one for:

8028 Some component Makefiles only need a PATH symbol change

How can I correct this mistake?  The first two are just local changes
that should not appear on Github.


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

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