Re: [oi-dev] No rsync at dlc-origin?

[Michal Nowak via oi-dev]

On 02/07/20 06:46 AM, Marcel Telka wrote:

On Sun, Feb 02, 2020 at 01:28:12PM +0100, Michal Nowak via oi-dev wrote:

On 02/02/20 08:15 AM, Marcel Telka wrote:

I noticed that rsync at dlc-origin stopped to work about 4 days ago:

rsync: failed to connect to dlc-origin.openindiana.org (91.194.75.37): 
Connection timed out (145)
rsync error: error in socket IO (code 10) at clientserver.c(127) 
[Receiver=3.1.3]

Is this intentional?


I think it's just down for some reason. Thanks for letting us know.


... and will somebody make it working again?


Thanks.



Ticket to our provider was filed, WIP.

Michal

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

Re: [oi-dev] No rsync at dlc-origin?

[Michal Nowak via oi-dev]

On 02/02/20 08:15 AM, Marcel Telka wrote:

Hi,

I noticed that rsync at dlc-origin stopped to work about 4 days ago:

rsync: failed to connect to dlc-origin.openindiana.org (91.194.75.37): 
Connection timed out (145)
rsync error: error in socket IO (code 10) at clientserver.c(127) 
[Receiver=3.1.3]

Is this intentional?


Thanks



I think it's just down for some reason. Thanks for letting us know.

Michal

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

Re: [oi-dev] GOCACHE for Jenkins jobs

[Michal Nowak via oi-dev]

We came across this problem before and therefor added

  COMPONENT_BUILD_ENV += GOCACHE="$(SOURCE_DIR)/gocache"

to golang-11{2,3} packages.

Any idea why this still failed?

Michal

On 01/27/20 09:37 AM, Till Wegmüller wrote:

Hi Aurelien

Yes you must define GOCACHE. Go modules requires this path to download
and unpack/compile Build dependencies. It will also speed up any
subsequent runs if this Cache is globally.

Here is my Jenkins config for go 1.11+

 environment {
  GOCACHE = "${WORKSPACE}/gocache"
  GO111MODULE = "on"
  GOPATH = "${WORKSPACE}/../gopath"
 }

GO111MODULE might not be necessary depending on the Software you are
building but they have to include a note if they do not support go
modules yet. Acording to the Go community it is advised to file a
upstream bug of Go modules are not yet supported.

If you need any Help with Go let me know. I Programm with it as my Day
Job and maintain the OpenIndiana Packages. Chances are I have come
accross an issue before :)

Greetings
Till


On 26.01.20 23:49, Aurélien Larcher wrote:

Hi,
it seems that MongoDB 3.4 fails to build on Jenkins because Go 1.12
requires a path used for caching files.

"build cache is required, but could not be located: GOCACHE is not
defined and neither $XDG_CACHE_HOME nor $HOME are defined Error building
bsondump"

As a workaround I defined a GOCACHE variable in the Jenkins
configuration but that is probably not suitable in the long run.

Kind regards,

Aurelien

--
---
Praise the Caffeine embeddings

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



___
oi-dev 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] Building openjdk-8-162 with gcc-6 on SPARC

[Michal Nowak via oi-dev]

On 01/12/20 04:03 PM, Gary Mills wrote:

I'm attempting to build openjdk-8-162 with gcc-6 on SPARC hardware.  I
finally got a successful gmake build, but a failure with gmake
install.  The error was this one:

 Error occurred during initialization of VM
 java.lang.StackOverflowError
 at java.lang.Object.(Object.java:41)

All newly-build java applications produce the same error.  With a
search on the web, I found exactly the same error for linux.  The bug
apparently affected all architectures except x86.  It appeared because
of increased optimization in later versions of gcc.  This is the linux
patch:

diff --git a/src/os_cpu/linux_zero/vm/os_linux_zero.cpp 
b/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
--- jdk8/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
+++ jdk8/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
@@ -55,8 +55,8 @@
  #include "utilities/vmError.hpp"
  
  address os::current_stack_pointer() {

-  address dummy = (address) 
-  return dummy;
+  // return the address of the current function
+  return (address)__builtin_frame_address(0);
  }
  
  frame os::get_sender_for_C_frame(frame* fr) {


This, of course, has no effect on OI.  During the build, OI is
detected as solaris.  The equivalent function for solaris-sparc, in
openjdk/hotspot/src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp,
has this code:

 address os::current_stack_pointer() {
   volatile int dummy;
   address sp = (address) + 8; //  need to confirm if this is 
right
   return sp;
 }

I assume that it's also compiled incorrectly because of the increased
optimization, but I don't know how to correct it.  I'm also concerned
about the comment.  Is it right?

Has anybody else built openjdk for SPARC with gcc?  How did you fix
this bug?




Does building with lesser optimization level than the present one make 
the problem go away? Look for 'gcc_OPT' in make-rules/shared-macros.mk 
and use it in the component's Makefile.


Michal

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

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

[Michal Nowak via oi-dev]

On 12/12/19 03:13 PM, Gary Mills wrote:

On Wed, Dec 11, 2019 at 09:34:03AM +0100, Michal Nowak via oi-dev wrote:

Thanks for your answers, Gary. One point of clarification below:

On 11/27/19 03:58 PM, Gary Mills wrote:

* we don't test that changes build the less work on SPARC


I don't understand this condition.


"It's not required to test update (PR) on SPARC for it to be merged."

Is this wording clearer?


Yes, that's clear to me.


Currently it's required minimal testing to be done for a PR to be accepted.
I am basically not expecting PR to be tested on SPARC for it to be
integrated.


I assume that a PR will always be tested on x86.  That's fine with me.




Thanks. This arrangement should work for me. Feel free to come-up with 
SPARC-related PRs in GitHub.


Michal

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

Re: [oi-dev] Would OI be interested in Pale Moon?

[Michal Nowak via oi-dev]

On 12/11/19 08:37 PM, Matt A. Tobin wrote:
BUT, that isn't what has happened this day. No, this day did not turn 
out as hoped for by the young programmer. Something very different 
happened. He, and by extension, all of us who work on the Unified XUL 
Platform and the projects, Pale Moon included, that build on it have 
been rejected out of hand.


We don't reject Jeremy, he is warmly welcome to work with and in our 
community (as stated before). Pale Moon is what we rejected. Not only 
from the reason you concentrate your reply around, but also from the 
other reason - we are a small community and we need to focus our efforts 
in a certain way, that's why we e.g. don't have desktop environments 
other than MATE.


So here we are, I am writing to all of you because someone I have come 
to know and who worked very hard to bring his chosen software to his 
chosen OS for all to use and enjoy has been crushed.


It may have played out differently if Jeremy talked to us about possible 
Pale Moon integration months ago when he started the work, because the 
position of at least one of our developers was clear back then and is on 
record at 
https://alp-notes.blogspot.com/2018/02/a-brief-story-of-how-you-shouldnt.html.


Michal

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

Re: [oi-dev] Would OI be interested in Pale Moon?

[Michal Nowak via oi-dev]

On 12/11/19 12:51 PM, Jeremy Andrews wrote:

This is an interesting discussion, and I did want to address some
additional comments...

Actually, the restrictions they have are on the use of the official
branding. They are saying you have to build it a specific way if you
want to use their official branding, and they have very specific
requirements to get permission to use official branding that I've
managed to comply with thus far. However, if you were to use alternative
branding like IceWeasel-UXP does:

https://wiki.hyperbola.info/doku.php?id=en:project:iceweasel-uxp

Then you don't have to follow those requirements.

I assumed since you weren't interested in Pale Moon, you weren't
interested in anything like this at all, but I heard someone talk about
issues with Rust and then someone else mention IceWeasel which reminded
me there was an alternative. The big advantages of the UXP platform are
that it supports more modern websites than older Firefox does, doesn't
have Rust or telemetry, and still supports XUL extensions and NPAPI plugins.

The irony of all this is, the reason Pale Moon has the branding
restrictions is because they haven't tested any system libraries other
than their own internal ones, they don't want to provide support for
custom builds, and they're worried about their browser getting a bad
reputation for being buggy due to being built in an unsupported
configuration. But now their browser apparently has a bad reputation
because of their licensing restrictions.


Jeremy, thank you for the explanation. We value your work and interest. 
Even-though we won't accept Pale Moon, I hope this whole exercise helped 
you understand web browser's internals.


As others I invite you to work with us on bringing Firefox 68 ESR to 
OpenIndiana. Your skill-set looks right for the task. Currently we 
update LLVM (https://github.com/OpenIndiana/oi-userland/pull/5389) so we 
can build newer Rust, and thus build new Firefox 
(https://github.com/OpenIndiana/oi-userland/pull/4999). Talk to us on 
#openindiana Freenode channel if this suits your interests.


Michal

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

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

[Michal Nowak via oi-dev]

Thanks for your answers, Gary. One point of clarification below:

On 11/27/19 03:58 PM, Gary Mills wrote:

* we don't test that changes build the less work on SPARC


I don't understand this condition.


"It's not required to test update (PR) on SPARC for it to be merged."

Is this wording clearer?

Currently it's required minimal testing to be done for a PR to be 
accepted. I am basically not expecting PR to be tested on SPARC for it 
to be integrated.


Michal

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

Re: [oi-dev] Would OI be interested in Pale Moon?

[Michal Nowak via oi-dev]

On 12/11/19 07:38 AM, Jeremy Andrews wrote:

I ported UXP to illumos and Solaris recently, and I got them to take the
code upstream. I'm pretty anxious about the process now honestly, and
really want everything to work out. There are a few things I'm worried
about, though.

1. I'm not very familiar with how packages are actually packaged for OI,
and the p5m file for Firefox in particular is... so complicated that
I've been holding off creating a Pale Moon system package for OI until
now, when they're pushing me to try. I was hoping that the subject
wouldn't come up and they'd just want to distribute a binary .tar.xz
file like they do for other operating systems (that kind of package is
very easy to create with a single command). I'm so mixed up because the
.p5m file for Firefox 52 looks so different from the one for Firefox 60,
and includes all these header files, is for 32-bit, etc. And I'm trying
to figure out which differences are due to a change in package design,
and which are due to actual differences in Firefox.

2. Pale Moon has some unusual requirements. For one thing, it can't use
the system NSS because Mozilla has changed the API somewhat since they
forked. In general, they're leery of using system libraries over the
ones in their own tree because sometimes those libraries have to be
modified in specific ways for the browser. On top of that, they seem to
have a problem with distributing the langpacks with the browser. They
have a site where you can download a langpack of your choice, but you
can't ship it with the browser for some reason.

I'm kind of afraid now that I've done all this for nothing. I'm worried
that their packaging requirements and our packaging requirements may not
line up, and I'll wind up only being able to distribute a tarball on my
own web space that no one will ever download. It's a very good browser,
and the people behind it are actually decent people, but... I'm
overwhelmed with the sense that I've gotten in over my head.


Given the hostility Pale Moon developers showed towards a license 
non-complying OpenBSD port at 
https://github.com/jasperla/openbsd-wip/issues/86, I'd rather avoid this 
community at all.


The other reason is maintenance cost on the OpenIndiana project. We 
already have Firefox and due to it's complexity it gives us hard time to 
keep-up even with ESR releases (currently we are stuck at version 60, 68 
is the latest one; the story for the 52->60 transition was the same). 
Same with Thunderbird. I am afraid Pale Moon would be another chapter of 
the very same story.


Michal

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

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

[Michal Nowak]

On 11/22/19 09:43 PM, Gary Mills wrote:

On Thu, Nov 21, 2019 at 10:56:11PM +0100, Michal Nowak wrote:

On 11/17/19 10:39 PM, Gary Mills wrote:

I have a series of questions to ask the members of this mailing list.
I have information to share with you as well.  I already have partial
answers to most of the questions, but I'd still like to hear from you.

[...]

There were 7 contributors to the OpenIndiana/oi-userland repo (which is the
bulk of OpenIndiana development) with more than 10 commits for the 2019.10
release. I don't know how many OI users (be it long-term or accidental ones)
are out there for the same period of time but I guess it's in low hundreds.


I have no doubt that SPARC owners are in the minority.  My estimate is
about 12 users and 6 developers.


Although I consider Gary's OI on SPARC an interesting achievement, I doubt
there are enough potential users and developers to sustain any illumos SPARC
distro of the same (slow) pace of hipster development. E.g. looking at
SPARC-related work in illumos, it's only Peter who contributes significantly
to this area (mostly by removing entirely obsolete platforms and by ensuring
illumos actually builds - and that's, I am afraid, revealing).


That's partly because illumos already has SPARC support built in:
Peter only fixes things in illumos that are broken.  I've submitted 14
bug reports, with patches, to the OI project.  I'm aware that the
patches need to be turned into PRs before OI developers will consider
them.  Most of the bug reports are not SPARC-specific.  I did not need
to submit any bug reports to the illumos project.


That built-in support is for > 10 years old platforms, for me that is 
indicative about interest in this platform. Given that illumos SPARC 
distros were not closely following illumos development, years of testing 
stuff which gets added is missing for SPARC.





Given the tiny resources OI project has and can offer, I wish OI and
"OI"-for-SPARC were independent and related to each other in the same way OI
currently relates to OmniOS CE and pkgsrc, that is by sharing knowledge,
patches.


Full independance is a good way to cripple SPARC development.  OI
source archives, Makefiles, and package manifests are used to build
and publish OI SPARC packages, generally with no change.  It's OI all
the way.  The only thing that will change is the list of components to
build.  The package names are the same.  The package repository does
not have to be hosted by OI, of course.

I've had a few offers of a build server with jenkins.  It will clone
oi-userland periodically, and build packages from it.  Only the binary
packages will be different from the x86 version.  The whole thing could
be fully automated and will track OI pretty closely.  We are not there
yet, but we will be.


Whatever the terminology on the projects relation, what I am really 
interested in is the OI amd64 development not being adversely affected.


Although I am not excited about it, I don't mind SPARC changes in the 
OpenIndiana GitHub projects (Makefiles, patches, .p5m files, ...), 
provided that OI does not guarantee anything for SPARC, including:


* we update a component which fails to build on SPARC, we don't retract,
* updated component's SPARC patch fails to apply and it's too 
complicated to fix it, we remove it for the time being and re-apply when 
SPARC developers come up with a fixed patch,

* we don't test that changes build the less work on SPARC

I don't think that's a great experience for SPARC re-builders from 
OpenIndiana/oi-userland.


Michal

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

Re: [oi-dev] Hosting site for OI SPARC ISO and repository

[Michal Nowak]

On 11/01/19 06:45 PM, Gary Mills wrote:

I'm looking for a hosting site for my OI SPARC ISO and IPS repository.
I don't mind paying for space.  All I need is a site that will allow
me to upload large files, so that I can publish the URLs where people
can download the same files.  Can anyone recommend such a site?

The compressed ISO file is less than 400 megs in size, although the
compressed repository is much larger, over 2 gigs in size.

I may only need to use this site for a few weeks, as the OI project
will eventually be hosting these files.

The source is OI with a few modification for SPARC hardware.  I began
with v9os, but now it's entirely OI from 2018.  I'll publish
information on how to use the ISO and repository as soon as I have
the files ready to download.


Create a minimal Cloud instance and setup FTP or HTTP server there? 
Costs should be really minimal for 1 vCPU / 1 GB of RAM instance.


Michal

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

Re: [oi-dev] what transforms and/or actuators for man pages?

[Michal Nowak]

On 10/09/19 08:57 PM, Tim Mooney wrote:
In userland, I believe that all/most the mangler.man.stability 
transforms, other than the default one setting man page stability to 
"uncommitted", should be removed because we can't really guarantee 
stability as userland is for the most part a set of third-party open 
source packages we don't control and can't promise anything (see my 
reasoning here 
https://github.com/OpenIndiana/oi-userland/pull/5060#pullrequestreview-246364150). 
Also see the tools/userland-mangler script.


I will follow your example and do the same if I touch a third-party
component, but what about other transforms in the .p5m file, like
the gtk-doc transforms or the locale transform?  If they are the
default transform, rather than something special for a particular package,
should they be removed too?


Not sure off-hand, do you have an example with such a transform?

Michal

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

Re: [oi-dev] what transforms and/or actuators for man pages?

[Michal Nowak]

Hi Tim.

On 10/08/19 11:34 PM, Tim Mooney wrote:


What are the recommended transforms to include in a component's .p5m file
for man pages?

The "Packaging and Delivering Software with IPS" guide has an example
(chapter 4, pages 27-28) of:

 \
     default facet.doc.man true>
 \
     add restart_fmri svc:/application/man-index:default>

The /usr/share/pkg/transform/documentation file has the same thing, but
for /usr/share/man, rather than the example above, for /opt.




Did you look into transforms/ of the oi-userland project?

It holds transform rules for every processed p5m file:

 newman   oi/hipster  ~  ws  oi-userland  transforms  ggrep -Rwn man
defaults:185: default 
mangler.man.stability uncommitted>

defaults:187:# Avoid mangling compressed man pages
defaults:188: 
default mangler.bypass true>

docs:26:# man pages
docs:27: \
docs:28:default facet.doc.man all>
docs:30: \
docs:31:default facet.doc.man all>
docs:70: delete 
facet.doc all>



The actual .p5m files in oi-userland use a wide variety of transforms
for man pages, such as

 set action.hash %<\1> >
 default mangler.man.stability 
uncommitted>


or

 default mangler.man.stability 
Uncommitted>


or

 default mangler.man.stability 
volatile>


or

 default mangler.man.stability 
"pass-through volatile">




In userland, I believe that all/most the mangler.man.stability 
transforms, other than the default one setting man page stability to 
"uncommitted", should be removed because we can't really guarantee 
stability as userland is for the most part a set of third-party open 
source packages we don't control and can't promise anything (see my 
reasoning here 
https://github.com/OpenIndiana/oi-userland/pull/5060#pullrequestreview-246364150). 
Also see the tools/userland-mangler script.



I don't see any current .p5m files that use the restart_fmri for OI's
service svc:/system/update-man-index:default , which I'm assuming is
equivalent to the svc:/application/man-index:default from the example.


update-man-index service is not restarted on man page being added to 
/usr/share/man/ though `whatis` knows about the new man page... so, I 
admit I don't understand this part of the process.




So, what are best practices for man page transforms for OI?

Thanks!

Tim


Michal

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

Re: [oi-dev] Errors from distro constructor

[Michal Nowak]

On 10/02/19 07:55 PM, Gary Mills wrote:

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?




Hi.

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 better way is to fix our Python 3 pkg: 
https://www.illumos.org/issues/11636.


Michal

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

Re: [oi-dev] Bootloader as of today damaged?

[Michal Nowak]

On 09/28/19 03:29 PM, Toomas Soome via oi-dev wrote:




On 28 Sep 2019, at 12:45, Toomas Soome  wrote:




On 28 Sep 2019, at 12:11, Andreas Wacknitz  wrote:

Hi all,

I have updated one of my build servers today and it stopped working after 
reboot.
I get a black screen (before the bootloader prompt typically is shown). So, my 
conclusion is that
the bootloader is damaged. I have re-installed OI with Michal's latest text 
image and after pkg update
the boot fails again.
Has anybody else experienced the same?

Regards,
Andreas


poke me on irc and we can do some diag…

rgds,
toomas




hi!

As it did turn out, it is not about bootloader being damaged, but installboot 
doing slightly wrong (updating VBR/PBR while stage2 was not updated). I’ll try 
to get the fix integrated asap, but for now, the workaround is:

after you run pkg update, force update of boot program with:
beadm mount NEWBE /mnt
bootadm install-bootloader -f -R /mnt

Or wait with update till the repo has loader package more recent than

Packaging Date: 28 September 2019 at 01:31:17
   Size: 2.26 MB
   FMRI: 
pkg://openindiana.org/system/boot/loader@1.1,5.11-2019.0.0.19070:20190928T013117Z

or /boot/gptzfsboot more recent than (use installboot -i /boot/gptzfsboot):
Extended version string: 1.1-2019.09.20.1

I’ll update installboot soon to make such error impossible in future.

sorry about the mess,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



I manually updated our illumos-gate with two loader fixes by Toomas as 
they are not integrated to the gate. This version should work:


  pkg://openindiana.org/system/boot/loader@1.1-2019.0.0.19072

It certainly works for me but I wasn't affected in the first place. If 
someone affected can test it, that would be great.


Michal

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

Re: [oi-dev] Hello OpenIndiana!

[Michal Nowak]

This is fantastic, Aurélien! Thanks for making it happen.

Michal

On 08/08/19 02:58 AM, Aurélien Larcher wrote:

narval> g++-9 --version
g++-9 (OpenIndiana 9.1.0-OI-0) 9.1.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

narval> g++-9 main.cpp
narval> ./a.out
Hello OpenIndiana!

narval> file a.out
a.out:          ELF 64-bit LSB executable AMD64 Version 1, dynamically 
linked, not stripped, no debugging information available


--
---
Praise the Caffeine embeddings


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



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

Re: [oi-dev] oi-userland rebuild failures

[Michal Nowak]

On 08/07/19 01:39 PM, Aurélien Larcher wrote:

Hi,
for reference, find the list of rebuild failures, some related to python 
3 migration of userland tools and pkg:


cluster/pcs -> invalid manifest after ruby update

desktop/gnome3/libgweather -> broken link

desktop/gnome3/seahorse -> missing dependency? Couldn't find 
'usr/lib/amd64/seahorse/xloadimage' in any of the specified search 
directories:


desktop/gnome3/evolution-data-server -> ld.so.1: EDataServer-1.2: fatal: 
libstdc++.so.6: version 'GLIBCXX_3.4.21' not found


developer/autogen -> 64-bit build fails which: no bash in ((null))

developer/jenkins -> pkgdepend issue

developer/opensp -> broken with new gettext

editor/bvi -> curses issue

editor/emacs -> segmentation fault

library/physfs -> wrong library path

network/openconnect -> obsolete required package and pkgdepend error

network/lftp -> curses issue

openindiana/illumos-closed -> publish does not execute prep

openindiana/qemu-kvm -> ctfmerge: failed to open ../cache-utils.o: File 
does not contain CTF data


Likely to be fixed with 
https://github.com/Mno-hime/oi-userland/commit/05ed355ec8da35eadd2ece43dd6b801cae547a68.




runtime/jruby -> java internal error

runtime/clisp -> missing localcharset.h probably broken with new gettext

sysutils/gtkperf -> broken with new gettext

sysutils/bacula -> bacula-fd not built in 64-bit

web/icedtea-web -> missing #include , obsolete since npapi 
dropped?


x11/compat-links -> fix makefile, pkgdepend issue

x11/compatibility -> fix makefile, pkgdepend issue

--
---
Praise the Caffeine embeddings


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



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

Re: [oi-dev] Image Packaging Developer's Guide

[Michal Nowak]

On 05/22/19 06:23 AM, Alexander Pyhalov via oi-dev wrote:

Hi.

We have CDDL-licensed Image Packaging Developer's Guide sources under 
https://github.com/OpenIndiana/pkg5/tree/oi/doc .

After small changes ( https://github.com/pyhalov/pkg5/tree/dev-guide ) I even 
could generate http://buildzone.oi-build.r61.net/pkg-guide/ .

I'm just interested, what do you think? Does it worth fixing/supporting this 
guide in this format or should we just merge relevant information to oi-docs?

Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department


Hi,

it looks like interesting documentation. We don't actually have 
abundance of IPS documentation. I think it should be merged with oi-docs.


Michal

___
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

[Michal Nowak]

On 05/15/19 09:23 PM, Gary Mills wrote:

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, this two pages should have most of what you were interested in wrt 
wiki (but login to the wiki first):


https://wiki.openindiana.org/dashboard.action#recently-worked
https://wiki.openindiana.org/users/viewnotifications.action

Michal

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

Re: [oi-dev] On the way to Firefox 68 ESR

[Michal Nowak]

On 05/11/19 02:35 PM, Aurélien Larcher wrote:

Hello,
thanks for doing this.

with Geoffrey Weiss we started working on the next Firefox ESR:

https://github.com/OpenIndiana/oi-userland/pull/4999


Which clang do you use?


developer/clang-40, the only one we have. ?

Maybe you should mention that people should not modify gcc headers in 
their global zone.


Just updated the PR, thanks.



Aurélien




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



--
---
Praise the Caffeine embeddings


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



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

[oi-dev] On the way to Firefox 68 ESR

[Michal Nowak]

Hi,

with Geoffrey Weiss we started working on the next Firefox ESR:

  https://github.com/OpenIndiana/oi-userland/pull/4999

Feel free to build it yourself (currently, you will get Firefox 66), 
share experience and ideas how to fix manual steps (2) and (3) in the 
PR, which are currently necessary to build it.


Michal

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

Re: [oi-dev] SMF service enabled by default in global zone

[Michal Nowak]

Toomas, Till, thank you, the IPS way worked for me.

Michal

On 05/07/19 10:31 PM, Toomas Soome via oi-dev wrote:

You need SMF profile. Google will help, also see /etc/svc/profile.

Sent from my iPhone


On 7 May 2019, at 23:27, Till Wegmüller  wrote:

Hi

The only way I know in the IPS framework is to use variants and two
seperate xml files for zone.global and zone.nonglobal environment

Greetings
Till


On 07.05.19 22:12, Michal Nowak wrote:
Hi,

I want to modify a SMF service so it's enabled by default once it's
installed in global zone. In non-global zone the service must be
disabled by default and may be enabled by admin manually (e.g. by
setting SMF prop value).

How do I do that in SMF? Is there an example of such a service already?

I figured out that '' does the
enablement, but how to limit this to global zone?

Thanks,
Michal

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


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



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



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

[oi-dev] SMF service enabled by default in global zone

[Michal Nowak]

Hi,

I want to modify a SMF service so it's enabled by default once it's 
installed in global zone. In non-global zone the service must be 
disabled by default and may be enabled by admin manually (e.g. by 
setting SMF prop value).


How do I do that in SMF? Is there an example of such a service already?

I figured out that '' does the 
enablement, but how to limit this to global zone?


Thanks,
Michal

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

Re: [oi-dev] Out of memory when trying to compile icinga2 with gcc6 - problem persists

[Michal Nowak]

On 01/14/19 10:37 AM, Marianne Spiller wrote:

Hi all,

nearly 1 year ago I asked the same and was not able to resolve this issue…

https://openindiana.org/pipermail/oi-dev/2018-March/005802.html

Now I’m back with a freshly updated hardware host and trying to compile 
icinga2-2.10.2. I made a change in my Makefile: |COMPONENT_BUILD_ARGS+= 
-j1|, but in comparison with the -j4 default the only difference are 
different values when crashing with out of memory. RAM consumption 
nearly 1.9GB when |Building CXX object 
lib/icinga/CMakeFiles/icinga.dir/icinga_unity.cpp.o|, swap leaving 
untouched.


It would be really nice to get some help on this ‘cause I’m stucked like 
I was last year at this point ;)


Cheers,
Marianne

|$ uname -a SunOS zfs-2011 5.11 illumos-9c7c0c4b59 i86pc i386 i86pc $ 
ulimit unlimited $ swap -lh swapfile dev swaplo blocks free 
/dev/zvol/dsk/rpool/swap 302,2 4K 31.9G 31.9G $ prtconf | grep Memory 
Memory size: 196495 Megabytes 
root@zfs-2011:/scratch/oi-userland/components/sysutils/icinga2# gmake 
sample-manifest /scratch/oi-userland/tools/userland-fetch --file 
/scratch/oi-userland/archives/icinga2-2.10.2.tar.gz --url 
https://github.com/Icinga/icinga2/archive/v2.10.2.tar.gz --hash 
sha256:99ab0c511a8a7014b9cf9467fe126d4a369026e9353f6e64c05ae39a15b32ad9 
Source /scratch/oi-userland/archives/icinga2-2.10.2.tar.gz... validating 
signature... skipping (no signature URL) validating hash... ok 
/usr/bin/touch /scratch/oi-userland/archives/icinga2-2.10.2.tar.gz 
/bin/rm -f -r 
/scratch/oi-userland/components/sysutils/icinga2/icinga2-2.10.2 
/usr/bin/env RUBY_VERSION=2.3 /scratch/oi-userland/tools/userland-unpack 
/scratch/oi-userland/archives/icinga2-2.10.2.tar.gz /usr/bin/touch 
/scratch/oi-userland/components/sysutils/icinga2/icinga2-2.10.2/.unpacked /usr/bin/touch 
/scratch/oi-userland/components/sysutils/icinga2/icinga2-2.10.2/.prep 
(/bin/rm -f -rf 
/scratch/oi-userland/components/sysutils/icinga2/build/amd64 ; 
/bin/mkdir -p 
/scratch/oi-userland/components/sysutils/icinga2/build/amd64) (cd 
/scratch/oi-userland/components/sysutils/icinga2/build/amd64 ; 
/usr/bin/env CONFIG_SHELL="/bin/bash" CC="/usr/gcc/6/bin/gcc" 
CXX="/usr/gcc/6/bin/g++" F77="/usr/gcc/6/bin/gfortran" 
FC="/usr/gcc/6/bin/gfortran" CFLAGS="-m64 -O3 " CXXFLAGS=" -m64 -O3 " 
FFLAGS=" -m64 -O3 " FCFLAGS="-m64 -O3 " LDFLAGS="-m64" 
PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig" \ cmake 
-DCMAKE_C_COMPILER:STRING="/usr/gcc/6/bin/gcc" 
-DCMAKE_CXX_COMPILER:STRING="/usr/gcc/6/bin/g++" 
-DCMAKE_Fortran_COMPILER:STRING="/usr/gcc/6/bin/gfortran" 
-DCMAKE_C_FLAGS:STRING="-m64 -O3 " -DCMAKE_CXX_FLAGS:STRING=" -m64 -O3 " 
-DCMAKE_Fortran_FLAGS:STRING="-m64 -O3 " LDFLAGS="-m64" 
PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig" 
-DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_INSTALL_BINDIR:PATH=bin 
-DCMAKE_INSTALL_LIBDIR:PATH=lib/amd64 -DCMAKE_INSTALL_SBINDIR:PATH=sbin 
-DCMAKE_INSTALL_DATAROOTDIR:PATH=share 
-DCMAKE_INSTALL_DATADIR:PATH=share 
-DCMAKE_INSTALL_INFODIR:PATH=share/info 
-DCMAKE_INSTALL_LOCALEDIR:PATH=share/locale 
-DCMAKE_INSTALL_MANDIR:PATH=share/man 
-DLIBEXEC_INSTALL_DIR="/usr/lib/amd64" 
-DLIB_INSTALL_DIR="/usr/lib/amd64" -DLIB_SUFFIX="/amd64" 
-DCMAKE_INSTALL_PREFIX="/usr" -DICINGA2_GIT_VERSION_INFO=OFF 
-DICINGA2_USER=icinga -DICINGA2_GROUP=icinga 
-DICINGA2_COMMAND_GROUP=icingacmd -DICINGA2_RUNDIR="/var/lib" 
-DCMAKE_INSTALL_SYSCONFDIR="/etc" 
-DICINGA2_SYSCONFIGFILE="/usr/lib/icinga2/icinga2" 
-DCMAKE_INSTALL_LOCALSTATEDIR="/var" 
-DICINGA2_PLUGINDIR="/usr/lib/nagios/plugins" -DICINGA2_UNITY_BUILD=ON 
-DICINGA2_LTO_BUILD=OFF -DUSE_SYSTEMD=OFF 
-DINSTALL_SYSTEMD_SERVICE_AND_INITSCRIPT=OFF -DICINGA2_WITH_CHECKER=ON 
-DICINGA2_WITH_COMPAT=ON -DICINGA2_WITH_DEMO=OFF 
-DICINGA2_WITH_HELLO=OFF -DICINGA2_WITH_LIVESTATUS=ON 
-DICINGA2_WITH_NOTIFICATION=ON -DICINGA2_WITH_PERFDATA=ON 
-DICINGA2_WITH_STUDIO=OFF -DICINGA2_WITH_TESTS=ON 
-DICINGA2_WITH_MYSQL=OFF -DICINGA2_WITH_PGSQL=OFF 
/scratch/oi-userland/components/sysutils/icinga2/icinga2-2.10.2) -- The 
C compiler identification is GNU 6.4.0 -- The CXX compiler 
identification is GNU 6.4.0 -- Check for working C compiler: 
/usr/gcc/6/bin/gcc -- Check for working C compiler: /usr/gcc/6/bin/gcc 
-- works -- Detecting C compiler ABI info -- Detecting C compiler ABI 
info - done -- Detecting C compile features -- Detecting C compile 
features - done -- Check for working CXX compiler: /usr/gcc/6/bin/g++ -- 
Check for working CXX compiler: /usr/gcc/6/bin/g++ -- works -- Detecting 
CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- 
Detecting CXX compile features -- Detecting CXX compile features - done 
-- Prefixing in ICINGA2_FULL_PKGDATADIR "share/icinga2" with /usr -- 
Prefixing in ICINGA2_FULL_INCLUDEDIR "share/icinga2/include" with /usr 
-- Looking for pthread.h -- Looking for pthread.h - found -- Looking for 
pthread_create -- Looking for pthread_create - found -- Found Threads: 
TRUE -- Boost version: 1.64.0 -- Found the following Boost libraries: -- 
thread -- 

Re: [oi-dev] build issue in percona-server-57

[Michal Nowak]

On 11/05/18 10:32 PM, Rich Reynolds wrote:


[ 32%] Building CXX object sql/CMakeFiles/binlog.dir/binlog_crypt_data.cc.o
/codebase/oi-userland/components/database/percona-server-57/percona-server-5.7.22-22/sql/binlog_crypt_data.cc: 
In member function 'void Binlog_crypt_data::free_key(uchar*&, 
std::size_t&)':
/codebase/oi-userland/components/database/percona-server-57/percona-server-5.7.22-22/sql/binlog_crypt_data.cc:62:37: 
error: 'memset_s' was not declared in this scope

  memset_s(key, 512, 0, key_length);
  ^
make[3]: *** [sql/CMakeFiles/binlog.dir/build.make:336: 
sql/CMakeFiles/binlog.dir/binlog_crypt_data.cc.o] Error 1




this a patching, upstream or makefile issue?  ill investigate if no one 
knows off the top of head


rich



I filed following ticket, you may want to follow it: 
https://jira.percona.com/browse/PS-5328. I'll update Percona Server 5.7 
once patch is available thru the ticket.


Michal

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

Re: [oi-dev] should packages have a pkg.description or not?

[Michal Nowak]

On 01/11/19 08:08 PM, Tim Mooney wrote:


All-

I'm new to oi-dev, though I've been on oi-discuss for years and have done
a little bit with oi-userland in the past.

My basic question is: Should we be including a package description
(pkg.description) in new packages we contribute, or should it
intentionally be left un-set?  Currently, some packages have a
pkg.description, but many do not.  I want to do it the "right" way, but
it's not clear to me which way that is.

I've done some searching of the oi-dev archives, but I don't see any
threads that discuss pkg.description.

Thanks,

Tim


Tim,

don't worry about "doing it right", provide a pull request to the 
project and during the review process, it will be find out, what's right.


Personally, I don't bother adding description, for the most part it's a 
nuisance in the `pkg search` output as it distorts it.


Michal

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

[oi-dev] Firefox 60esr

[Michal Nowak]

Aurélien,

does Firefox 60esr build from what's in your 'firefox60' branch?

I pulled from your 'firefox60' branch but I am unable to build Firefox, 
it fails with: "NSModules are not ordered appropriately". More at: 
https://paste.ec/paste/u-QGkgcO#Jf182EbyHq3Zt5s8MU9VVNHp3daKhtM-+z1OSxDkIrN


If I remove that check from firefox-60.3.0/toolkit/library/libxul.mk it 
fails with missing "Undefined symbol 'sendfile'": 
https://paste.ec/paste/Ov5E1DuC#s1uY-Msq9w7alg5xMgWPJLONv0kypS3yulQPjDxBh2b. 
When I fix it manually, it later hangs at:


Executing 
/export/home/newman/ws/oi-userland/components/web/firefox/build/amd64/dist/bin/shlibsign 
-v -o ../../dist/firefox/libsoftokn3.chk -i 
../../dist/firefox/libsoftokn3.so
moduleSpec configdir='' certPrefix='' keyPrefix='' secmod='' 
flags=noCertDB, noModDB


The process takes one whole core for an hour doing something. When I 
make SIGN_LIBS from firefox-60.3.0/toolkit/mozapps/installer/packager.py 
empty, it finally publishes, but the firefox process eventually dumps 
core (which is not that surprising for me reading your IRC posts :) ):


$ mdb core
mdb: core file data for mapping at 22fbf7c39000 not saved: Bad address
mdb: core file data for mapping at 22fbf7c59000 not saved: Bad address
Loading modules: [ libc.so.1 libnvpair.so.1 libuutil.so.1 libavl.so.1 
ld.so.1 ]

> ::status
debugging core file of firefox (64-bit) from lenovo
file: /usr/lib/amd64/firefox/firefox
initial argv: /usr/bin/firefox
threading model: native threads
status: process terminated by SIGSEGV (Segmentation Fault), pid=2975 
uid=101 code=-1

> $C
fd7fffdfe730 libc.so.1`_lwp_kill+0xa()
fd7fffdfe760 libc.so.1`raise+0x20(b)
000b 
libxul.so`_ZN13nsProfileLock18FatalSignalHandlerEiP7siginfoPv+0xff()


I am bit more surprised that Firefox 62 from Joyent's binary pkgsrc 
dumps for me as well: 
https://paste.ec/paste/xdeCYjGD#rSuQOzMOl+QmumtxpSLR1LU6WzblzSV7uroLrrua2eE


Michal

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

Re: [oi-dev] Mate Schema error ?

[Michal Nowak]

On 11/09/18 05:41 PM, Udo Grabowski (IMK) wrote:

On 09/11/2018 17:37, Aurélien Larcher wrote:

Did you install from 2018.10?


It's the current Hipster trunk as seen yesterday around Noon (UTC).



I have installed a few testing images in the past two weeks and this
issue does not occur.
I'll try to check if there are differences.

On 11/9/18, Udo Grabowski (IMK)  wrote:

On 09/11/2018 16:27, Aurélien Larcher wrote:



On Fri, Nov 9, 2018 at 12:06 PM Udo Grabowski (IMK)
mailto:udo.grabow...@kit.edu>> wrote:

    Hi, I noticed that the mouse right click menu is not available on
    MATE.

...






Do I have it right that you actually login to MATE as a *root*? That's 
something I never tested.


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

Re: [oi-dev] build issue in percona-server-57

[Michal Nowak]

On 11/06/18 01:07 AM, Rich Reynolds wrote:

On 11/5/18 2:38 PM, Bob Friesenhahn wrote:

On Mon, 5 Nov 2018, Rich Reynolds wrote:



[ 32%] Building CXX object 
sql/CMakeFiles/binlog.dir/binlog_crypt_data.cc.o
/codebase/oi-userland/components/database/percona-server-57/percona-server-5.7.22-22/sql/binlog_crypt_data.cc: 
In member function 'void Binlog_crypt_data::free_key(uchar*&, 
std::size_t&)':
/codebase/oi-userland/components/database/percona-server-57/percona-server-5.7.22-22/sql/binlog_crypt_data.cc:62:37: 
error: 'memset_s' was not declared in this scope

    memset_s(key, 512, 0, key_length);
    ^
make[3]: *** [sql/CMakeFiles/binlog.dir/build.make:336: 
sql/CMakeFiles/binlog.dir/binlog_crypt_data.cc.o] Error 1




this a patching, upstream or makefile issue?  ill investigate if no 
one knows off the top of head


This appears to be a C'11 function.  See 
https://en.cppreference.com/w/c/string/byte/memset.  Depending on C'11 
at this time is very optimistic.


What version of GCC are you using?

Bob

cmake was fine with 6.4.0

-- Running cmake version 3.11.3
-- Found Git: /usr/bin/git (found version "2.19.1")
-- Configuring with MAX_INDEXES = 64U
-- The C compiler identification is GNU 6.4.0
-- The CXX compiler identification is GNU 6.4.0
-- Check for working C compiler: /usr/gcc/6/bin/gcc
-- Check for working C compiler: /usr/gcc/6/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/gcc/6/bin/g++
-- Check for working CXX compiler: /usr/gcc/6/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done

and cuz more information is better than less:

-- CMAKE_BUILD_TYPE: RELEASE
-- COMPILE_DEFINITIONS: 
_FILE_OFFSET_BITS=64;__EXTENSIONS__;_POSIX_PTHREAD_SEMANTICS;_REENTRANT;_PTHREADS;BOOST_GEOMETRY_SQRT_CHECK_FINITENESS;HAVE_CONFIG_H;HAVE_LIBEVENT1 

-- CMAKE_C_FLAGS: -m32 -O3 -Wall -Wextra -Wformat-security -Wvla 
-Wwrite-strings -Wdeclaration-after-statement
-- CMAKE_CXX_FLAGS:  -m32 -O3 -Wall -Wextra -Wformat-security -Wvla 
-Woverloaded-virtual -Wno-unused-parameter

-- CMAKE_C_LINK_FLAGS:  -m32
-- CMAKE_CXX_LINK_FLAGS:  -m32
-- CMAKE_C_FLAGS_RELEASE: -O3 -DNDEBUG -DDBUG_OFF -DNDEBUG
-- CMAKE_CXX_FLAGS_RELEASE: -O3 -DNDEBUG -DDBUG_OFF -DNDEBUG
-- Configuring done

rich



Three months ago illumos added support for memset_s(3C) 
(https://www.illumos.org/issues/8548) before that it likely wasn't detected.


memset_s(3C) seems to require

  #define __STDC_WANT_LIB_EXT1__ 1
  #include 

I don't know how to do that properly in cmake/C++.

If anyone does know, I'll fix it in userland when updating Percona 
Server to 5.7.23-23.


This works for cmake to use GCC 7.3:

  GCC_VERSION = 7

Michal

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

Re: [oi-dev] Slow Loader on Samsung 950 Pro

[Michal Nowak]

I noticed this very same issue under vSphere 6.7 U1 when fully updated hipster 
is installed to emulated NVMe device (on SSD disk).

I haven't seen it on vSphere 6.7, but I might be wrong. Release notes 
(https://docs.vmware.com/en/VMware-vSphere/6.7/rn/vsphere-esxi-671-release-notes.html)
 for 6.7 U1 says something about new NVMe feature, but it's not clear to me if 
they have guest or host device in mind.

M.

On Monday, September 24, 2018 at 9:34 PM, Toomas Soome via oi-dev 
 wrote:
>> On 24 Sep 2018, at 21:20, Till Wegmüller  wrote:
>>
>> Hi Toomas
>>
>> The system was installed two weeks ago and updated about one week ago.
>> What I noticed when booting is:
>> The first spinner already akes a couple of seconds to load loader wheras
>> on the iso it takes at most one second.
> 
> So, in your case the disk (not cd) io is to be investigated.
> 
>> What takes most time is Display of available memory after displaying the
>> seem bios drives.
>>
> 
> That is the biosdisk init and zfs probe, yes.
> 
>> Loading things like the string class is fast as expected.
>> Loading menu config and boot_archive from disk is what takes most time.
>>
>> Your dev version of loader gets as far as printing the system bios
>> drives on white background and then stop
> 
> That probably means it stops while probing for zfs pools. So we need to
> investigate, why... but for that we need to insert some debug printouts.
> 
>> Loader on Hipster takes some time to print the bios memory then it
>> continious.
>>
>> Loader from your dev link also sees a fd device which current stable
>> loader does not. I have no Floppy disk device in that computer.
>> Does this help?
>>
> 
> A bit,  but we definitely need to investigate it further.  Anyhow, I only
> can check email this week, I left my laptop home on purpose:)
> 
> Rgds,
> Toomas
>>
>>> On 09/24/18 02:55 PM, Toomas Soome via oi-dev wrote:
>>> Forgot to note, you should also be able to boot usb/iso, press esc from
>>> menu. Then use beadm list zfs:rpool and beadm activate zfs:rpool and
>>> then enter boot
>>>
>>> Sent from my iPhone
>>>
 On 24 Sep 2018, at 15:40, Toomas Soome via oi-dev
  wrote:

 Installed or pkg update is also done?

 I am on the trip this week and can not help with code, but from
 http://148.52.235.80.sta.estpak.ee you can find iso/usb image, and
 from it you can copy the dev version of loader binary. You can copy it
 with new name and if you press the space just when the first spinner,
 you can enter the new name.

 Basically I’d like to establish if the error is actually fixed...

 Sent from my iPhone

> On 24 Sep 2018, at 15:18, Till Wegmüller 
> wrote:
>
> Hi Setup is most recent Hipster installed two weeks ago.
>
> Greetings
> Till
>> On 9/24/18 1:44 PM, Toomas Soome via oi-dev wrote:
>> What version, or how old is the setup? The older ones had some cases
>> where the read past disk end and with some systems this can cause
>> slowdown as described.
>>
>> Rgds,
>> Toomas
>>
>> Sent from my iPhone
>>
>>> On 24 Sep 2018, at 13:03, Till Wegmüller 
>>> wrote:
>>>
>>> Hello
>>>
>>> Has anybody tested loader on an NVME Disk? I have two Samsung 950
>>> Pro in
>>> a mirror Zpool Configuration. They are nicely fast but not during
>>> boot.
>>> To be more precise loader requires more than 20minutes to get to
>>> the
>>> point at which it has loaded the kernel and Ramdisk into memory.
>>> From
>>> there the Kernel requires about 10-20 seconds to boot to graphical
>>> desktop.
>>>
>>> I would like to start debugging that issue. Where can I start?
>>>
>>> Thanks and Greetings
>>> Till
>>>
>>> ___
>>> oi-dev mailing list
>>> oi-dev@openindiana.org
>>> https://openindiana.org/mailman/listinfo/oi-dev
>>
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
>>
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

 ___
 oi-dev mailing list
 oi-dev@openindiana.org
 https://openindiana.org/mailman/listinfo/oi-dev
>>>
>>> ___
>>> oi-dev mailing list
>>> oi-dev@openindiana.org
>>> https://openindiana.org/mailman/listinfo/oi-dev
>>>
>>
>> ___
>> 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] 2018.10 targets

[Michal Nowak]

On 09/29/18 09:01 AM, Michal Nowak wrote:

On 09/28/18 10:41 AM, Alexander Pyhalov via oi-dev wrote:

Hi, folks.

We are approaching October. While I have limited time now, I want to
coordinate priorities and targets, what should we do till end of
October (and due to personal reasons, I'd better announce snapshot
till 20 October or earlier or allow someone else to do this).

We have several regressions and problems, which would be good to
fix.

1) Virtualbox failure after FPU changes
https://www.illumos.org/issues/9761 ,
https://www.virtualbox.org/ticket/17947 is a serious one, but I'm
afraid I lack skills to fix it in reasonable time. The stack trace
itself doesn't seem related to illumos-gate changes, but likely it
is. In KVM Joyent fixed this using new hma_fpu_* API, but Virtualbox
structures to store VM registers differ and from brief overlook it
has several asm functions to store/restore Host/Base registers state.
So far I don't have an idea how convert one to another. So, this
likely will be broken in 2018.10 unless someone skillful dig into
this.

2) sbcl issues - threaded sbcl can not be built after KPTI changes,
it fails FLOCK and posix tests. Needs investigation. It's a serious
issue, because threaded sbcl is needed to build pgloader.

3) Our Mate is a bit old, but newer Mate requires updated GTK3 .
Updated GTK3 IIRC has dropped support for theme engines, and so our
Nimbus theme based on unico engine doesn't work. Also I've heard
there were issues with new mate-terminal. Michal, do you have some
comments here?


I run MATE 1.20 as seen in the PR and it works fine but:

(1) Nimbus theme. I stick to "Traditional" theme.

(2) Pluma text editor's text area blinks annoyingly. Might be an 
Intel-only issue. Upstream issue reported.


(3) MATE Terminal requires new vte library which does not work for us. 
 From my investigation I noticed that some #ifdef __sun were removed 
from newer vte. Also I haven't seen new vte for non-Linux OS (pkgsrc, 
BSDs, ...).


(3) is now resolved in my mate_1.20 branch. It's also updated to the 
latest MATE 1.20 code stream. The missing piece is chopping the huge PR 
to pieces our builder can actually consume.




I don't think I am able to do anything about those.



4) As for new features, I really want to see KVM zones, perhaps, I'll
dig into this shortly.

Does somebody have another targets/comments?


I will work on openQA tests for them to be in shape for the snapshot and 
test the images once test-snapshot is available.


I run a test build on Sunday and with some fixes and tweaking our openQA 
tests are ready: 
https://openqa.oi.mnowak.cz/tests/overview?distri=openindiana=hipster=20181006=1.


This time around I am not scheduling VirtualBox jobs as keeping them 
alive was too much pain.


Michal



Also I had some progress with Meson but can't promise this.

Michal



Please, avoid turning this topic in bike-shedding, I want to hear OI
developers in a way "I ll take item #N" or "I expect to finish
feature A before snapshot", not "please, also fix this and that".

Best regards, Alexander Pyhalov, system administrator of Southern
Federal University IT department



___ 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] 2018.10 targets

[Michal Nowak]

On 09/28/18 10:41 AM, Alexander Pyhalov via oi-dev wrote:

Hi, folks.

We are approaching October. While I have limited time now, I want to
coordinate priorities and targets, what should we do till end of
October (and due to personal reasons, I'd better announce snapshot
till 20 October or earlier or allow someone else to do this).

We have several regressions and problems, which would be good to
fix.

1) Virtualbox failure after FPU changes
https://www.illumos.org/issues/9761 ,
https://www.virtualbox.org/ticket/17947 is a serious one, but I'm
afraid I lack skills to fix it in reasonable time. The stack trace
itself doesn't seem related to illumos-gate changes, but likely it
is. In KVM Joyent fixed this using new hma_fpu_* API, but Virtualbox
structures to store VM registers differ and from brief overlook it
has several asm functions to store/restore Host/Base registers state.
So far I don't have an idea how convert one to another. So, this
likely will be broken in 2018.10 unless someone skillful dig into
this.

2) sbcl issues - threaded sbcl can not be built after KPTI changes,
it fails FLOCK and posix tests. Needs investigation. It's a serious
issue, because threaded sbcl is needed to build pgloader.

3) Our Mate is a bit old, but newer Mate requires updated GTK3 .
Updated GTK3 IIRC has dropped support for theme engines, and so our
Nimbus theme based on unico engine doesn't work. Also I've heard
there were issues with new mate-terminal. Michal, do you have some
comments here?


I run MATE 1.20 as seen in the PR and it works fine but:

(1) Nimbus theme. I stick to "Traditional" theme.

(2) Pluma text editor's text area blinks annoyingly. Might be an 
Intel-only issue. Upstream issue reported.


(3) MATE Terminal requires new vte library which does not work for us. 
From my investigation I noticed that some #ifdef __sun were removed 
from newer vte. Also I haven't seen new vte for non-Linux OS (pkgsrc, 
BSDs, ...).


I don't think I am able to do anything about those.



4) As for new features, I really want to see KVM zones, perhaps, I'll
dig into this shortly.

Does somebody have another targets/comments?


I will work on openQA tests for them to be in shape for the snapshot and 
test the images once test-snapshot is available.


Also I had some progress with Meson but can't promise this.

Michal



Please, avoid turning this topic in bike-shedding, I want to hear OI
developers in a way "I ll take item #N" or "I expect to finish
feature A before snapshot", not "please, also fix this and that".

Best regards, Alexander Pyhalov, system administrator of Southern
Federal University IT department



___ 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] Rust 1.28 testing package

[Michal Nowak]

On 09/12/18 08:42 PM, Till Wegmüller wrote:

Hi Aurelian

Nice work.

I tested a few Rust programs acros github trending at random to see how
we are with workflow compliance.

cargo seems to work and can be used to install programs.
Tested:
https://github.com/sharkdp/bat simple cat clone: Does not work the
termios library does not know about us.

https://github.com/rust-lang-nursery/rustup.rs/ Seems to be very
unstable... They recomend that a packager pckages it. We maybe should
aswell seing that many rust utilities seem to require their very
specific version of rust.. Including firefox.

https://github.com/uutils/coreutils Does not seem to like that our libc
has no ENOATTR


I guess https://github.com/Stebalien/xattr/issues/18 is what you see? 
There's workaround for this in xattr v0.2.2, but I thought is fixed by 
following rust's libc patches which define ENOATTR as ENODATA:


* src_vendor_libc_src_unix_solaris_mod.rs.patch
* src_liblibc_src_unix_solaris_mod.rs.patch

But yes along the way there are another platform-specific problems like:

error[E0432]: unresolved import `self::libc::TIOCGWINSZ`
 --> 
/export/home/newman/.cargo/registry/src/github.com-1ecc6299db9ec823/termsize-0.1.5/src/nix.rs:4:33

  |
4 | use self::libc::{STDOUT_FILENO, TIOCGWINSZ, c_ushort};
  | ^^ no `TIOCGWINSZ` in the root

Michal



All in all i would say the compiler works it was saying that many
packages were compiling without errors. But the work has just begun.
There seems to be very much platform specific code in rust libraries in
the wild.

Keep up the good work
Greetings
Till

On 09/12/18 02:30 PM, Aurélien Larcher wrote:

For anyone interested there is a testing package of rust 1.28 at

https://pkg.openindiana.org/gcc-next/

pkg://userland/developer/lang/rustc@1.28.0,5.11-2018.0.0.0:20180912T121658Z

The repository is built with gcc-8 so a new BE and a good bandwidth are
required.

--
---
Praise the Caffeine embeddings


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



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



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

Re: [oi-dev] Rust in userland?

[Michal Nowak]

On 08/21/18 11:16 PM, Aurélien Larcher wrote:



On Tue, Aug 21, 2018 at 11:10 PM, Michal Nowak <mailto:mno...@startmail.com>> wrote:


On 08/16/18 07:31 PM, Aurélien Larcher wrote:



On Thu, Aug 16, 2018 at 7:18 PM, Aurélien Larcher
mailto:aurelien.larc...@gmail.com>
<mailto:aurelien.larc...@gmail.com
<mailto:aurelien.larc...@gmail.com>>> wrote:






https://github.com/cgrzemba/oi-userland/tree/rust/components/developer/rust

<https://github.com/cgrzemba/oi-userland/tree/rust/components/developer/rust>

<https://github.com/cgrzemba/oi-userland/tree/rust/components/developer/rust


<https://github.com/cgrzemba/oi-userland/tree/rust/components/developer/rust>>


         I remember now updating my recipe to yours but I needed
some
         configuration tweaks to deal with a few issues:
         - /usr/bin/cc is default used as linker but it is
sunstudio 12.1
         so you need to override it,
         - AR should be specified,
         - this recipe assumes that GCC runtime libraries are in
         /usr/lib/$(MACH64) which is not true for us with GCC >= 6,
         - the linker should be specified for the target as it
is not
         passed from the global settings.

         Also rustc will eat up to 3GB of RAM so the host should
have
         enough memory.


     Just rebased my change over Carsten's branch:

https://github.com/alarcher/oi-userland/tree/rust123
<https://github.com/alarcher/oi-userland/tree/rust123>
     <https://github.com/alarcher/oi-userland/tree/rust123
<https://github.com/alarcher/oi-userland/tree/rust123>>


More work:

helios> rustc hello.rs <http://hello.rs> <http://hello.rs>
error[E0463]: can't find crate for `std`

error: aborting due to previous error

helios> ls /usr/lib/amd64/rustlib/x86_64-sun-solaris/
analysis/ lib/

but rust looks for libraries in /usr/lib/rustlib

Symlinked like a piggy to check it and it is the problem...

Also rustc does not put /usr/lib/amd64 in the search path so
executables are broken.


I build Aurélien's branch inside a zone, but it fails for me with:

error: could not exec the linker `/usr/gcc/6/bin/gcc`: Not enough
space (os error 12)

For full log, see
https://paste.ec/paste/JxbabBm7#Kn+gh58pAwBhweYcTzrk6gzVSH7Rc6Npg2eXEmoCMv1

<https://paste.ec/paste/JxbabBm7#Kn+gh58pAwBhweYcTzrk6gzVSH7Rc6Npg2eXEmoCMv1>.

I am quite sure that I have plenty of disk space available:

$ df -h .
Filesystem             Size   Used  Available Capacity  Mounted on
rpool/zones/build/build-userland/ROOT/zbe-125
                        114G  14.7G      74.9G    17%    /

Any idea what the problem might be? I build it on Lenovo X220 (4
cores, 6 GB of memory + 3 GB of swap), OS is updated to latest
packages. I don't think I limited the zone in any way when I created it.



I have seen one instance of rustc take more than 3GB so you probably ran 
out of mem.


I guess that's the only logical explanation, especially when the same 
component sources work for you. Hence I don't have a suitable system to 
work this on.


I also tried to bump rust to 1.28 but failed short as "-nodefaultlibs" 
is getting my way: 
https://github.com/mno-hime/oi-userland/tree/rust/components/developer/rust.


M.

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

Re: [oi-dev] Rust in userland?

[Michal Nowak]

On 08/16/18 07:31 PM, Aurélien Larcher wrote:



On Thu, Aug 16, 2018 at 7:18 PM, Aurélien Larcher 
mailto:aurelien.larc...@gmail.com>> wrote:







https://github.com/cgrzemba/oi-userland/tree/rust/components/developer/rust




I remember now updating my recipe to yours but I needed some
configuration tweaks to deal with a few issues:
- /usr/bin/cc is default used as linker but it is sunstudio 12.1
so you need to override it,
- AR should be specified,
- this recipe assumes that GCC runtime libraries are in
/usr/lib/$(MACH64) which is not true for us with GCC >= 6,
- the linker should be specified for the target as it is not
passed from the global settings.

Also rustc will eat up to 3GB of RAM so the host should have
enough memory.


Just rebased my change over Carsten's branch:

https://github.com/alarcher/oi-userland/tree/rust123



More work:

helios> rustc hello.rs 
error[E0463]: can't find crate for `std`

error: aborting due to previous error

helios> ls /usr/lib/amd64/rustlib/x86_64-sun-solaris/
analysis/ lib/

but rust looks for libraries in /usr/lib/rustlib

Symlinked like a piggy to check it and it is the problem...

Also rustc does not put /usr/lib/amd64 in the search path so executables 
are broken.


I build Aurélien's branch inside a zone, but it fails for me with:

error: could not exec the linker `/usr/gcc/6/bin/gcc`: Not enough space 
(os error 12)


For full log, see 
https://paste.ec/paste/JxbabBm7#Kn+gh58pAwBhweYcTzrk6gzVSH7Rc6Npg2eXEmoCMv1.


I am quite sure that I have plenty of disk space available:

$ df -h .
Filesystem Size   Used  Available Capacity  Mounted on
rpool/zones/build/build-userland/ROOT/zbe-125
   114G  14.7G  74.9G17%/

Any idea what the problem might be? I build it on Lenovo X220 (4 cores, 
6 GB of memory + 3 GB of swap), OS is updated to latest packages. I 
don't think I limited the zone in any way when I created it.


Thanks,
Michal

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

[oi-dev] Build server not building new illumos

[Michal Nowak]

Hi,

it seems that our build server is not producing new illumos builds for a 
couple of days. The error at 
https://hipster.openindiana.org/logs/illumos-gate/latest/openindiana.illumos-gate.publish.log 
is:


From git://github.com/illumos/illumos-gate
 * branch  HEAD   -> FETCH_HEAD
error: Your local changes to the following files would be overwritten by 
merge:

usr/src/lib/libc/port/mapfile-vers
Please commit your changes or stash them before you merge.
Aborting
Updating 6640c13bea..9fed930b55

Can someone with access to the build server fix it, please?

Thanks,
Michal

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

Re: [oi-dev] Rust in userland?

[Michal Nowak]

On 08/14/18 09:01 AM, Till Wegmüller wrote:

Hi

Could you use an earlier version of Rust as bootstrap for the current rust?

There should be a guide for rust bootstraping around on the internet.

You can look at golang 1.8 how bootstraping with an earlier version works.

The Reason for that is, that we build all packages on a buildserver with
jenkins. Where we will not install pkgsrc packages.

Can you also check platform support? Last I remember solarish systems
where a secondary platform and required patches.

In any case when you need a reviewer just tag me on github i'll gladly
take a look.

Thanks and Greetings
Till



Hi Till,

I noticed that Joyent has very recent rust bootstraps, e.g. 
https://us-east.manta.joyent.com/pkgsrc/public/pkg-bootstraps/rust-1.28.0-x86_64-sun-solaris.tar.gz, 
which we could leverage as an internal payload of the rust component. At 
least initially.


Looking at platform support 
(https://forge.rust-lang.org/platform-support.html), Solaris is Tier 2 
platform for which standard library is guaranteed to build, though 
looking at Joyent's rust it seems to me that rustc and cargo are doable 
as well.


Thank you for your support, I'll get back to you when something 
materialize :).


Michal


On 13.08.2018 22:39, Michal Nowak wrote:

Hi,

it seems that rust lang is needed for compilation of Thunderbird 60 and
Firefox 60 ESR. Did anyone worked on rust component for userland?

If not, I thought on packaging it (and cargo) from scratch using
pkgsrc's Makefile and Joyent's rust in binary pkgsrc as rust is needed
for building itself.

Michal

___
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] Rust in userland?

[Michal Nowak]

On 08/15/18 05:19 PM, Aurélien Larcher wrote:



On Wed, Aug 15, 2018 at 7:56 AM, Carsten Grzemba <mailto:grze...@contac-dt.de>> wrote:




On 14.08.18 18:38, *Andreas Wacknitz * mailto:a.wackn...@gmx.de>> wrote:

Am 13.08.18 um 22:39 schrieb Michal Nowak:
> Hi,
>
> it seems that rust lang is needed for compilation of Thunderbird 60
> and Firefox 60 ESR. Did anyone worked on rust component for
userland?
>
> If not, I thought on packaging it (and cargo) from scratch using
> pkgsrc's Makefile and Joyent's rust in binary pkgsrc as rust is
needed
> for building itself.



I wrote a rust component last year and use it for a while but I had no 
time to follow up.

Not sure on which machine it was, I'll have a look in the week-end.



Would be cool if you found the component's sources, Aurélien. Carsten's 
component looks like a nice start, though I'd love to compare both 
approaches.


Thanks,
Michal


>
> Michal
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org <mailto:oi-dev@openindiana.org>
> https://openindiana.org/mailman/listinfo/oi-dev
<https://openindiana.org/mailman/listinfo/oi-dev>
Go for it!

Regards
Andreas

___
oi-dev mailing list
oi-dev@openindiana.org <mailto:oi-dev@openindiana.org>
https://openindiana.org/mailman/listinfo/oi-dev
<https://openindiana.org/mailman/listinfo/oi-dev>
-- 
Carsten Grzemba

I did this

https://github.com/cgrzemba/oi-userland/tree/rust
<https://github.com/cgrzemba/oi-userland/tree/rust>

but I havn't any time for test.

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




--
---
Praise the Caffeine embeddings


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



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

Re: [oi-dev] Rust in userland?

[Michal Nowak]

On 08/15/18 07:56 AM, Carsten Grzemba wrote:



On 14.08.18 18:38, *Andreas Wacknitz *  wrote:

Am 13.08.18 um 22:39 schrieb Michal Nowak:
> Hi,
>
> it seems that rust lang is needed for compilation of Thunderbird 60
> and Firefox 60 ESR. Did anyone worked on rust component for userland?
>
> If not, I thought on packaging it (and cargo) from scratch using
> pkgsrc's Makefile and Joyent's rust in binary pkgsrc as rust is needed
> for building itself.
>
> Michal
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
Go for it!

Regards
Andreas

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

--
Carsten Grzemba
I did this

https://github.com/cgrzemba/oi-userland/tree/rust

but I havn't any time for test.


Thank you Carsten, that looks like a great start! I'll go with this.

Michal

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

[oi-dev] Rust in userland?

[Michal Nowak]

Hi,

it seems that rust lang is needed for compilation of Thunderbird 60 and 
Firefox 60 ESR. Did anyone worked on rust component for userland?


If not, I thought on packaging it (and cargo) from scratch using 
pkgsrc's Makefile and Joyent's rust in binary pkgsrc as rust is needed 
for building itself.


Michal

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

Re: [oi-dev] Problems publishing zziplib

[Michal Nowak]

On 08/02/18 10:42 PM, Michal Nowak wrote:

On 08/02/18 05:08 PM, Andreas Wacknitz wrote:

Am 02.08.2018 um 15:30 schrieb Michal Nowak:
On Thursday, August 2, 2018 at 1:01 PM, Andreas Wacknitz 
 wrote:

Hi,

In my new build environment I have problems with zziplib. I have 
created

a new sample-manifest an compared it to the original:

diff sample-manifest.p5m sample-manifest.p5m.orig
13c13
< # Copyright 2018 
---

# Copyright 2017 

121a122,131

file path=usr/share/man/man3/zzip_dir_alloc.3
file path=usr/share/man/man3/zzip_dir_alloc_ext_io.3
file path=usr/share/man/man3/zzip_dir_free.3
file path=usr/share/man/man3/zzip_dir_open.3
file path=usr/share/man/man3/zzip_dir_open_ext_io.3
file path=usr/share/man/man3/zzip_dir_read.3
file path=usr/share/man/man3/zzip_dir_real.3
file path=usr/share/man/man3/zzip_dir_stat.3
file path=usr/share/man/man3/zzip_dirfd.3
file path=usr/share/man/man3/zzip_dirhandle.3

154a165,193

file path=usr/share/man/man3/zzip_error.3
file path=usr/share/man/man3/zzip_file_real.3
file path=usr/share/man/man3/zzip_file_stat.3
file path=usr/share/man/man3/zzip_fopen.3
file path=usr/share/man/man3/zzip_fread.3
file path=usr/share/man/man3/zzip_freopen.3
file path=usr/share/man/man3/zzip_fstat.3
file path=usr/share/man/man3/zzip_get_default_io.3
file path=usr/share/man/man3/zzip_init_io.3
file path=usr/share/man/man3/zzip_open.3
file path=usr/share/man/man3/zzip_open_ext_io.3
file path=usr/share/man/man3/zzip_open_shared_io.3
file path=usr/share/man/man3/zzip_opendir.3
file path=usr/share/man/man3/zzip_opendir_ext_io.3
file path=usr/share/man/man3/zzip_read.3
file path=usr/share/man/man3/zzip_realdir.3
file path=usr/share/man/man3/zzip_realfd.3
file path=usr/share/man/man3/zzip_rewinddir.3
file path=usr/share/man/man3/zzip_seek.3
file path=usr/share/man/man3/zzip_seek32.3
file path=usr/share/man/man3/zzip_seekdir.3
file path=usr/share/man/man3/zzip_seekdir32.3
file path=usr/share/man/man3/zzip_seterror.3
file path=usr/share/man/man3/zzip_strerror.3
file path=usr/share/man/man3/zzip_strerror_of.3
file path=usr/share/man/man3/zzip_tell.3
file path=usr/share/man/man3/zzip_tell32.3
file path=usr/share/man/man3/zzip_telldir.3
file path=usr/share/man/man3/zzip_telldir32.3


At least some of the missing man pages actually cannot be shown on my
system with the zziplib package installed, eg.
man zzip_dir_alloc
mandoc: zzip_dir_alloc_ext_io.3: ERROR: No such file or directory
()
()

See the file zzip_dir_alloc_ext_io.3.

 August 2,
2018  ()




I am not sure how to proceed here. Is it a problem on my build env 
or do

others have the same problems?

Regards,
Andreas


I was able to build the component recently.
I used to be able to publish it, too. But not with my new build 
environment.
Sometime I start from scratch in order to find errors we don't find 
otherwise.
I have a list of packages that don't build or publish for one reason 
or another (part of my components.ignore):


# Failing packages for aw
#
/^archiver\/zziplib$/d
/^database\/pgloader$/d
/^developer\/golang-110$/d
/^editor\/emacs$/d
/^library\/glibmm$/d
/^library\/goffice$/d
/^library\/libgtop$/d
/^library\/p11-kit$/d
/^library\/physfs$/d
/^multimedia\/sox$/d
/^python\/coherence$/d
/^scientific\/gdl$/d
/^sysutils\/clamav$/d
/^text\/hunspell-de$/d
/^text\/tidy$/d

This list is typically growing and from time to time I start to 
investigate and try to fix the problems (or ask for help ;-)).
For example our emacs build isn't working at all. It has lisp compile 
errros that are easily overseen during the build process.
Alarcher already confirmed this but has no time to fix it. I already 
tried to build it with different compiler versions but with no luck yet.
Furthermore, emacs-26.1 has the same problems. So even creating a 
newer version doesn't solve the problem at the moment.


Are all build requirements present in the environment? Specifically 
text/xmlto. I configure script able to detect it properly?
I I have created a simple script that I maintain that install almost 
everything. (BTW: If you have a better solution for creating build 
envs I am open for suggestions.

Maintaining a big script is tedious and errorprone.)
So yes, xmlto and xmltoman are installed.



Are those man pages generated or just not installed in the proto area?

They are in the proto area (or should be).
Can you check for me whether my example works for you:
 man zzip_disk_buffer
gives an error for me (the installed package seems to have serveral 
errors like this). Even if it builds and publishes on your 
environment, there seem to be a problem with the package.
Did you start from a clean environment? I usually start with a 'gmake 
clean' and also remove former source folders (if the version has 
changed).

Our build enviroment isnt't really well prepared for removes of files.

Andreas


It seems to me like a bug in docbook-xsl: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831831 Onc

Re: [oi-dev] Problems publishing zziplib

[Michal Nowak]

On 08/02/18 05:08 PM, Andreas Wacknitz wrote:

Am 02.08.2018 um 15:30 schrieb Michal Nowak:
On Thursday, August 2, 2018 at 1:01 PM, Andreas Wacknitz 
 wrote:

Hi,

In my new build environment I have problems with zziplib. I have created
a new sample-manifest an compared it to the original:

diff sample-manifest.p5m sample-manifest.p5m.orig
13c13
< # Copyright 2018 
---

# Copyright 2017 

121a122,131

file path=usr/share/man/man3/zzip_dir_alloc.3
file path=usr/share/man/man3/zzip_dir_alloc_ext_io.3
file path=usr/share/man/man3/zzip_dir_free.3
file path=usr/share/man/man3/zzip_dir_open.3
file path=usr/share/man/man3/zzip_dir_open_ext_io.3
file path=usr/share/man/man3/zzip_dir_read.3
file path=usr/share/man/man3/zzip_dir_real.3
file path=usr/share/man/man3/zzip_dir_stat.3
file path=usr/share/man/man3/zzip_dirfd.3
file path=usr/share/man/man3/zzip_dirhandle.3

154a165,193

file path=usr/share/man/man3/zzip_error.3
file path=usr/share/man/man3/zzip_file_real.3
file path=usr/share/man/man3/zzip_file_stat.3
file path=usr/share/man/man3/zzip_fopen.3
file path=usr/share/man/man3/zzip_fread.3
file path=usr/share/man/man3/zzip_freopen.3
file path=usr/share/man/man3/zzip_fstat.3
file path=usr/share/man/man3/zzip_get_default_io.3
file path=usr/share/man/man3/zzip_init_io.3
file path=usr/share/man/man3/zzip_open.3
file path=usr/share/man/man3/zzip_open_ext_io.3
file path=usr/share/man/man3/zzip_open_shared_io.3
file path=usr/share/man/man3/zzip_opendir.3
file path=usr/share/man/man3/zzip_opendir_ext_io.3
file path=usr/share/man/man3/zzip_read.3
file path=usr/share/man/man3/zzip_realdir.3
file path=usr/share/man/man3/zzip_realfd.3
file path=usr/share/man/man3/zzip_rewinddir.3
file path=usr/share/man/man3/zzip_seek.3
file path=usr/share/man/man3/zzip_seek32.3
file path=usr/share/man/man3/zzip_seekdir.3
file path=usr/share/man/man3/zzip_seekdir32.3
file path=usr/share/man/man3/zzip_seterror.3
file path=usr/share/man/man3/zzip_strerror.3
file path=usr/share/man/man3/zzip_strerror_of.3
file path=usr/share/man/man3/zzip_tell.3
file path=usr/share/man/man3/zzip_tell32.3
file path=usr/share/man/man3/zzip_telldir.3
file path=usr/share/man/man3/zzip_telldir32.3


At least some of the missing man pages actually cannot be shown on my
system with the zziplib package installed, eg.
man zzip_dir_alloc
mandoc: zzip_dir_alloc_ext_io.3: ERROR: No such file or directory
()
()

See the file zzip_dir_alloc_ext_io.3.

 August 2,
2018  ()




I am not sure how to proceed here. Is it a problem on my build env or do
others have the same problems?

Regards,
Andreas


I was able to build the component recently.
I used to be able to publish it, too. But not with my new build 
environment.
Sometime I start from scratch in order to find errors we don't find 
otherwise.
I have a list of packages that don't build or publish for one reason or 
another (part of my components.ignore):


# Failing packages for aw
#
/^archiver\/zziplib$/d
/^database\/pgloader$/d
/^developer\/golang-110$/d
/^editor\/emacs$/d
/^library\/glibmm$/d
/^library\/goffice$/d
/^library\/libgtop$/d
/^library\/p11-kit$/d
/^library\/physfs$/d
/^multimedia\/sox$/d
/^python\/coherence$/d
/^scientific\/gdl$/d
/^sysutils\/clamav$/d
/^text\/hunspell-de$/d
/^text\/tidy$/d

This list is typically growing and from time to time I start to 
investigate and try to fix the problems (or ask for help ;-)).
For example our emacs build isn't working at all. It has lisp compile 
errros that are easily overseen during the build process.
Alarcher already confirmed this but has no time to fix it. I already 
tried to build it with different compiler versions but with no luck yet.
Furthermore, emacs-26.1 has the same problems. So even creating a newer 
version doesn't solve the problem at the moment.


Are all build requirements present in the environment? Specifically 
text/xmlto. I configure script able to detect it properly?
I I have created a simple script that I maintain that install almost 
everything. (BTW: If you have a better solution for creating build envs 
I am open for suggestions.

Maintaining a big script is tedious and errorprone.)
So yes, xmlto and xmltoman are installed.



Are those man pages generated or just not installed in the proto area?

They are in the proto area (or should be).
Can you check for me whether my example works for you:
     man zzip_disk_buffer
gives an error for me (the installed package seems to have serveral 
errors like this). Even if it builds and publishes on your environment, 
there seem to be a problem with the package.
Did you start from a clean environment? I usually start with a 'gmake 
clean' and also remove former source folders (if the version has changed).

Our build enviroment isnt't really well prepared for removes of files.

Andreas


It seems to me like a bug in docbook-xsl: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831831 Once I add that 
patch, the man page is in corr

Re: [oi-dev] Problems publishing zziplib

[Michal Nowak]

On Thursday, August 2, 2018 at 1:01 PM, Andreas Wacknitz  
wrote:
> Hi,
> 
> In my new build environment I have problems with zziplib. I have created
> a new sample-manifest an compared it to the original:
> 
> diff sample-manifest.p5m sample-manifest.p5m.orig
> 13c13
> < # Copyright 2018 
> ---
>> # Copyright 2017 
> 121a122,131
>> file path=usr/share/man/man3/zzip_dir_alloc.3
>> file path=usr/share/man/man3/zzip_dir_alloc_ext_io.3
>> file path=usr/share/man/man3/zzip_dir_free.3
>> file path=usr/share/man/man3/zzip_dir_open.3
>> file path=usr/share/man/man3/zzip_dir_open_ext_io.3
>> file path=usr/share/man/man3/zzip_dir_read.3
>> file path=usr/share/man/man3/zzip_dir_real.3
>> file path=usr/share/man/man3/zzip_dir_stat.3
>> file path=usr/share/man/man3/zzip_dirfd.3
>> file path=usr/share/man/man3/zzip_dirhandle.3
> 154a165,193
>> file path=usr/share/man/man3/zzip_error.3
>> file path=usr/share/man/man3/zzip_file_real.3
>> file path=usr/share/man/man3/zzip_file_stat.3
>> file path=usr/share/man/man3/zzip_fopen.3
>> file path=usr/share/man/man3/zzip_fread.3
>> file path=usr/share/man/man3/zzip_freopen.3
>> file path=usr/share/man/man3/zzip_fstat.3
>> file path=usr/share/man/man3/zzip_get_default_io.3
>> file path=usr/share/man/man3/zzip_init_io.3
>> file path=usr/share/man/man3/zzip_open.3
>> file path=usr/share/man/man3/zzip_open_ext_io.3
>> file path=usr/share/man/man3/zzip_open_shared_io.3
>> file path=usr/share/man/man3/zzip_opendir.3
>> file path=usr/share/man/man3/zzip_opendir_ext_io.3
>> file path=usr/share/man/man3/zzip_read.3
>> file path=usr/share/man/man3/zzip_realdir.3
>> file path=usr/share/man/man3/zzip_realfd.3
>> file path=usr/share/man/man3/zzip_rewinddir.3
>> file path=usr/share/man/man3/zzip_seek.3
>> file path=usr/share/man/man3/zzip_seek32.3
>> file path=usr/share/man/man3/zzip_seekdir.3
>> file path=usr/share/man/man3/zzip_seekdir32.3
>> file path=usr/share/man/man3/zzip_seterror.3
>> file path=usr/share/man/man3/zzip_strerror.3
>> file path=usr/share/man/man3/zzip_strerror_of.3
>> file path=usr/share/man/man3/zzip_tell.3
>> file path=usr/share/man/man3/zzip_tell32.3
>> file path=usr/share/man/man3/zzip_telldir.3
>> file path=usr/share/man/man3/zzip_telldir32.3
> 
> 
> At least some of the missing man pages actually cannot be shown on my
> system with the zziplib package installed, eg.
> man zzip_dir_alloc
> mandoc: zzip_dir_alloc_ext_io.3: ERROR: No such file or directory
> () 
> ()
> 
> See the file zzip_dir_alloc_ext_io.3.
> 
>     August 2,
> 2018  ()
> 
> 
> 
> 
> I am not sure how to proceed here. Is it a problem on my build env or do
> others have the same problems?
> 
> Regards,
> Andreas
> 

I was able to build the component recently.

Are all build requirements present in the environment? Specifically text/xmlto. 
I configure script able to detect it properly?

Are those man pages generated or just not installed in the proto area?

Michal

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

Re: [oi-dev] lightdm-gtk-greeter and exo-csource

[Michal Nowak]

Hi,

can it be the simplest (even if temporary and hackish) solution to 
prepare a patch outside OpenIndiana and just apply it in our build system?


I removed 'osd' style from glade and regenerated 
lightdm-gtk-greeter-ui.h like this (as seen in Makefile.am) on Linux:


exo-csource --static --strip-comments --strip-content 
--name=lightdm_gtk_greeter_ui lightdm-gtk-greeter.glade > 
lightdm-gtk-greeter-ui.h


I applied the patch and published to my userland repo, installed to GZ 
and the only difference I see is that the top panel is now back to the 
old whitish color from transparent dark blue. But I use GTK 3.22.30, 
your mileage may vary.


See the patch attached. I am happy to prepare PR based on this, if we 
find this path viable.


lightdm-gtk-greeter-css-fallback.h and 
lightdm-gtk-greeter-css-application.h did not change during a similar 
regeneration.


Thanks,
Michal

On 06/26/18 05:35 PM, Пыхалов Александр Владимирович via oi-dev wrote:

Hi.

I've been fighting with lightdm-gtk-greeter as after last update it
looks ugly .

It seems in lightdm-gtk-greeter.glade "osd" style should be removed
and lightdm-gtk-greeter-2.0.5/src/lightdm-gtk-greeter-ui.h should be
regenerated. To regenerate it, I need exo-csource, which is a part of
https://github.com/xfce-mirror/exo, which has several XFCE
dependencies.

I see several options: - create components for all XFCE dependencies
and exo (a lot of mostly useless work); - create component just for
exo-csource  (this can be just a really small component, and it can
even be renamed if we want to avoid conflict with full exo library); 
- compile it manually and create patches to generated files.


So far I think about second approach as it is not extremely rude, but
allows to minimise time spent on it. What do you think?

Best regards, Alexander Pyhalov, system administrator of Southern
Federal University IT department

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


--- lightdm-gtk-greeter-2.0.5/src/lightdm-gtk-greeter-ui.h	2018-03-18 21:18:27.0 +
+++ lightdm-gtk-greeter-2.0.5/src/lightdm-gtk-greeter-ui.h	2018-06-26 20:49:28.080429611 +
@@ -100,196 +100,196 @@ static const char lightdm_gtk_greeter_ui
   "ost_menuitem\">host_menuitemFalse6power_window"
-  "False"
-  "centercenterTrueFalse<"
-  "property name=\"orientation\">verticalconten"
-  "t_frameTrueFalseTrueFalse2424242466TrueFalse61266gtk-missi"
-  "ng-image002TrueFalsestart6True[title]power_windowFalsecentercenterTrueFalseverticalcontent_frame<"
+  "property name=\"visible\">TrueF"
+  "alseTrueFalse2424242466True"
+  "False61266gtk-missing-image"
+  "002<"
+  "/packing><"
+  "property name=\"visible\">TrueF"
+  "alsestart6True[title]10TrueFalsestartTrue[text]11FalseTrue0<"
+  "/packing>buttonbox_frameTrueFalseTrueFalse24242424"
+  "6endCancelcancel"
+  "_buttonTrueTrueFa"
+  "lseFalseTrue0OK<"
+  "/property>power_ok_buttonTrueTrueFalse"
+  "FalseTrue1Fals"
+  "eTrue1screen<"
+  "/property>FalseTrueTrueTrueFalseF"
+  "alse"
+  ""
+  "login_windowTrueFalsesta"
+  "rtstartlogin_boxTrueFalseverticalcontent_frameTrueFalse0noneT"
+  "rueFalse242424618user_image_borderTrueFalsecentercenter0noneuser_imageTr"
+  "ueFalse80avatar-defau"
+  "lt003user_combobox"
+  "200Falsecenter12Trueuser_liststore1210TrueFalsestart"
-  "True[text]11FalseTrue0buttonbox_frame0prompt_entryTrueTrue\342\200\242Enter you"
+  "r username11prompt_entry200TrueTrue12TrueFalse\342\200\242Fal"
+  "seFalseEnter your"
+  " password12TrueTrue0<"
+  "property name=\"name\">greeter_infobarFalseFalseendF"
+  "alseFalse-1FalseTrueFalse[message]"
+  "TrueTrue0FalseTrue-1FalseT"
+  "rue1buttonbox_frameTrueFalse0noneTrueFalse242424Cancelcancel_buttonTrueFalseTrueFalse242424246endCancelcancel_buttonTrueTrueFalseFalseTrue0Log Inlogin_buttonTrueTrueFalseFalseTrue0OKpower_ok_buttonTrueTrueFalseFalseTrue1FalseTrue1<"
-  "style>screenFalseTrueTrue"
-  "TrueFalseFalselogin_windowTrue"
-  "Falsestartstart"
-  "login_boxTrueFalsevert"
-  "ical<"
-  "property name=\"name\">content_frameTrueFalse0none"
-  "TrueFalse242424618"
-  "<"
-  "property name=\"name\">user_image_borderTrueFalsecentercenter"
-  "0noneuser_imageTrueFalse<"
-  "property name=\"pixel_size\">80"
-  "avatar-default003u"
-  "ser_combobox200<"
-  "property name=\"can_focus\">Falsec"
-  "enter12Trueuser_liststore1210prompt"
-  "_entryTrueTrue\342\200"
-  "\242Enter your username11prompt_entry200Tr"
-  "ueTrue12TrueFalse\342\200\242FalseF"
-  "alseEnter your password12TrueTrue0greeter_infobarFalseFalseendFalseFalse-1FalseTrueFalse[message]TrueTrue0FalseTrue-1FalseTrue1buttonbox_frameTrueFalse0noneTrueFalse242424Cancelcancel_b"
-  "uttonTrueTrueFals"
-  "eFalseTrue0Log Inlogin_buttonTr"
-  

Re: [oi-dev] [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020)

[Michal Nowak]

Debian Security Tracker says that Debian's v2.0.x is affected: 
https://security-tracker.debian.org/tracker/CVE-2018-12020. Most likely 
ours is as well. There are two ways forward. Bumping our GnuPG to 2.2.8, 
or rebase our current stream to Debian jessie v2.0.26-6+deb8u2.


Michal

On 06/09/18 08:56 PM, Andreas Wacknitz wrote:

Hi all,

I just saw that GnuPG announced the new version 2.2.8
(https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/000425.html).
I am not sure whether our GnuPG 2.0.30 is effected by this vulnerability.
According to https://www.gnupg.org/download 2.0.x is eol'd 31.12.2017.
So, do we need a new GnuPG?

Regards,
Andreas


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



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

Re: [oi-dev] KPTI testing images and repository archive uploaded

[Michal Nowak]

  
  
On 03/05/2018 02:32 PM, Aurélien Larcher wrote:

  

  On Mon, Mar 5, 2018 at 8:25 AM,
Michal Nowak <mno...@startmail.com>
wrote:

   On
  03/03/2018 09:13 PM, Aurélien Larcher wrote:
  

  

  

  
Hi,

I set up this directory with testing
resources:

http://dlc-int.openindiana.org/users/aurelien/kpti/

  
  Live Media, Minimal Text images, and
  repository as p5p archive are provided.
  

The repository is located at:

pkg.openindiana.org/kpti

  
  Let me know if you encounter any issue.
  

Kind regards

  
  Aurélien
  

  

  

  


  

  

  

  

  

Hi,
over the weekend I tested KPTI from the repository on
  Toshiba Satellite L855 laptop (Ivy Bridge-based, has
  PCID). I run many tests from Phoronix Test Suite 7.8
  there and haven't seen any crash nor any other problem
  (apart from the fact that some tests are not in a good
  shape for OpenIndiana...). With regards to general use
  of the system, I haven't seen any noticeable slowdown.
  

Same experience here :)
  

I'd be interested in putting PTS to a better shape. Do
  you have any inital recipe that I could use for creating a
  component?

  

  

Unfortunately I don't... I used source tarball from the project's
website and manually installed required dependencies.

  

  
One "old" issue is that PTS runs 32-bit binaries by
  default for some tests since it expects /usr/bin to
  deliver 64-bit executables.

  

  

I see, that would explain why some tests from the test suite were
unable to find some binaries (e.g. mpich).

  

  

  
I also run the KPTI images thru our openQA tests
  and there's no problem, nor slowdown (I can say this
  from comparison with older runs) as well. Host for the
  tests was the Ivy Bridge-based laptop.
So far great experience. Thanks for putting those
  images and repos together Aurélien.
  

:)
  

Thanks to you for the openQA testing of the images, it
  is quite impressive :)

 

  
Michal

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

  
  
  
  
  -- 
  

  
---
Praise the Caffeine embeddings
  
  

  

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


  


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

Re: [oi-dev] KPTI testing images and repository archive uploaded

[Michal Nowak]

  
  
On 03/03/2018 09:13 PM, Aurélien Larcher wrote:

  

  

  

  Hi,
  
  I set up this directory with testing resources:
  
  http://dlc-int.openindiana.org/users/aurelien/kpti/
  

Live Media, Minimal Text images, and repository as p5p
archive are provided.

  
  The repository is located at:
  
  pkg.openindiana.org/kpti
  

Let me know if you encounter any issue.

  
  Kind regards
  

Aurélien

  

  

  

  
  

  

  

  

  

Hi,
over the weekend I tested KPTI from the repository on Toshiba
  Satellite L855 laptop (Ivy Bridge-based, has PCID). I run many
  tests from Phoronix Test Suite 7.8 there and haven't seen any
  crash nor any other problem (apart from the fact that some tests
  are not in a good shape for OpenIndiana...). With regards to
  general use of the system, I haven't seen any noticeable slowdown.
I also run the KPTI images thru our openQA
tests and there's no problem, nor slowdown (I can say this
  from comparison with older runs) as well. Host for the tests was
  the Ivy Bridge-based laptop.
So far great experience. Thanks for putting those images and
  repos together Aurélien.
Michal

  


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

Re: [oi-dev] [CFT] gcc 6.4.0-built repository available

[Michal Nowak]

  
  
On 02/07/2018 09:10 PM, Aurélien Larcher wrote:

  

  

  Hi everyone,
  
  we are happy to announce that a repository containing all
  the oi-userland packages built with gcc 6.4.0 is now
  available for testing.
  

The repository is located at:

http://pkg.openindiana.org/gcc-6/

  
  It is synchronized with the latest oi-userland bits and
  contains some minor updates.

While these packages have been tested for a few weeks now,
  be aware that the repository should be used for evaluation
  only (not in production).
  

Note that illumos-gate is still built with illumos-gcc
  4.4.4.



To test this repository, we recommend that you create a new
  Boot Environment (BE) and update manually this newly created
  BE.
  

Assume the right credentials using sudo, or pfexec if you
  have Software Installation profile: you need to add sudo or
  pfexec before each of the following command lines.
  

$ beadm create 20180207-gcc6
  

with '20180207-gcc6' an arbitrary BE name.
  

$ beadm mount 20180207-gcc6
  Mounted successfully on: '/tmp/tmp.7mayXC'
  

with '/tmp/tmp.7mayXC' the mountpoint of the new BE.
  

Add the gcc-6 repository to the list of publishers and set
  as preferred:


  $ pkg -R /tmp/tmp.7mayXC set-publisher -P -O http://pkg.openindiana.org/gcc-6/
  userland
  
  $ pkg -R /tmp/tmp.7mayXC set-publisher --non-sticky --disable
  openindiana.org
  
  $ pkg -R /tmp/tmp.7mayXC publisher 
  PUBLISHER   TYPE STATUS P LOCATION
  userland    origin   online F http://pkg.openindiana.org/gcc-6/
  openindiana.org
  (non-sticky, disabled) origin   online F http://pkg.openindiana.org/hipster/
  

Finally you can update the new BE:
  
  $ pkg -R /tmp/tmp.7mayXC update -v
  

Be aware that the update can make up to 3GB of data.
  

The created BE can be chosen manually at the next reboot,
  or activated using:
  
  $ beadm activate 20180207-gcc6



Please report any package dependency issue that may arise.
  

Happy testing!
  

Aurélien

  

Hi everyone and thanks Aurélien, Alp et al. for making this happen!

I added support for additional repository to our openQA tests
and updated several images which had default installation of Live,
Server, and Minimal variants from last three releases. Although I
haven't found any dependency issues, four of the seven updates
failed shortly after reboot to the new BE (which got created
automatically as part of the update process).

Live and Server variants
of 20161030 release failed with: "Unexpected trap. Unexpected trap.
Nested trap." (See the red-framed screen in each job run for the
error message; other screens and video in "Logs & Assets" might
be helpful too.)

Live and Server variants
of 20170502 release failed with:

krtld: error during initial load/link phase
krtld could neither locate nor resolve symbols for:
    /platform/i86pc/kernel/amd64/unix
in the boot archive. Please verify that this file
matches what is found in the boot archive.
You may need to boot using the Solaris failsafe to fix this.

All variants of the 20171031 release passes just fine: Live, Server, Minimal.

You can reproduce it by downloading the QCOW2 image from "Logs &
Assets" of a respective job and starting it on Linux KVM (I use QEMU
2.11.0) via:

    qemu-img create -f qcow2 OI-20170502-Server.qcow2 -b
openindiana-hipster-x86_64-20170502-Server@64bit.qcow2

    /usr/bin/qemu-system-x86_64 -soundhw ac97 -vga cirrus -global
isa-fdc.driveA= -m 3072 -cpu qemu64,+xsave -netdev user,id=qanet0
-device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -device
virtio-blk,drive=hd1,serial=1 -drive
file=OI-20170502-Server.qcow2,cache=unsafe,if=none,id=hd1,format=qcow2
-boot order=c -device usb-ehci -device usb-tablet -smp 1 -enable-kvm

OS credentials:
    User: robot
    User password: nots3cr3t (root via sudo is password-less)

Michal
  


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

Re: [oi-dev] Building install medium with custom illumos

[Michal Nowak]

On 12/08/2017 01:31 PM, Alexander Pyhalov wrote:

On 12/08/17 02:38 PM, Michal Nowak wrote:

Hello.

How do I create OpenIndiana install medium with custom illumos packages?

I built illumos with two Xen patches sent to illumos devel ml for a 
review and

pointed pkd.depot to the built packages (/usr/lib/pkg.depotd -d
/ws/illumos-gate/packages/i386/nightly/repo.redist -p 1).

These are the changes I did in slim_minimal_X86.xml
<https://paste.ec/paste/WtFORIAh#byqTjNqCf0fQsNYqLpj1gBflN+dXukDbuP+E9+gPuAa>: 




  http://localhost:1/;
  authname="on-nightly"/>


and


  
  name="pkg://on-nightly/consolidation/osnet/osnet-incorporation"/>

  
  
  




Hello.
You'll have (at least) 2 problems.
1) The one you have is easy to solve. Your repository should be first 
in repository list (in  pkg_repo_default_authority section).
2) The second one is that we replace some packages from 
osnet-incorporation (and from repository) - see
https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/openindiana/illumos-gate/packages.ignore 

and 
https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/openindiana/illumos-gate/Makefile#L155 
. You'd like to remove, for example, ssh packages, delivered by 
illumos-gate.


Perhaps, it's easier to use oi-userland reciept to build illumos-gate, 
so that you'll have all OI customizations applied to illumos-gate 
packages and do use oi-userland repository as pkg_repo_default_authority.




Thank you Till and Alp, with your kind help I was able to build those 
images.


With the userland illumos-gate component it was really easy to build the 
patched illumos and incorporate it to install images. The only other 
thing I had to do was to move userland to pkg_repo_default_authority and 
openindiana.org to pkg_repo_addl_authority, as Alp suggested.


Michal


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

[oi-dev] Building install medium with custom illumos

[Michal Nowak]

  
  
Hello.
How do I create OpenIndiana install medium with custom illumos
  packages?
I built illumos with two Xen patches sent to illumos devel ml for
  a review and pointed pkd.depot to the built packages (/usr/lib/pkg.depotd
-d /ws/illumos-gate/packages/i386/nightly/repo.redist -p 1).
These are the changes I did in slim_minimal_X86.xml:

      
"http://localhost:1/"
          authname="on-nightly"/>
  

and

      
      
      
      
      
  
I can see some interaction with pkg.depot:
127.0.0.1 - - [08/Dec/2017:12:00:42] "GET /versions/0/ HTTP/1.1"
  200 177 "" "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518;
  full; pkg)"
  127.0.0.1 - - [08/Dec/2017:12:00:42] "GET
  /on-nightly/catalog/1/catalog.attrs HTTP/1.1" 200 732 ""
  "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
  127.0.0.1 - - [08/Dec/2017:12:00:42] "GET
  /on-nightly/catalog/1/catalog.summary.C HTTP/1.1" 200 193511 ""
  "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
  127.0.0.1 - - [08/Dec/2017:12:00:42] "GET
  /on-nightly/catalog/1/catalog.dependency.C HTTP/1.1" 200 258218 ""
  "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
  127.0.0.1 - - [08/Dec/2017:12:00:42] "GET
  /on-nightly/catalog/1/catalog.base.C HTTP/1.1" 200 70279 ""
  "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
  127.0.0.1 - - [08/Dec/2017:12:00:49] "GET /versions/0/ HTTP/1.1"
  200 177 "" "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518;
  full; pkg)"
  127.0.0.1 - - [08/Dec/2017:12:00:49] "GET
  /on-nightly/catalog/1/catalog.attrs HTTP/1.1" 200 732 ""
  "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
But the build process eventually fails (full
log) with:
...
  pkg install: No matching version of minimal_install can
be installed:
    Reject: 
pkg://openindiana.org/minimal_install@0.1-2017.0.0.17
    Reason:  No version matching 'require' dependency
SUNWcs can be installed
      
      Reject:  pkg://on-nightly/SUNWcs@0.5.11-2017.3.0.0
  pkg install: No matching version of minimal_install can
be installed:
    Reject: 
pkg://openindiana.org/minimal_install@0.1-2017.0.0.17
    Reason:  No version matching 'require' dependency
SUNWcs can be installed
      
      Reject:  pkg://on-nightly/SUNWcs@0.5.11-2017.3.0.0
    Reason:  Higher ranked publisher
  openindiana.org was selected
    Reject: 
  pkg://openindiana.org/SUNWcs@0.5.11-2017.0.0.16768
   to

  pkg://openindiana.org/SUNWcs@0.5.11-2017.0.0.16893
    Reason:  Excluded by proposed incorporation
  'consolidation/osnet/osnet-incorporation'
      
      Reason:  Higher ranked publisher openindiana.org was
selected
      Reject: 
pkg://openindiana.org/SUNWcs@0.5.11-2017.0.0.16768
     to
  
pkg://openindiana.org/SUNWcs@0.5.11-2017.0.0.16893
      Reason:  Excluded by proposed incorporation
'consolidation/osnet/osnet-incorporation'
      
    Reject: 
pkg://openindiana.org/minimal_install@0.1-2017.0.0.18
   to
    
pkg://openindiana.org/minimal_install@0.1-2017.0.0.22
    Reason:  No version matching 'require' dependency
SUNWcs can be installed
  ...
Thanks,
  Michal

  


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

Re: [oi-dev] Automated test suite for OpenIndiana

[Michal Nowak]

We discussed the topics with Adam over IRC so just a short summary:

Ad (1): It should be doable, first I need to understand how Vagrant does 
stuff, will have a look at oi-packer.


Ad (2):

The dashboard, scheduler, and DB parts of openQA can run in a VM 
instance (and they do now), however worker (the part where the 
system-under-test aka VM actually runs) needs hypervizor to spawn VMs.


My laptop is the current KVM, VirtualBox, and Xen host. First two 
hypervizors can be switched on-the-fly, Xen environment is accessible 
only via reboot.


For jobs which require KVM the hypervizor host is openQA worker as well. 
For jobs which require VirtualBox or Xen hypervizor, the openQA worker 
and the hypervizor host may be different systems which can talk to one 
another via HTTP and SSH, but for HW reasons they are united in the 
current setup.


openQA has a good CLI which leverages REST-like API: e.g. 
https://openqa.oi.mnowak.cz/xyz.


Michal

On 11/25/2017 10:16 AM, Adam Števko wrote:

Hello,

nice job!

Few questions:

1) Would you be able to incorporate vagrant box testing? 2) We could
try and get an instance for running this. Can this run inside the VM
reliably? I see KVM/Xen/VirtualBox host. Can you confirm these are
not your laptop, but dedicated hosts?

With this there is also a much more incentive to automate the
creation of images as tests can run. Is there a good CLI client/API
for managing openqa instance?

Cheers Adam


On Nov 24, 2017, at 9:28 PM, Michal Nowak <mno...@startmail.com>
wrote:

Hello,

last couple of months I have been working on automated test suite
for OpenIndiana. You can find it's dashboard at

https://openqa.oi.mnowak.cz

It makes use of openQA (http://open.qa/), an open source automated
test tool that makes possible to test the whole installation
process of operating system, OS configuration, regression and
sanity testing of individual components. openQA is currently used
by Fedora (https://openqa.fedoraproject.org/) and openSUSE
(https://openqa.opensuse.org/) for package updates and snapshot
release testing, respectively.

Test suite sources and guidance on how to setup your local openQA
instance are on GitHub

https://github.com/Mno-hime/os-autoinst-distri-openindiana/

Currently Live, Text, and Minimal variants of both ISO and USB
images are tested as VM guests on KVM, VirtualBox, and Xen.

Some of the test scenarios implemented:

* General installation via text- as well as GUI-installer to disk,
reboot to the installed system, OS setup, shutdown. -
installation_mate@64bit: https://openqa.oi.mnowak.cz/tests/1820 (on
KVM host) - installation_textmode_raidz@64bit:
https://openqa.oi.mnowak.cz/tests/1841 (on KVM host) -
installation_textmode_mbr@vbox64_ide_piix3:
https://openqa.oi.mnowak.cz/tests/1805 (on VirtualBox host) -
installation_mate@xen-hvm: https://openqa.oi.mnowak.cz/tests/1846
(on Xen host; note: illumos guest Xen drivers are in bad shape
atm)

* Upgrade scenarios for latest OpenIndiana snapshots to the latest
incorporation, e.g. upgrade_textmode_20161030:
https://openqa.oi.mnowak.cz/tests/1808

* illumos KVM virtualization test:
https://openqa.oi.mnowak.cz/tests/1796

* Extended `pkg` console tests:
https://openqa.oi.mnowak.cz/tests/1816

* Toolchain (pkg_src & oi-userland build) tests:
https://openqa.oi.mnowak.cz/tests/1815

* Build of OpenIndiana snapshot images from latest published
packages: https://openqa.oi.mnowak.cz/group_overview/2

* When things go wrong:
installation_textmode@vbox64_sas_LSILogicSAS:
https://openqa.oi.mnowak.cz/tests/1795

My test-host/worker - a 5 year old 4 core Ivy Bridge laptop with 12
GB of RAM, and SSD - is able to run 3 jobs in parallel reliably.
Full build validation takes about 8 hours. Bare metal server is
certainly desired.

I believe that this test suite could help us produce OpenIndiana
hipster snapshots more validated, with higher level of confidence
to particular updates, periodically run package's upstream
testsuite in real-life environment as opposed to a bare-bone build
environment, or release snapshots more often (if desired).

How to get involved: Deploy your local openQA instance in
accordance to the documentation at http://open.qa on a Linux host
(sic; I never deployed openQA on illumos as I don't have illumos
capable hardware), follow OpenIndiana-specific guide at
https://github.com/Mno-hime/os-autoinst-distri-openindiana/blob/master/README.md,
clone particular job from openqa.oi.mnowak.cz, see how your changes
affect the test run, and contribute the code back as a pull
request.

Similar test suite can be implemented for other illumos
distributions like OmniOS CE and SmartOS.

Feel free to contact me (mnowak_) on #illumos or #oi-dev.

Michal

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

[oi-dev] Automated test suite for OpenIndiana

[Michal Nowak]

Hello,

last couple of months I have been working on automated test suite for 
OpenIndiana. You can find it's dashboard at


  https://openqa.oi.mnowak.cz

It makes use of openQA (http://open.qa/), an open source automated test 
tool that makes possible to test the whole installation process of 
operating system, OS configuration, regression and sanity testing of 
individual components. openQA is currently used by Fedora 
(https://openqa.fedoraproject.org/) and openSUSE 
(https://openqa.opensuse.org/) for package updates and snapshot release 
testing, respectively.


Test suite sources and guidance on how to setup your local openQA 
instance are on GitHub


  https://github.com/Mno-hime/os-autoinst-distri-openindiana/

Currently Live, Text, and Minimal variants of both ISO and USB images 
are tested as VM guests on KVM, VirtualBox, and Xen.


Some of the test scenarios implemented:

* General installation via text- as well as GUI-installer to disk, 
reboot to the installed system, OS setup, shutdown.
  - installation_mate@64bit: https://openqa.oi.mnowak.cz/tests/1820 (on 
KVM host)
  - installation_textmode_raidz@64bit: 
https://openqa.oi.mnowak.cz/tests/1841 (on KVM host)
  - installation_textmode_mbr@vbox64_ide_piix3: 
https://openqa.oi.mnowak.cz/tests/1805 (on VirtualBox host)
  - installation_mate@xen-hvm: https://openqa.oi.mnowak.cz/tests/1846 
(on Xen host; note: illumos guest Xen drivers are in bad shape atm)


* Upgrade scenarios for latest OpenIndiana snapshots to the latest 
incorporation, e.g. upgrade_textmode_20161030: 
https://openqa.oi.mnowak.cz/tests/1808


* illumos KVM virtualization test: https://openqa.oi.mnowak.cz/tests/1796

* Extended `pkg` console tests: https://openqa.oi.mnowak.cz/tests/1816

* Toolchain (pkg_src & oi-userland build) tests: 
https://openqa.oi.mnowak.cz/tests/1815


* Build of OpenIndiana snapshot images from latest published packages: 
https://openqa.oi.mnowak.cz/group_overview/2


* When things go wrong: installation_textmode@vbox64_sas_LSILogicSAS: 
https://openqa.oi.mnowak.cz/tests/1795


My test-host/worker - a 5 year old 4 core Ivy Bridge laptop with 12 GB 
of RAM, and SSD - is able to run 3 jobs in parallel reliably. Full build 
validation takes about 8 hours. Bare metal server is certainly desired.


I believe that this test suite could help us produce OpenIndiana hipster 
snapshots more validated, with higher level of confidence to particular 
updates, periodically run package's upstream testsuite in real-life 
environment as opposed to a bare-bone build environment, or release 
snapshots more often (if desired).


How to get involved: Deploy your local openQA instance in accordance to 
the documentation at http://open.qa on a Linux host (sic; I never 
deployed openQA on illumos as I don't have illumos capable hardware), 
follow OpenIndiana-specific guide at 
https://github.com/Mno-hime/os-autoinst-distri-openindiana/blob/master/README.md, 
clone particular job from openqa.oi.mnowak.cz, see how your changes 
affect the test run, and contribute the code back as a pull request.


Similar test suite can be implemented for other illumos distributions 
like OmniOS CE and SmartOS.


Feel free to contact me (mnowak_) on #illumos or #oi-dev.

Michal

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

[oi-dev] How to build minimal install DVD?

[Michal Nowak]

Hi -

how do I build "minimal install DVD"?

I have a distribution constructor prescripts for text and live install, but I 
could not find similar XML prescript for the minimal variant anywhere. Does 
anyone have it?

Thank you,
Michal

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