Re: [oi-dev] How many CPUs does OI support?

[ken mays via oi-dev]

 Hello,
Technically, there are only soft limits. I remember something like 256 cores x 
14-16 threads/core for OI x64-based systems. SPARC was around 512 cores.Higher 
thread count was around 4096 threads. 

A true beast...
~K


On Thursday, January 7, 2021, 11:53:11 PM PST, Chris  
wrote:  
 
 I'm looking to help building packages. Both current, as
well as newer versions. I have a large server farm. But
primarily BSD based. As such I'm looking into a new build
box, based on an Opteron or Xeon. So before I take the
plunge. I was hoping to add as many CPU/cores as possible.
Which begs the question: haw many CPUs does OI support?

Thank you for all your time, and consideration.

--Chris

-- 
~40yrs of UNIX and counting

___
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 gcc-next test images

[ken mays via oi-dev]

 The new Live ISO image seems good. Only two things off the brim:
1. Firefox 60.9.0ESR not loading remote web pages? Loads and works fine locally 
otherwise.
2. Mate core apps not updated to 1.24 (still 1.22.x).
Good luck,Ken

   On Monday, March 23, 2020, 1:15:01 PM PDT, Aurélien Larcher 
 wrote:  
 
 Uploading right now:
http://dlc-int.openindiana.org/users/aurelien/20200323/
Minimal images are already there and Live images being transferred (~20min to 
go).

It seems gpg-agent is broken so I could not sign the images.

-- 
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
  ___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

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

[ken mays via oi-dev]

 
Jeremy,
Nice backstory.
Any interest in working and reviewing a Firefox 68.3.0esr port to OI?
The trials and tribulations of porting
~K
On Tuesday, December 10, 2019, 10:39:15 PM PST, 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.



___
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] Where should SPARC go?

[ken mays via oi-dev]

Gary,
1. Testing a newer compile of the current illumos-gate snapshot seems 
reasonable to ensure everything still works with your SPARC-related changes.
 Ref: 
https://github.com/illumos/illumos-gate/commit/f52943a93040563107b95bccb9db87d9971ef47d
I'll review your SPARC-related tickets, if you have any porting issues with 
recent oi-userland on SPARC - did you provide a list as well?

~ Ken


On Tuesday, November 26, 2019, 6:47:33 AM PST, Gary Mills 
 wrote:  
 
 On Sun, Nov 24, 2019 at 08:40:58PM +, Peter Tribble wrote:
>    On Fri, Nov 22, 2019 at 8:43 PM Gary Mills <[1]gary_mi...@fastmail.fm>
>    wrote:
> 
>      I have no doubt that SPARC owners are in the minority.�  My estimate
>      is
>      about 12 users and 6 developers.
> 
>    That's probably slightly low in terms of users. There are currently
>    about 6 active
>    users of Tribblix for SPARC (other than myself). (For reference, there
>    are 50-100
>    active users of Tribblix on x86.) I suspect the number would increase
>    if illumos on
>    SPARC were more mature.

That's probably true.  It's still a small minority, of course.

>      That's partly because illumos already has SPARC support built in:
>      Peter only fixes things in illumos that are broken.�
> 
>    It's not as if there's any hardware development going on that affects
>    the
>    supported SPARC platforms. (Yes, it would be nice to support more
>    current
>    hardware, but what we have is a static target.) Much of the cleanup
>    work that
>    I'm (very very slowly) doing is to try and reduce the blast radius of
>    changes
>    from x86.

Yes, I agree with that policy.  Ordinary people have to buy SPARC
machines on the used market.  The largest SPARC machines are too
expensive.  The oldest ones are too slow to be useful.  It's only the
mid-range that we need to support.  Even those are large, heavy, and
power-hungry.

>      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.
> 
>    I wouldn't have expected full independence. I would have thought you
>    want
>    your own fork of oi-userland, though, so you can make whatever local
>    changes
>    necessary.

There won't be any local changes.  At least, that is my intention.

>    One thing I'm finding is that the chance of something
>    building on
>    SPARC is going down over time, so I'm having to hold certain packages
>    on
>    SPARC at older revisions.

So far, I haven't run into that problem with OI.  My intention is to
build OI packages without any changes.  Most of the time, this plan is
successful.


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

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

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

[ken mays via oi-dev]

 Hi Gary,
Well, good answers abound!
As you've put much effort into keeping SPARC machines alive through the 
OpenIndiana project, let us reviewa long arm supportable approach to this issue:
1. Maintain your bug reports through OI bug tracker.and tag new/old 
SPARC-related issues with 'sparc'. I see five tickets here:
Issues - OpenIndiana Distribution - illumos

| 
| 
|  | 
Issues - OpenIndiana Distribution - illumos

Redmine
 |

 |

 |



2. Define the SPARC machines you are supporting through the distro project.
Noted here that past supporters have T1000 through T5440 servers as well as a 
few Blade or Ultra 25/45 workstations that were beinghosted as build repos. 
Will you continually support the SPARC workstations as well as modern 
UltraSPARC T1/T2 servers?

3. Packages built on your distro working elsewhere (i.e. DilOS, Tribblix, 
OpenSXCE, S11.x SPARC) and/or pre-existing SPARC packagesworking on your distro.

Just a start
~ Ken

On Sunday, November 17, 2019, 2:37:16 PM PST, 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.

First of all, how much interest do you have in OI on SPARC?  My
interest is as a developer and tester.  What is your interest?
I'd like to determine the size of the audience.

How should I contribute to OI on SPARC?  I have plans to build more
packages, and to do so with fewer changes to the OI source.  I also
have plans to update the distribution from the current 2018 to 2019 or
2020.  Does this sound reasonable to you?

How should you contribute to OI on SPARC?  I've filed bug reports
for many of the changes I've made.  They can be seen at:

    https://www.illumos.org/projects/openindiana/issues

I've attached patches to each bug report, but in order for these
patches to be integrated into the OI source, the patches need to be
turned into PRs for github.  They also need to be tested on x86 to
make sure they don't accidentally change anything there.  Can you help
with any of this?  Can you build packages for SPARC from OI source?
Can you help in any other way?

What type of repository do you prefer?  Should it be file-based, as it
is now, or should it be remote, as for OI x86?  The repository will
only get larger, as people build more packages and publish them.  Will
you download such a large file?  I don't know of any way to merge
repositories, so there must be only one.

Finally, who should coordinate OI on SPARC?  Should this be done by
the OI project, or should it be done separately?  Keep in mind that OI
SPARC uses OI source.  Most of it builds and publishes with no
changes.  When changes are necessary, my plan has been to introduce
them with no harm to x86 packages built from the same source.  Indeed,
some of the changes fix bugs in the corresponding x86 packages.  Also
keep in mind that IPS is designed to handle multiple architectures,
making it easy to integrate SPARC with x86.  In fact, this is already
done for illumos.


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

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

[oi-dev] Nvidia 440.x video driver support proposal

[ken mays via oi-dev]

Hi,
One of the goals discussed a few years ago was to support many of the legacy 
Nvidia cards within a 10-15 year coverage. 

I'm proposing the latest driver, Nvidia 440.31, as it works with recent Nvidia 
600-series through RTX graphic cards (also Quadro 400 through Quadro RTX 8000).
This video driver release provides nine years of recent graphics 
hardware-acceleration coverage for OI.
~ Ken Mays


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

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

[ken mays via oi-dev]

 Hello,
Remove these:

driver/network/celibrary/desktop/gtk1
library/glib1
library/medialib
~K


On Wednesday, October 24, 2018, 5:39:25 AM PDT, Aurélien Larcher 
 wrote:  
 
 Hi,
this list contains packages installed on my system that cannot be published 
from oi-userland:

compatibility/packages/SUNWxwinc
compatibility/packages/SUNWxwplt
consolidation/cde/cde-incorporation
consolidation/dbtg/dbtg-incorporation
consolidation/jdmk/jdmk-incorporation
consolidation/man/man-incorporation
developer/macro/cpp
driver/network/ce
library/desktop/gtk1
library/glib1
library/medialib
library/motif
system/font/truetype/arphic-uming
system/font/truetype/hanyang-ko-core
system/font/truetype/ipafont
system/font/truetype/lohit
system/font/xorg/iso8859-1
system/font/xorg/xorg-core
system/input-method/library/libanthy
system/input-method/library/libchewing
system/input-method/library/libhangul
system/install/locale
system/library/c++/sunpro
system/library/iconv/extra
system/library/iconv/unicode
system/library/iconv/utf-8
system/library/iconv/utf-8/manual
system/library/iconv/xsh4/latin
system/manual/locale/ca
system/manual/locale/ja
system/osnet/locale/fr
system/osnet/locale/ja
system/xvm/xvmstore
text/auto_ef
text/doctools/ja
x11/compatibility/links-svid
x11/library/dps
x11/library/libowconfig
x11/library/toolkit/libxaw4
x11/library/toolkit/libxaw5
x11/network/rstart

The question is: what can we deprecate?

As usual I can deal with x11/ and I know that iconv will be a pain...

Kind regards,

Aurélien

-- 
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev  ___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Help with 2018.10 release notes

[ken mays via oi-dev]

 Michael,
1. illumos refresh - any known MAJOR issues with current (>=2018/10/22)?
2. Spacing issue in page: "Pidgin was updated(_)to 2.13.0."3. Can decide to 
mention about Firefox ESR 60.0.2 exclusion. (NO time for deadline, etc...).
4. Any known installation issues and workarounds?5. Any known issues on AMD 
ThreadRipper/Ryzen installs?
~K

On Monday, October 22, 2018, 12:46:20 AM PDT, Michal Nowak 
 wrote:  
 
 Hi,

I drafted 2018.10 release notes at 
https://wiki.openindiana.org/oi/2018.10+Release+notes. Please join me in 
adding what you feel should be mentioned in the release notes of the 
upcoming 2018.10 snapshot.

Sofar I added entries of "XXX updated to version ###" nature. I 
obviously tend to add things I worked on, so don't be shy and add what 
you worked on during last 6 months.

Though, feel free to remove what you don't find significant enough, fix 
errors etc, merge entries.

I especially miss updates in following sections: Nodejs, X-stack, 
toolchain, illumos, oi-userland build.

This link shows what got merged since April 27 (2018.04 snapshot):

https://github.com/OpenIndiana/oi-userland/pulls?page=17&q=is%3Apr+merged%3A%3E%3D2018-04-27&utf8=%E2%9C%93

If you feel the release notes wiki page should be in "contributors-only 
mode", hidden for the public, please make it so (can't do it on my own).

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

Re: [oi-dev] 2018.10 targets

[ken mays via oi-dev]

 
- Virtualbox failure after FPU changes https://www.illumos.org/issues/9761 , 
https://www.virtualbox.org/ticket/17947 is a serious one,a. I reviewed it. Can 
work with their devs (as time permits).
- Nimbus theme GTK3
a. Nimbus conversion to GTK3 
- MATE 1.20a. Commit what works now. Update vte as time permits.

~K


   On Friday, September 28, 2018, 2:40:06 AM PDT, Aurélien Larcher 
 wrote:  
 
 

On Fri, Sep 28, 2018 at 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?

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? 

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


Hi Alexander,
I'll be busy as well and my skills are not up to tasks #1 or #2... the only 
tracks I can pursue for now are:
1) fixing pkg and gfx-drm components so that we can migrate userland to gcc-8 
before or after the snapshot.
2) pushing Firefox 60esr
3) updating Xorg to latest
4) fixing openmpi which has been broken before summer

If I have time to fix audacity then we can also update ffmpeg and vlc.
I had some fixes for drm/i915 but my Intel box died 4 months ago so this is on 
hold until I can replace it.
Kind regards,

Aurélien
 

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



-- 
---
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] MATE 1.18: updates for Sept 2018 refresh

[ken mays via oi-dev]

Hi,
Ref: https://github.com/OpenIndiana/oi-userland/pull/4433

I've submitted this PR for the latest updates to OI MATE 1.18.

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

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

[ken mays via oi-dev]

 @Gary,
DilOS mentioned: "SPARC: illumos build still with gcc 4,x because have to work 
on transitions of Sun AS -> GNU AS for sparc sources."

I just wrote about a move to either GCC 6.x/7.x moving forward, then I remember 
this from DilOSdarn
~K
On Sunday, May 20, 2018, 7:23:47 PM PDT, Gary Mills 
 wrote:  
 
 On Sat, May 19, 2018 at 09:10:26PM -0500, Norm Jacobs wrote:
>    It looks like
>    developer/gcc-7/patches/0008-sol2-enable-full-__cxa_atexit-support.patc
>    h may need work for SPARC, particularly in libgcc/config.host.  Without
>    looking too far into it, I would guess that changing the diffs for
>    libgcc/config.host in the patch to
[...]

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

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


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

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

[oi-dev] MATE 1.18 - March 2018 refresh

[ken mays via oi-dev]

Hello,
Ref: https://github.com/kenmays/oi-userland-20180315/commits/oi/hipster
I've updated a snapshot of oi-userland for the latest MATE 1.18 revisions as of 
2018-03-15.
Several packages were updated:pluma-1.18.3.tar.xz
engrampa-1.18.3.tar.xz
eom-1.18.3.tar.xz
libmateweather-1.18.2.tar.xz
marco-1.18.2.tar.xz
mate-applets-1.18.2.tar.xz
mate-calc-1.18.1.tar.xz
mate-indicator-applet-1.18.1.tar.xz
mate-menus-1.18.1.tar.xz
mate-notification-daemon-1.18.1.tar.xz
mate-panel-1.18.7.tar.xz
mate-settings-daemon-1.18.2.tar.xz
mate-themes-3.20.24.tar.xzmate-utils-1.18.3.tar.xz
We still plan to migrate to MATE 1.20 for the 2018.04 snapshot.- once we 
convert to gtk 3.22.
Enjoy,Ken
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] MATE 1.20 integration

[ken mays via oi-dev]

Hello,
Be aware of some changes:
1. GTK 3.22 or newer is required to build MATE Desktop 1.202. Atril epub 
capability still limited.3. Nimbus theme tweakages.4. Older GNOME2 apps being 
phased out for MATE equivalents or GNOME3 versions.5. wxwidgets 3.x migration

We will try to have things in place very soon..stay tuned...

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

[oi-dev] MATE 1.18 review & bug cleanup - Jan 2018

[ken mays via oi-dev]

Latest packages for port integration:
pluma-1.18.3.tar.xz
engrampa-1.18.3.tar.xz
eom-1.18.3.tar.xz
libmateweather-1.18.2.tar.xz
marco-1.18.2.tar.xz
mate-applets-1.18.2.tar.xz
mate-calc-1.18.1.tar.xz
mate-indicator-applet-1.18.1.tar.xz
mate-media-1.18.2.tar.xz
mate-menus-1.18.1.tar.xz
mate-notification-daemon-1.18.1.tar.xz
mate-panel-1.18.7.tar.xz
mate-settings-daemon-1.18.2.tar.xzmate-themes-3.20.23.tar.xz
mate-system-monitor-1.18.1.tar.xz
mate-sensors-applet-1.18.3.tar.xzmate-utils-1.18.3.tar.xz

Checked against:
http://pkg.openindiana.org/hipster/en/index.shtml
Last Updated 2018-01-25 14:11:17

Bugs verified as fixed in current IPS:

https://www.illumos.org/issues/7977
https://www.illumos.org/issues/8773

https://www.illumos.org/issues/8118

https://www.illumos.org/issues/8272


~ Ken






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

[oi-dev] Audacity 2.1.0 for OI

[ken mays via oi-dev]

Hi,
Info: https://wiki.openindiana.org/oi/Audacity
Binary link: 
https://wiki.openindiana.org/download/attachments/37061045/oi-audacity-2.1.0-32_kmays.tar.xz
You'll need to install wxwidgets and libsoxr on your workstations.
Note: 
1. pfexec pkg install library/graphics/wxwidgets
2. Compile libsoxr and install (if not included)
3. You can 'rip' audio CDs with Audacity - similar to Sound Juicer. 
~ K
  ___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] GCC6 build zone status

[ken mays via oi-dev]

 We'd want to keep them if we can't find either the GNOME3 version or better 
alternatives.1. seahorse-plugins is being replaced by seahorse-caja 
(seahorse-nautilus, GNOME3)

On Tuesday, November 14, 2017, 4:30:04 AM PST, Jim Klimov 
 wrote:  
 
 On November 13, 2017 10:42:07 PM GMT+01:00, "Aurélien Larcher" 
 wrote:
>On Mon, Nov 13, 2017 at 10:37 PM, ken mays 
>wrote:
>
>>
>> Are we not phasing out
>>
>> COMPONENT_DIRS += desktop/gnome2/gnome-connection-manager
>> COMPONENT_DIRS += desktop/gnome2/gnome-media
>> COMPONENT_DIRS += desktop/gnome2/hamster-applet
>> COMPONENT_DIRS += desktop/gnome2/seahorse-plugins
>>
>
>If somebody volunteers to deprecate stuff, I'll be glad, less work :)
>
>
>>
>> On Monday, November 13, 2017, 10:06:33 AM PST, Aurélien Larcher <
>> aurelien.larc...@gmail.com> wrote:
>>
>>
>> Hi,
>> for your information, the list of components left to publish with GCC
>> 6.4.0:
>>
>> COMPONENT_DIRS += database/geoip-database
>> COMPONENT_DIRS += desktop/gnome2/gnome-connection-manager
>> COMPONENT_DIRS += desktop/gnome2/gnome-media
>> COMPONENT_DIRS += desktop/gnome2/hamster-applet
>> COMPONENT_DIRS += desktop/gnome2/seahorse-plugins
>> COMPONENT_DIRS += desktop/hexchat
>> COMPONENT_DIRS += desktop/xscreensaver
>> COMPONENT_DIRS += library/libpeas
>> COMPONENT_DIRS += library/trousers
>> COMPONENT_DIRS += library/vte
>> COMPONENT_DIRS += network/asterisk
>> COMPONENT_DIRS += network/openssh
>> COMPONENT_DIRS += network/rtorrent
>> COMPONENT_DIRS += perl/DBI-MySQL
>> COMPONENT_DIRS += perl/DBI-PostgreSQL
>> COMPONENT_DIRS += print/hal-cups-utils
>> COMPONENT_DIRS += python/pylint
>> COMPONENT_DIRS += runtime/clisp
>> COMPONENT_DIRS += runtime/jruby
>> COMPONENT_DIRS += runtime/ocaml
>> COMPONENT_DIRS += runtime/openjdk-8
>> COMPONENT_DIRS += sysutils/clamav
>> COMPONENT_DIRS += sysutils/freeipmi
>> COMPONENT_DIRS += sysutils/ngrep
>> COMPONENT_DIRS += sysutils/nut
>> COMPONENT_DIRS += sysutils/open-vm-tools
>> COMPONENT_DIRS += text/hunspell-cs
>> COMPONENT_DIRS += text/hunspell-es
>> COMPONENT_DIRS += text/hunspell-fr
>> COMPONENT_DIRS += text/hunspell-pl
>> COMPONENT_DIRS += text/hunspell-sv
>> COMPONENT_DIRS += web/tomcat-8
>> COMPONENT_DIRS += x11/tigervnc
>>
>> and some comments updated on the Wiki at
>https://wiki.openindiana.org/
>> oi/GCC+6.
>> As oi-userland contains almost 1400 components, we are definitely
>closer
>> to the end than the beginning.
>>
>> If you have some time to look at one of these components, your help
>will
>> be much appreciated :)
>>
>> Kind regards
>>
>> Aurelien
>>
>>
>> --
>> ---
>> Praise the Caffeine embeddings
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
>>

As posted on IRC: note that "gnome-connection-manager" is a bit of misnomer, 
being a python script and not a GNOME team project.

For those that don't use it - this is a multi-tabbed xterm/ssh client with 
split-view, cluster-management and saved session (and session logging) support, 
similar to SecureCRT or MTPuTTY interfaces on Windows.

Indispensable in my work, and probably wouldn't miss GNOME2 if that's gone, 
either.

Jim
--
Typos courtesy of K-9 Mail on my Android  ___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] GCC6 build zone status

[ken mays via oi-dev]

We'd want to keep them if we can't find either the GNOME3 version or better 
alternatives.1. seahorse-plugins is being replaced by seahorse-nautilus (GNOME3)
 

On Tuesday, November 14, 2017, 4:30:04 AM PST, Jim Klimov 
 wrote:  
 
 On November 13, 2017 10:42:07 PM GMT+01:00, "Aurélien Larcher" 
 wrote:
>On Mon, Nov 13, 2017 at 10:37 PM, ken mays 
>wrote:
>
>>
>> Are we not phasing out
>>
>> COMPONENT_DIRS += desktop/gnome2/gnome-connection-manager
>> COMPONENT_DIRS += desktop/gnome2/gnome-media
>> COMPONENT_DIRS += desktop/gnome2/hamster-applet
>> COMPONENT_DIRS += desktop/gnome2/seahorse-plugins
>>
>
>If somebody volunteers to deprecate stuff, I'll be glad, less work :)
>
>
>>
>> On Monday, November 13, 2017, 10:06:33 AM PST, Aurélien Larcher <
>> aurelien.larc...@gmail.com> wrote:
>>
>>
>> Hi,
>> for your information, the list of components left to publish with GCC
>> 6.4.0:
>>
>> COMPONENT_DIRS += database/geoip-database
>> COMPONENT_DIRS += desktop/gnome2/gnome-connection-manager
>> COMPONENT_DIRS += desktop/gnome2/gnome-media
>> COMPONENT_DIRS += desktop/gnome2/hamster-applet
>> COMPONENT_DIRS += desktop/gnome2/seahorse-plugins
>> COMPONENT_DIRS += desktop/hexchat
>> COMPONENT_DIRS += desktop/xscreensaver
>> COMPONENT_DIRS += library/libpeas
>> COMPONENT_DIRS += library/trousers
>> COMPONENT_DIRS += library/vte
>> COMPONENT_DIRS += network/asterisk
>> COMPONENT_DIRS += network/openssh
>> COMPONENT_DIRS += network/rtorrent
>> COMPONENT_DIRS += perl/DBI-MySQL
>> COMPONENT_DIRS += perl/DBI-PostgreSQL
>> COMPONENT_DIRS += print/hal-cups-utils
>> COMPONENT_DIRS += python/pylint
>> COMPONENT_DIRS += runtime/clisp
>> COMPONENT_DIRS += runtime/jruby
>> COMPONENT_DIRS += runtime/ocaml
>> COMPONENT_DIRS += runtime/openjdk-8
>> COMPONENT_DIRS += sysutils/clamav
>> COMPONENT_DIRS += sysutils/freeipmi
>> COMPONENT_DIRS += sysutils/ngrep
>> COMPONENT_DIRS += sysutils/nut
>> COMPONENT_DIRS += sysutils/open-vm-tools
>> COMPONENT_DIRS += text/hunspell-cs
>> COMPONENT_DIRS += text/hunspell-es
>> COMPONENT_DIRS += text/hunspell-fr
>> COMPONENT_DIRS += text/hunspell-pl
>> COMPONENT_DIRS += text/hunspell-sv
>> COMPONENT_DIRS += web/tomcat-8
>> COMPONENT_DIRS += x11/tigervnc
>>
>> and some comments updated on the Wiki at
>https://wiki.openindiana.org/
>> oi/GCC+6.
>> As oi-userland contains almost 1400 components, we are definitely
>closer
>> to the end than the beginning.
>>
>> If you have some time to look at one of these components, your help
>will
>> be much appreciated :)
>>
>> Kind regards
>>
>> Aurelien
>>
>>
>> --
>> ---
>> Praise the Caffeine embeddings
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
>>

As posted on IRC: note that "gnome-connection-manager" is a bit of misnomer, 
being a python script and not a GNOME team project.

For those that don't use it - this is a multi-tabbed xterm/ssh client with 
split-view, cluster-management and saved session (and session logging) support, 
similar to SecureCRT or MTPuTTY interfaces on Windows.

Indispensable in my work, and probably wouldn't miss GNOME2 if that's gone, 
either.

Jim
--
Typos courtesy of K-9 Mail on my Android  ___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] GCC6 build zone status

[ken mays via oi-dev]

 
Are we not phasing out
COMPONENT_DIRS += desktop/gnome2/gnome-connection-manager
COMPONENT_DIRS += desktop/gnome2/gnome-media
COMPONENT_DIRS += desktop/gnome2/hamster-applet
COMPONENT_DIRS += desktop/gnome2/seahorse-plugins
On Monday, November 13, 2017, 10:06:33 AM PST, Aurélien Larcher 
 wrote:  
 
 Hi,
for your information, the list of components left to publish with GCC 6.4.0:

COMPONENT_DIRS += database/geoip-database
COMPONENT_DIRS += desktop/gnome2/gnome-connection-manager
COMPONENT_DIRS += desktop/gnome2/gnome-media
COMPONENT_DIRS += desktop/gnome2/hamster-applet
COMPONENT_DIRS += desktop/gnome2/seahorse-plugins
COMPONENT_DIRS += desktop/hexchat
COMPONENT_DIRS += desktop/xscreensaver
COMPONENT_DIRS += library/libpeas
COMPONENT_DIRS += library/trousers
COMPONENT_DIRS += library/vte
COMPONENT_DIRS += network/asterisk
COMPONENT_DIRS += network/openssh
COMPONENT_DIRS += network/rtorrent
COMPONENT_DIRS += perl/DBI-MySQL
COMPONENT_DIRS += perl/DBI-PostgreSQL
COMPONENT_DIRS += print/hal-cups-utils
COMPONENT_DIRS += python/pylint
COMPONENT_DIRS += runtime/clisp
COMPONENT_DIRS += runtime/jruby
COMPONENT_DIRS += runtime/ocaml
COMPONENT_DIRS += runtime/openjdk-8
COMPONENT_DIRS += sysutils/clamav
COMPONENT_DIRS += sysutils/freeipmi
COMPONENT_DIRS += sysutils/ngrep
COMPONENT_DIRS += sysutils/nut
COMPONENT_DIRS += sysutils/open-vm-tools
COMPONENT_DIRS += text/hunspell-cs
COMPONENT_DIRS += text/hunspell-es
COMPONENT_DIRS += text/hunspell-fr
COMPONENT_DIRS += text/hunspell-pl
COMPONENT_DIRS += text/hunspell-sv
COMPONENT_DIRS += web/tomcat-8
COMPONENT_DIRS += x11/tigervnc

and some comments updated on the Wiki at https://wiki.openindiana.org/oi/GCC+6.
As oi-userland contains almost 1400 components, we are definitely closer to the 
end than the beginning.

If you have some time to look at one of these components, your help will be 
much appreciated :)

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

Re: [oi-dev] ibus-setup autostart management

[ken mays via oi-dev]

Alex,

Yes, migrate it if < 1 days effort to drop legacy gate
for your improvements.

~K


On Thu, 10/26/17, Alexander Pyhalov  wrote:

 Subject: [oi-dev] ibus-setup autostart management
 To: "OpenIndiana Developer mailing list" 
 Date: Thursday, October 26, 2017, 11:20 AM
 
 Hi.
 
 Today imf-selector is used to choose
 default input method. I've ported 
 it to Python gobject/gtk3 in 
 https://github.com/OpenIndiana/oi-userland/pull/3612 .
 ibus-setup utility once upon a time had
 an ability to manage ibus 
 autostart. It was broken and now is
 disabled. I've created the following 
 patch - 
 
https://github.com/OpenIndiana/oi-userland/pull/3613/commits/e40411787674f7b9d00555d62c8dc643112aa1be
 
 to resurrect it. It generally works,
 but GUI interface is ugly. And it 
 still relies on startup script from
 imf-selector. In theory, we could 
 move this script to ibus, fix GTK
 builder ui file and this would allow 
 us to drop imf-selector (as it's from
 now-closed input-method gate, and 
 we'll likely have no updates from
 upstream, it has some advantages). The 
 question is if it worth the effort, or
 we can just drop iiim, but 
 continue shipping imf-selector.
 -- 
 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] Phoronix again

[ken mays via oi-dev]

You can use the Phoronix forums in relation to the article.Also, the OI wiki 
provides a way to report on our own 'test analysis' on compatible OI-related 
hardware.
Phoronix is just another independent test and review website. Anyone can report 
and test on what 'works for them' to 
challenge what is said there or anywhere else.
You can simulate in VMware or virtual clouds, so having esoteric and exotic 
physical hardware on hand/in-house is not a requirement.
~K
 

On Monday, July 31, 2017 11:45 AM, Aurélien Larcher 
 wrote:
 

 



It needs 3 things - hardware, engineer and time. AFAIK right now there are 2 
companies behind illumos who have more direct relations with hardware - Joyent 
and Nexenta and those companies are still most likely interested about the 
server class hardware.
Anything else is really about the community - if anyone has such hardware and 
is willing to help with diagnostics and testing, then we can do something, 
otherwise...

I do not know if we could better communicate how to report such issues ...
 

rgds,toomas
__ _
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/ mailman/listinfo/oi-dev




-- 
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

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

Re: [oi-dev] Phoronix again

[ken mays via oi-dev]

You are correct. There is a 'test text install ISO, based on illumos-4ac9cfc 
that works on legacy hardware like the previous snapshots versus the 2017.04 
release. Alex just fixed libusb and some other issues so we may want to wait 
till another test ISO snapshot is released.
Recent test boot images: 
http://buildzone.oi-build.r61.net/installer-zpool-install/2017-07-22/
~K





On Monday, July 31, 2017, 7:41:25 AM PDT, Aurélien Larcher 
 wrote:



On Mon, Jul 31, 2017 at 4:37 PM, ken mays  wrote:

Ref: 
https://wiki.openindiana.org/ oi/2017.04+Release+notes
https://wiki.openindiana.org/ oi/2016.10+Release+notes
The official name varies (i.e. 2017.04) from their directory naming:
http://dlc.openindiana.org/ isos/hipster/20170502/


These were the original images for 2017.04 published on 2017-05-02, or am I 
wrong?

 


~K



On Monday, July 31, 2017, 7:08:14 AM PDT, Aurélien Larcher 
 wrote:



On Mon, Jul 31, 2017 at 3:57 PM, ken mays via oi-dev  
wrote:

Actually...
There was a respin due on the 20170502 images to resolve a boot issue on 
specific hardware that worked with the 20161030 images.

Were these images announced? I do not remember them.
 

Newer dev snapshots resolve this boot issue. Haven't tried on the MSI X299 
motherboard, but know we lack some drivers to enable all of its hardware 
features.

~ K









On Monday, July 31, 2017, 3:42:01 AM PDT, Aurélien Larcher 
 wrote:

Hi,
again Michael Larabel attempted a review and could boot on his hardware:

http://phoronix.com/scan.php? page=news_item&px=OpenIndiana- 7900X-Hipster

Obviously, instead of contacting us, he wrote directly an article to state the 
fact.

Last time this happened I contacted him to find out what caused the problem but 
he never reached back. What can we do about it?

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




-- 
---
Praise the Caffeine embeddings




-- 
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Phoronix again

[ken mays via oi-dev]

Ref: 
https://wiki.openindiana.org/oi/2017.04+Release+notes
https://wiki.openindiana.org/oi/2016.10+Release+notes
The official name varies (i.e. 2017.04) from their directory naming:
http://dlc.openindiana.org/isos/hipster/20170502/

~K



On Monday, July 31, 2017, 7:08:14 AM PDT, Aurélien Larcher 
 wrote:



On Mon, Jul 31, 2017 at 3:57 PM, ken mays via oi-dev  
wrote:

Actually...
There was a respin due on the 20170502 images to resolve a boot issue on 
specific hardware that worked with the 20161030 images.

Were these images announced? I do not remember them.
 

Newer dev snapshots resolve this boot issue. Haven't tried on the MSI X299 
motherboard, but know we lack some drivers to enable all of its hardware 
features.

~ K









On Monday, July 31, 2017, 3:42:01 AM PDT, Aurélien Larcher 
 wrote:

Hi,
again Michael Larabel attempted a review and could boot on his hardware:

http://phoronix.com/scan.php? page=news_item&px=OpenIndiana- 7900X-Hipster

Obviously, instead of contacting us, he wrote directly an article to state the 
fact.

Last time this happened I contacted him to find out what caused the problem but 
he never reached back. What can we do about it?

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




-- 
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Phoronix again

[ken mays via oi-dev]

Actually...
There was a respin due on the 20170502 images to resolve a boot issue on 
specific hardware that worked with the 20161030 images.
Newer dev snapshots resolve this boot issue. Haven't tried on the MSI X299 
motherboard, but know we lack some drivers to enable all of its hardware 
features.

~ K









On Monday, July 31, 2017, 3:42:01 AM PDT, Aurélien Larcher 
 wrote:

Hi,
again Michael Larabel attempted a review and could boot on his hardware:

http://phoronix.com/scan.php?page=news_item&px=OpenIndiana-7900X-Hipster

Obviously, instead of contacting us, he wrote directly an article to state the 
fact.

Last time this happened I contacted him to find out what caused the problem but 
he never reached back. What can we do about it?

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

Re: [oi-dev] XFCE

[ken mays via oi-dev]

Most of the non-primary DEs and WMs live in SFE (or custom/personal repos).
Maintainers/distributors use their personal or preferred primary GUIs like 
IceWM, JVM, Xfce, Enlightenment, Cinnamon, KDE, GNOME and others.
As mentioned, we primarily support the MATE desktop for OI.

~ Ken

On Wednesday, May 10, 2017, 8:36:42 AM PDT, Peter Tribble 
 wrote:On Wed, May 10, 2017 at 4:07 PM, Aurélien 
Larcher  wrote:


À Mercredi 10 mai 2017, Dariusz Sendkowski a écrit :
> Hi,
>
> Has anybody ever tried to add XFCE desktop environment to oi-userland?
> Or maybe someone has been already working on it

We decided to add only in oi-userland what could be supported reliably to avoid 
packages becoming unmaintained.
Even Enlightenment turned out to be troublesome and was broken 6 months until I 
figured the issue.
Even if XFCE is a nice DE, we have already a lot of work coping with Xorg and 
MATE so I do not think we discussed it.
Our situation is different than Linux distributions since we need to patch 
Linux-specific code, it requires more effort. The take is usually to focus on 
integration of selected packages (example: Caja's ZFS snapshot browser has no 
equivalent in XFCE).
In short, adding another big DE  to oi-userland should come with the guarantee 
that someone will maintain it.
I use MATE and Enlightenment only, and I have no tried building XFCE.


To be fair, Xfce take portability pretty seriously, they realise that running
on non-Linux platforms is a good selling point and were more than happy
to accept my porting patches. It's run on Solaris/illumos for many years
and is the default DE on Tribblix.

You shouldn't need any patches to get it to build, I just put in a couple of
tweaks, nothing more.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - 
http://ptribble.blogspot.com/___
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] MATE 1.18 for OpenIndiana "Next"

[ken mays via oi-dev]

Hello,
MATE 1.18 package built for testing on OpenIndiana, so now we document and 
track the bugs.
http://mate-desktop.org/blog/2017-03-13-mate-1-18-released/
Mainly for the dev/test snapshots leading up to the next official snapshot:
Wiki page:https://wiki.openindiana.org/oi/MATE+1.18+Desktop
~ K


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

Re: [oi-dev] OI 2017-05 snapshot: AMD Athlon 64 (K8) compatibility issues

[ken mays via oi-dev]

Test with either USB or live DVD beforehand.

You can compare with any test snapshot before this one.

~ K


On Friday, May 5, 2017, 11:24:33 PM PDT, Jean-Pierre André 
 wrote:ken mays via oi-dev wrote:
> On that note, be aware of prior notice on AMD64 Athlon 64-based
> computers and the use of software from:

I have such a computer, which I intended to upgrade to 2017.04

Is booting on a live-usb a valid test for presence/absence of
further problems ahead ? (IOW is the problem in the new loader or
in the kernel ?)

Jean-Pierre

>
> http://dlc.openindiana.org/isos/hipster/20170502/
>
> ~ Ken
>
>
>
> On Friday, May 5, 2017, 4:36:35 PM PDT, Adam Števko
>  wrote:
> Hey Ken,
>
> there is no 2017.05 snapshot, onlt 2017.04, which was released on 2 May.
>
> Cheers,
> Adam
>
>> On May 5, 2017, at 5:04 PM, ken mays via oi-dev
>> mailto:oi-dev@openindiana.org>> wrote:
>>
>> Hello,
>>
>> If you are using AMD Athlon 64 (K8) CPUs, it is possible that the
>> current release of OI 2017.05 snapshot will not boot fully.
>> Please bug report if you are using those specific CPUs.
>>
>> Otherwise, all previous OI snapshots were tested as working.
>>
>> ~ Ken





___
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 2017-05 snapshot: AMD Athlon 64 (K8) compatibility issues

[ken mays via oi-dev]

On that note, be aware of prior notice on AMD64 Athlon 64-based computers and 
the use of software from:
http://dlc.openindiana.org/isos/hipster/20170502/
~ Ken


On Friday, May 5, 2017, 4:36:35 PM PDT, Adam Števko  
wrote:Hey Ken,
there is no 2017.05 snapshot, onlt 2017.04, which was released on 2 May.
Cheers,Adam


On May 5, 2017, at 5:04 PM, ken mays via oi-dev  wrote:
Hello,
If you are using AMD Athlon 64 (K8) CPUs, it is possible that the current 
release of OI 2017.05 snapshot will not boot fully.Please bug report if you are 
using those specific CPUs.
Otherwise, all previous OI snapshots were tested as working.
~ Ken
___
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] OI 2017-05 snapshot: AMD Athlon 64 (K8) compatibility issues

[ken mays via oi-dev]

Hello,
If you are using AMD Athlon 64 (K8) CPUs, it is possible that the current 
release of OI 2017.05 snapshot will not boot fully.Please bug report if you are 
using those specific CPUs.
Otherwise, all previous OI snapshots were tested as working.
~ Ken
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] sound-juicer removal?

[ken mays via oi-dev]

Like Joerg mentioned, I also went the similar solution path with cddawav 
(cdrtools) when I maintained gstreamer long ago.
You can glance at Mediamonkey (http://www.mediamonkey.com) and Whipper 
(https://aur.archlinux.org/packages/whipper-git/) for various modernization 
efforts

~ Ken


On Monday, April 3, 2017, 6:44:45 PM PDT, Alexander Pyhalov  
wrote:Hello.

After updating brasero I've looked at sound-juicer to check that it 
didn't break... OK, old sound juicer doesn't work with new brasero.
New sound juicer requires cdparanoia gstreamer 1.0 plugin. We don't ship 
it, because cdparanoia was never properly ported to Solaris.
I've looked at porting it yesterday, but the most I could do so far - is 
to make it get the correct list of CD devices. Now I need to look at 
scsi logic, and I'm afraid it'll take too much effort...
Oracle just removed sound juicer.

I'm considering doing the same (at least if I'll not be able to make it 
work in 1-2 days). Any objections?
By objection I mean: 'Don't drop it, I'll help porting cdparanoia'. 
Everything else seems to be not constructive...
-- 
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] MATE 1.18 testing

[ken mays via oi-dev]

Hello,
This OI-Hipster Pulseaudio 10.0 test binary is based on this compile 
set:https://github.com/oracle/solaris-userland/tree/master/components/desktop/pulseaudio
I've making some adjustments for our Boomer and OSS v4.2 build 201 
compatibility/stability.
Thanks,Ken

 


On Saturday, March 25, 2017, 6:10:11 AM PDT, Aurélien Larcher 
 wrote:

On Fri, Mar 24, 2017 at 11:31 PM, ken mays via oi-dev  
wrote:

Greetings,
MATE 1.18 is now available for OI-Hipster! Well, mostly...

I'm doing an update for the current test ISO, but if you'd like to test over 
the weekend I'll provide a downloadlink when I post it.
I'm still reviewing all posted bugs and feature requests. Anything nimbus 
gtk3-related will also be reviewed. 

Also saw your comment on oi-dev about Pulsaudio 10.
With the default patchset Pulseaudio 9 and 10 do not work reliably and crash 
regularly.
So even if it compiles I would not push it without further testing.
 

Enjoy!,Ken

__ _
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] MATE 1.18 testing

[ken mays via oi-dev]

Greetings,
MATE 1.18 is now available for OI-Hipster! Well, mostly...

I'm doing an update for the current test ISO, but if you'd like to test over 
the weekend I'll provide a downloadlink when I post it.
I'm still reviewing all posted bugs and feature requests. Anything nimbus 
gtk3-related will also be reviewed. 
Enjoy!,Ken
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] Fw: [developer] Review & test request: 7974 Some USB3 drives don't attach

[ken mays via oi-dev]

FYI, as we have recent test-ISO which require patching...
 
 On Wednesday, March 15, 2017 10:08 AM, Dan McDonald  
wrote:
 

 Point your browsers here:

    http://kebe.com/~danmcd/webrevs/7974/

    commit d903346c9538c89e786455bd673eb7b5038f9aff
    Author: Robert Mustacchi 
    Date:  Wed Mar 15 12:58:46 2017 -0400

        7974 Some USB3 drives don't attach
        Reviewed by: Dan McDonald 


Dale and I noticed a certain model of Seagate USB3 drive:

USB    c4t0d0                  Seagate  BUP Slim Mac SL  931.51 GiB  no  no 

wouldn't attach as USB3 under the in-gate XHCI wad.  Luckily, Robert had left 
all the breadcrumbs we needed here:

    https://github.com/joyent/smartos-live/issues/694

After a deep dive, we came up with where exactly it failed, and Robert then 
informed us it was a one-liner, per the webrev above.

If anyone is having a problem attaching a USB3 storage device after this fix 
went upstream, PLEASE rebuild your "usba" module with this fix, and see if you 
have better luck.

Thank you!
Dan



---
illumos-developer
Archives: https://www.listbox.com/member/archive/182179/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182179/21175186-163ec15a
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=21175186&id_secret=21175186-d92734da
Powered by Listbox: http://www.listbox.com

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

Re: [oi-dev] Why are Firefox and Thunderbird built with jemalloc?

[ken mays via oi-dev]

Aurelien,
libumem was the preferred solution a few years ago. I ran across using it for 
Wine and it solved a few things for me.FOSS devs lean on what's supported or 
works for them.
~K
 

On Monday, February 20, 2017 7:33 AM, Aurélien Larcher 
 wrote:
 

 Hi,
This is just a simple and honest question.
I have rebuilt Firefox and Thunderbird with jemalloc disabled and linked to 
libumem.
I am not sure if the behaviour is related to adjusting layout.frame_rate=24 or 
the memory alloc but Thunderbird seems less "bloated".
Any experience?
Kind regards

Aurélien

-- 
---
Praise the Caffeine embeddings

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

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

Re: [oi-dev] Fwd: [Graphics/DRM - Bug #7716] drm hang with ring dumps in messages

[ken mays via oi-dev]

Intel Graphics HD 4000


 

On Friday, February 10, 2017 1:27 PM, Aurélien Larcher 
 wrote:
 

 

On Fri, Feb 10, 2017 at 10:22 PM, ken mays via oi-dev  
wrote:

Hello,
My desktop doesn't hang when doing this test. 


What is the chipset? 


Two things are reporting to fix issue:1. Update xorg-video-intel 2.99.917 
driver to recent git (fixes this for Linux users for same bug).

Nope. I already run latest git with Xorg 1.18.4.
 
2. Patch gfx-drm.
~K
 

On Friday, February 10, 2017 12:14 PM, Aurélien Larcher 
 wrote:
 

 

On Fri, Feb 10, 2017 at 9:06 PM, Marcel Telka  wrote:

I just did on my T520:

mdb -kwe 'i915_try_reset/W 1'

I'll report back in few days if it won't hang (or sooner, if it will).


You can trigger it by running glx_gears in non-synced mode: vblank_mode=0 
glxgears

See if the GPU hangs 2-3 seconds then continues.
 


Thanks.


On Fri, Feb 10, 2017 at 02:39:07PM -0500, Gordon Ross wrote:
> I've heard this happens on the Lenovo W520 (and maybe others)
> Can anyone try this for me?  Thanks.
>
>
> -- Forwarded message --
> From: illumos project 
> Date: Fri, Feb 10, 2017 at 2:37 PM
> Subject: [Graphics/DRM - Bug #7716] drm hang with ring dumps in messages
> To:
>
>
> Issue #7716 has been updated by Gordon Ross.
>
>
> Can anyone with one of the systems affected by this hang try setting
>   i915_try_reset = true
> (you can use mdb -kw to set it)
> and report back with the result?  Thanks!
>
> -- --
> Bug #7716: drm hang with ring dumps in messages
> https://www.illumos.org/ issues/7716#change-18715
>
> * Author: Marcel Telka
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category:
> * Target version:
> * Difficulty: Medium
> * Tags: needs-triage
> -- --
> I face the drm hang with the flood of ring dumps in the
> /var/adm/messages (attached).  After the hang the screen shows the
> distorted image and Xorg core dumps.  The only way I found how to get
> out of this is reboot.
>
> Here is the beginning of the messages log:
>
> 
> Jan  2 11:41:32 telcontar drm: [ID 300979 kern.warning] WARNING:
> [drm:ring_dump:881] Dump render ring ring
> Jan  2 11:41:32 telcontar drm: [ID 834546 kern.warning] WARNING:
> [drm:ring_dump:882] HEAD 0x14d04 TAIL 0x14e28
> Jan  2 11:41:32 telcontar drm: [ID 628728 kern.warning] WARNING:
> [drm:ring_dump:883] seq 3742159
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a34]: 0x12044
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a38]: 0x3919c9
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a3c]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a40]: 0x1101
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a44]: 0x22040
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a48]: 0x3919c9
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a4c]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a50]: 0x1081
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a54]: 0x80
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a58]: 0x3919c9
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a5c]: 0x100
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a60]: 0xb160001
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a64]: 0x3919c9
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a68]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a6c]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a70]: 0x7a03
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a74]: 0x12
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a78]: 0x261084
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a7c]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warn

Re: [oi-dev] Fwd: [Graphics/DRM - Bug #7716] drm hang with ring dumps in messages

[ken mays via oi-dev]

Hello,
My desktop doesn't hang when doing this test. 

Two things are reporting to fix issue:1. Update xorg-video-intel 2.99.917 
driver to recent git (fixes this for Linux users for same bug).2. Patch gfx-drm.
~K
 

On Friday, February 10, 2017 12:14 PM, Aurélien Larcher 
 wrote:
 

 

On Fri, Feb 10, 2017 at 9:06 PM, Marcel Telka  wrote:

I just did on my T520:

mdb -kwe 'i915_try_reset/W 1'

I'll report back in few days if it won't hang (or sooner, if it will).


You can trigger it by running glx_gears in non-synced mode: vblank_mode=0 
glxgears

See if the GPU hangs 2-3 seconds then continues.
 


Thanks.


On Fri, Feb 10, 2017 at 02:39:07PM -0500, Gordon Ross wrote:
> I've heard this happens on the Lenovo W520 (and maybe others)
> Can anyone try this for me?  Thanks.
>
>
> -- Forwarded message --
> From: illumos project 
> Date: Fri, Feb 10, 2017 at 2:37 PM
> Subject: [Graphics/DRM - Bug #7716] drm hang with ring dumps in messages
> To:
>
>
> Issue #7716 has been updated by Gordon Ross.
>
>
> Can anyone with one of the systems affected by this hang try setting
>   i915_try_reset = true
> (you can use mdb -kw to set it)
> and report back with the result?  Thanks!
>
> -- --
> Bug #7716: drm hang with ring dumps in messages
> https://www.illumos.org/ issues/7716#change-18715
>
> * Author: Marcel Telka
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category:
> * Target version:
> * Difficulty: Medium
> * Tags: needs-triage
> -- --
> I face the drm hang with the flood of ring dumps in the
> /var/adm/messages (attached).  After the hang the screen shows the
> distorted image and Xorg core dumps.  The only way I found how to get
> out of this is reboot.
>
> Here is the beginning of the messages log:
>
> 
> Jan  2 11:41:32 telcontar drm: [ID 300979 kern.warning] WARNING:
> [drm:ring_dump:881] Dump render ring ring
> Jan  2 11:41:32 telcontar drm: [ID 834546 kern.warning] WARNING:
> [drm:ring_dump:882] HEAD 0x14d04 TAIL 0x14e28
> Jan  2 11:41:32 telcontar drm: [ID 628728 kern.warning] WARNING:
> [drm:ring_dump:883] seq 3742159
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a34]: 0x12044
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a38]: 0x3919c9
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a3c]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a40]: 0x1101
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a44]: 0x22040
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a48]: 0x3919c9
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a4c]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a50]: 0x1081
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a54]: 0x80
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a58]: 0x3919c9
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a5c]: 0x100
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a60]: 0xb160001
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a64]: 0x3919c9
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a68]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a6c]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a70]: 0x7a03
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a74]: 0x12
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a78]: 0x261084
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a7c]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a80]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a84]: 0x0
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a88]: 0x7a03
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a8c]: 0x4000
> Jan  2 11:41:32 telcontar drm: [ID 994420 kern.warning] WARNING:
> [drm:ring_dump:890] render ring[0x14a90]: 0x

Re: [oi-dev] Latest DRM working OK on iron lake?

[ken mays via oi-dev]

Hello,

I see the current /dev DRM packages at 20161230 so possibly missing recent 
commits?

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

Re: [oi-dev] Problems with packages and drm

[ken mays via oi-dev]

Happy New Year!!!

Great work by great people

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

Re: [oi-dev] Problems with packages and drm

[ken mays via oi-dev]

Suggesting use of the 2016Q4 Intel release notes as explained in IRC.

Upstream have other thoughts?




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

Re: [oi-dev] Problems with packages and drm

[ken mays via oi-dev]

Migrate your work to libdrm 2.4.74 and we'll scan it for our compliance review.
~ Ken
 

On Tuesday, December 27, 2016 7:17 AM, Alexander Pyhalov  
wrote:
 

 On 12/27/16 02:02 PM, Alexander Pyhalov wrote:
> On 12/26/16 09:17 PM, Andreas Wacknitz wrote:
>> Hi,
>>
>> I have two kind of problems building and publishing packages with drm.
>>
>> 1. #include  fails for several packags now.
>>    I don't know whether this is simply because of a missing include
>> path or something else.
>>    Example packages: x11/mesa, x11/redshift, x11/tigervnc,
>> x11/xf86-video-ati, x11/xf86-video-openchrome
>> 2. Some package cannot link successfully anymore because of 32/64 clash
>> with libdrm.so:
>>    They fail with "ld: fatal: file /usr/lib/xorg/amd64/libdrm.so: wrong
>> ELF class: ELFCLASS64"
>>    It seems as if 32 bit builds try to use 64 bit libdrm.
>>    Example packages: clutter-gst, clutter-gtk
>>
>> Are these problems local here or does anybody else suffer? And how can
>> this be fixed?
>>
>
> Hi.
> Updated my build zone, installed header-drm
> See the same.
> libdrm.pc is broken.
>
> Created https://www.illumos.org/issues/7692 .
>
>

Gordon, it seems the following patch fixes the issue:

https://github.com/pyhalov/gfx-drm/commit/b1ebcc82b300cdb4abd4ad83b0b1b832758fb73f

Current patch mechanism in gfx-drm is ugly, so I had to update also 
another patch, touching *.pc.in files, but it's as sepate issue.

Also this patch fixes one compilation warning:
https://github.com/pyhalov/gfx-drm/commit/b30075dd1203a123a871687281c2dc1f38fe956e
(seems to appear only in debug build).


As this issue affects oi-userland build, I'd appreciate if someone 
committed this (or another) fix for https://www.illumos.org/issues/7692
-- 
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] [OpenIndiana-discuss] Looking for translators for the updated 'openindiana-welcome'

[ken mays via oi-dev]

Michael,


== OpenIndiana Welcome page in Spanish 


OpenIndiana Logo

Bienvenido a OpenIndiana inconformista!


OpenIndiana es un Illumos distribución basada en Unix deriva de

OpenSolaris. Construido como un sistema operativo de propósito general

características de clase empresarial, OpenIndiana Hipster es desarrollado por el

comunidad y para la comunidad.



OpenIndiana obtiene su nombre de Proyecto de Indiana, un esfuerzo de código 
abierto

por Sun Microsystems (ahora Oracle Corporation) para producir OpenSolaris, una

comunidad desarrolló distribución similar a Unix basados en Sun Solaris. 
Proyecto

Indiana fue dirigido por Ian Murdock, fundador de la distribución Debian Linux.

Algunas de las diferencias entre OpenIndiana y OpenSolaris puede haber

caracterizado como sigue:



OS / NET consolidación de Sun (cerrado por Oracle) ha sido sustituido

con Illumos puerta.



Muchas de las consolidaciones originales de software OpenSolaris han sido

reorganizado en un solo consolidación oi-espacio de usuario.

Sun Studio de Oracle ha sido sustituido por el código abierto GNU GCC

compilador.


XVM (XEN) ha sido reemplazado con el puerto Illumos-KVM.


Características OpenIndiana inconformista Enterprise Class

función Descripción

Sistema de archivos ZFS y Volume Manager

Dtrace de rastreo dinámico (Sistema de introspección)

Ballesta de virtualización de red y de control de recursos

De gestión de servicios SMF

FMA Fault Management Architecture

COMSTAR Común multiprotocolo de destino SCSI (iSCSI Target Marco)

Basado en el kernel de KVM Virtual Machine (La virtualización del sistema 
operativo)

Zonas el nivel del SO virtualizado Aplicación Contenedores

Tiempo-deslizante automatizada de instantáneas de ZFS y Retrotracciones

Role-Based Access Control RBAC

IPMP múltiple en redes IP

DLMP de enlace de datos múltiples rutas


Notas de la versión

https://wiki.openindiana.org/oi/Release+Notes


Sobre nosotros

El Proyecto OpenIndiana es una comunidad de voluntarios y UNIX

los entusiastas de todo el mundo. Actualmente construir servidores, hosting y

el ancho de banda es donado por EveryCity de alojamiento en el Reino Unido.


Involucrado

Nuestro éxito como una distribución depende del éxito de nuestra comunidad,

es por ello que nos gustaría invitar a todos los interesados en el futuro

OpenIndiana de participar e involucrarse!

Tenemos muchos recursos a partir del cual se puede empezar, incluyendo nuestro

Wiki, listas de correo y el canal de IRC.

Para los desarrolladores tenemos imágenes de desarrollo que pueden ser Vagrant

fácil de implementar.

Para los usuarios finales que tenemos depósitos de IPS disponibles al público 
para

actualización de la instalación con las últimas correcciones de software y 
seguridad.


Campo de golf

Página web: https://openindiana.org

Wiki: https://wiki.openindiana.org

Listas de correo: http://openindiana.org/mailman

Canal IRC: #openindiana en irc.freenode.net


Licencia

OpenIndiana Información sobre licencias 


===

Enjoy!,
Ken

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

Re: [oi-dev] Updated OpenIndiana-Welcome

[ken mays via oi-dev]

Michael,

I like it overall.

Ken




On Sunday, October 23, 2016 7:55 PM, Michael Kruger  
wrote:
This is a request for comments for an updated OpenIndiana-Welcome doc...


...
ODT file is attached.

thanks,

Michael

___
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] AMDgpu 1.1.2 and OpenChrome 0.5.159 drivers

[ken mays via oi-dev]

ts submitted proposals for
those ideas; that was unexpected! We now need to decide which one we
want to mentor and the choice is difficult.

Our blog has moved to a new location (linked above).


p.s. Ken, I found this in 
https://lists.freebsd.org/pipermail/freebsd-current/2016-May/060964.html
MIND THE LENGTH.

We here have 0.1% as many resources compared to them.


So your message is a mystery to me.
The most funny part is that you didn't at least mention that KMS would 
hypothetically be needed for this.

Read your announcement:

https://openindiana.org/pipermail/oi-dev/2016-September/004869.html 

"""""Hello, We have updated and tested 32/64-bit 2D drivers for the AMDgpu 
1.1.2 and Openchrome 0.5.159 
supported graphic adapters for OI-Hipster. The AMDgpu driver mainly support AMD 
Radeon R9 series graphic 
adapters (see: https://wiki.openindiana.org/oi/Graphics+Adapters). The 
OpenChrome 0.5.159 driver is a free 
and Open Source 2D video driver for the VIA/S3G UniChrome, UniChrome Pro and 
Chrome9 graphics chipsets: 
CLE266, KM400/KN400/KM400A/P4M800, CN400/PM800/PN800/PM880, K8M800, 
CN700/VM800/P4M800Pro, 
CX700, K8M890, P4M890, P4M900/VN896/CN896, VX800, VX855, VX900. We'll try to 
have everything included 
in the next snapshot release. Thanks, Ken"""""


You know, being optimistic versus pessimistic is certainly one thing to agree 
or disagree with and to discuss about.
But on the last day before defeat shouting "We soon win the war, yupee yaeh!" - 
Is that "optimism"?




best regards,
%martin bochnig





 Понедельник, 26 сентября 2016, 19:02 UTC от ken mays via oi-dev 
:
 
Now that we are able to compile the drivers for phase 1 ... the kernel 
components are the next implementation phase...


I'd like to update all of the X11 2D video drivers when time permits.

~ Ken




On Monday, September 26, 2016 11:08 AM, Alexander Pyhalov  wrote:
> On Monday, September 26, 2016 10:37 AM, Alexander Pyhalov  
> wrote:
> Hi.
> 
> 
> ken mays via oi-dev писал 26.09.2016 19:54:
>> Hello,
>> 
>> We have updated and tested 32/64-bit 2D drivers for the AMDgpu 1.1.2
>> and Openchrome 0.5.159 supported graphic adapters for OI-Hipster.
>> 
>> The AMDgpu driver mainly support AMD Radeon R9 series graphic adapters
>> (see: https://wiki.openindiana.org/oi/Graphics+Adapters).
>> 
>> The OpenChrome 0.5.159 driver is a free and Open Source 2D video
>> driver for the VIA/S3G UniChrome, UniChrome Pro and Chrome9 graphics
>> chipsets: CLE266, KM400/KN400/KM400A/P4M800, CN400/PM800/PN800/PM880,
>> K8M800, CN700/VM800/P4M800Pro, CX700, K8M890, P4M890,
>> P4M900/VN896/CN896, VX800, VX855, VX900.
>> 
> 
> Doesn't amdgpu require KMS?

ken mays писал 26.09.2016 20:47:
> Yes...

So how is it suposed to work on OI?


---
System Administrator of Southern Federal University Computer Center

___
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] AMDgpu 1.1.2 and OpenChrome 0.5.159 drivers

[ken mays via oi-dev]

Now that we are able to compile the drivers for phase 1 ... the kernel 
components are the next implementation phase...


I'd like to update all of the X11 2D video drivers when time permits.

~ Ken




On Monday, September 26, 2016 11:08 AM, Alexander Pyhalov  wrote:
> On Monday, September 26, 2016 10:37 AM, Alexander Pyhalov  
> wrote:
> Hi.
> 
> 
> ken mays via oi-dev писал 26.09.2016 19:54:
>> Hello,
>> 
>> We have updated and tested 32/64-bit 2D drivers for the AMDgpu 1.1.2
>> and Openchrome 0.5.159 supported graphic adapters for OI-Hipster.
>> 
>> The AMDgpu driver mainly support AMD Radeon R9 series graphic adapters
>> (see: https://wiki.openindiana.org/oi/Graphics+Adapters).
>> 
>> The OpenChrome 0.5.159 driver is a free and Open Source 2D video
>> driver for the VIA/S3G UniChrome, UniChrome Pro and Chrome9 graphics
>> chipsets: CLE266, KM400/KN400/KM400A/P4M800, CN400/PM800/PN800/PM880,
>> K8M800, CN700/VM800/P4M800Pro, CX700, K8M890, P4M890,
>> P4M900/VN896/CN896, VX800, VX855, VX900.
>> 
> 
> Doesn't amdgpu require KMS?

ken mays писал 26.09.2016 20:47:
> Yes...

So how is it suposed to work on OI?


---
System Administrator of Southern Federal University Computer Center

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

Re: [oi-dev] AMDgpu 1.1.2 and OpenChrome 0.5.159 drivers

[ken mays via oi-dev]

Yes...




On Monday, September 26, 2016 10:37 AM, Alexander Pyhalov  wrote:
Hi.


ken mays via oi-dev писал 26.09.2016 19:54:
> Hello,
> 
> We have updated and tested 32/64-bit 2D drivers for the AMDgpu 1.1.2
> and Openchrome 0.5.159 supported graphic adapters for OI-Hipster.
> 
> The AMDgpu driver mainly support AMD Radeon R9 series graphic adapters
> (see: https://wiki.openindiana.org/oi/Graphics+Adapters).
> 
> The OpenChrome 0.5.159 driver is a free and Open Source 2D video
> driver for the VIA/S3G UniChrome, UniChrome Pro and Chrome9 graphics
> chipsets: CLE266, KM400/KN400/KM400A/P4M800, CN400/PM800/PN800/PM880,
> K8M800, CN700/VM800/P4M800Pro, CX700, K8M890, P4M890,
> P4M900/VN896/CN896, VX800, VX855, VX900.
> 

Doesn't amdgpu require KMS?

---
System Administrator of Southern Federal University Computer Center

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

Re: [oi-dev] AMDgpu 1.1.2 and OpenChrome 0.5.159 drivers

[ken mays via oi-dev]

Hello,

There are actually two driver versions: AMDgpu and AMDgpu-PRO (full featured, 
closed kernel sources)

AMDgpu driver mainly supports the AMD Radeon R7 260/260X and R9 GPUs.


Yes, same linux driver. 



Thanks,
Ken







On Monday, September 26, 2016 10:21 AM, C Bergström  
wrote:
sorry - drive-by stupid question. The "AMDGPU" driver is this the same
things as the new driver going into the linux kernel? The old open
source driver was called Radeon..  The "amdgpu" driver I'm aware of
was originally planned to be Fiji class cards (Volcanic Islands?) and
forward, but they ended up (recently) porting it to Hawaii class cards
(known at Southern Islands)

I'm not sure if this is the same or similar thing and just curious..
(If it is that would be very cool)



On Tue, Sep 27, 2016 at 12:54 AM, ken mays via oi-dev
 wrote:
> Hello,
>
> We have updated and tested 32/64-bit 2D drivers for the AMDgpu 1.1.2 and 
> Openchrome 0.5.159 supported graphic adapters for OI-Hipster.
>
> The AMDgpu driver mainly support AMD Radeon R9 series graphic adapters (see: 
> https://wiki.openindiana.org/oi/Graphics+Adapters).
>
> The OpenChrome 0.5.159 driver is a free and Open Source 2D video driver for 
> the VIA/S3G UniChrome, UniChrome Pro and Chrome9 graphics chipsets: CLE266, 
> KM400/KN400/KM400A/P4M800, CN400/PM800/PN800/PM880, K8M800, 
> CN700/VM800/P4M800Pro, CX700, K8M890, P4M890, P4M900/VN896/CN896, VX800, 
> VX855, VX900.
>
>
> We'll try to have everything included in the next snapshot release.
>
> Thanks,
> Ken
>
> ___
> 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] AMDgpu 1.1.2 and OpenChrome 0.5.159 drivers

[ken mays via oi-dev]

Hello,

We have updated and tested 32/64-bit 2D drivers for the AMDgpu 1.1.2 and 
Openchrome 0.5.159 supported graphic adapters for OI-Hipster.

The AMDgpu driver mainly support AMD Radeon R9 series graphic adapters (see: 
https://wiki.openindiana.org/oi/Graphics+Adapters).

The OpenChrome 0.5.159 driver is a free and Open Source 2D video driver for the 
VIA/S3G UniChrome, UniChrome Pro and Chrome9 graphics chipsets: CLE266, 
KM400/KN400/KM400A/P4M800, CN400/PM800/PN800/PM880, K8M800, 
CN700/VM800/P4M800Pro, CX700, K8M890, P4M890, P4M900/VN896/CN896, VX800, VX855, 
VX900. 


We'll try to have everything included in the next snapshot release.

Thanks,
Ken

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

Re: [oi-dev] X11 update

[ken mays via oi-dev]

Martin,
Well, you detailed out what I was aiming at - it is not the driver. Yes, I know 
about the Solaris graphics backend components as it was discussed years ago - 
straight from the Sun USA/China kernel teams and X11 team. I'vewalked the green 
mile with each graphics driver whether from Sun, IHV, or open source. The more 
we talk about this the older I get.

Your point is clear - don't use Intel SNA for Solaris/illumos based systems at 
this time. I didn't suggest it as it'll make your hair turn silvery grey! 
They used to say "love is all you need" ... guess not.
~K
 



On Friday, September 16, 2016 5:52 PM, Мартин Бохниг  
wrote:
 

 
> Kernel DRM needs more love.

Unfortunately I spent all of this year for Hipster related projetcs.
It doesn't need "more love" but some $$$ to pay the running bills, but I 
understand that community work will never ever be sustainable to us here who 
actually do something (and I'm only one of many), hence forget my comment.
Vbox 5.1.6 is almost ready to ship, I made it work with Qt4.8 aagain after 
having messsed 1 week with Qt5.8alpha (and other 5.x branches).
Qt 5.x needs more love, and its newer versions are not yet compatible with Vbox 
even *if* and *after* you got it all built for 64bit (and Vbox is 64bit-only 
since 5.0).


As of Intel DRM versus SNA:

Sun and then Oracle never enabled SNA for their Xorg ddx, they strictly 
defaulted and still keep defaulting to UXA.
And there is a good reason for this: SNA performs about 10 times *slower* on 
Solaris kernels than with accelleration disabled in the Intel ddx!
You can test that on Intel Xorg ddx 2.2x with SNA enabled. Unlike 2.99.x which 
is a _pre_release 3.0 _non_version (as shipped in Hipster), the 2.2x Intel ddx 
branch does _not_ segfault with the S12 DRM/KMS bakport. But you never in your 
life witnessed such a sloow-mtion anti-performance if you 
explicitly make it use SNA (by compiling in SNA support _plus_ [on Solars] by 
explicitly specifying SNA accell via xorg.conf).

After you experienced that (I mentioned it last winter) you will stop whining 
abbout lack of SNA.
Reminder: Sun/Oracle also intentionally do NOT use it.

So rather than spreading such vague uncertainty like "needs more love", be more 
specific: The only thing which i915/drm-kms works on Hipster is support for <= 
generation 5 Intel GPU's.
And to get *that*, not the driver needs any single line of change, but Illumos' 
outdated agpgart stack needs to get enhanced.
And that would already have happened had I not wasted 1 week on Qt5 which is 
really a pain on my Hipster installation based on illumos-f83b46b .

Because even after converting Aurelien's specs to match 
qt5/qt-everywhere-opensource-src-5.8.0-alpha/qtbase/mkspecs/solaris-g++-64 on 
my machine it still didn't work at all with Qt5.6 or higher, due to changes in 
qmake.
I always ended up in this exact scenario: 
http://stackoverflow.com/questions/38549755/raspberry-pi-2-and-qt-5-7-make-stuck-at-qtbase-bin-qmake-conf-qtbase-q
 

And that also includedes the workaround.
However, with the resulting painfully built Qt5.8 and based on that Vbox linked 
against it all one would get was 20 lines of *this*:  
"gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem"

KMS: Needs more love: What arou you waiting for?
Specifics?
diffs?


%m



 Пятница, 16 сентября 2016, 23:25 UTC от ken mays via oi-dev 
:3. On Intel, UXA works well while SNA still crashes.
- SNA is improved in current Intel drv git. Kernel DRM needs more love. 

~K


Unfortunately I spent all of this year for Hipster related projetcs.


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

Re: [oi-dev] X11 update

[ken mays via oi-dev]

Reviews below (-):
1. enabling EGL in mesa activates some tests which do not compile in mesa-demos,
- We can disable this in mesa-demos for default builds.

2. glamor EGL support needs patching,
- OK.

3. On Intel, UXA works well while SNA still crashes.
- SNA is improved in current Intel drv git. Kernel DRM needs more love. 

~K
 

On Friday, September 16, 2016 3:55 PM, Aurélien Larcher 
 wrote:
 

 On Fri, Sep 16, 2016 at 5:29 PM, Aurélien Larcher
 wrote:
> Hi,
> I updated the X11 branch yesterday with mesa 12.0.3:
>
> https://github.com/OpenIndiana/oi-userland/pull/2360
>
> Some observations:
> - enabling EGL in mesa activates some tests which do not compile in 
> mesa-demos,
> - glamor EGL support needs patching,
> - latest build tested on Nvidia and Intel,
> - on Intel, UXA works well while SNA still crashes.
>
> If someone finds time to help with packaging X11 fonts and fixing
> mesa-demos and glamor, it will be very much appreciated :)

The testing branch is now updated to Xorg 1.18.4

helios> Xorg -version



X.Org X Server 1.18.4
Release Date: 2016-07-19
X Protocol Version 11, Revision 0
Build Operating System: SunOS 5.11 i86pc
Current Operating System: SunOS helios 5.11 illumos-79d7283 i86pc
Build Date: 17 September 2016  12:11:49AM
Solaris ABI: 64-bit
Current version of pixman: 0.32.8
    Before reporting problems, check http://openindiana.org
    to make sure that you have the latest version.



Thanks

Aurelien

> Cheers
>
> Aurelien
>
> --
> ---
> Praise the Caffeine embeddings



-- 
---
Praise the Caffeine embeddings

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

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

Re: [oi-dev] [CFT] Mesa 12

[ken mays via oi-dev]

After the Xserver bump, I'll push the Radeon KMS components.~K
 

On Monday, September 12, 2016 7:31 AM, Alexander Pyhalov  
wrote:
 

 On 09/12/16 05:23 PM, ken mays via oi-dev wrote:
> Enable:--enable-gbm
> --enable-egl
>
> If you want to build the amdgpu driver for Radeon R7/8/9-series and RX 
> 400-series card support.
>

Hi.

Doesn't it require Radeon KMS  support to work correctly?

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

Re: [oi-dev] [CFT] Mesa 12

[ken mays via oi-dev]

Enable:--enable-gbm
--enable-egl

If you want to build the amdgpu driver for Radeon R7/8/9-series and RX 
400-series card support.

~ Ken
 

On Monday, September 12, 2016 6:43 AM, Alexander Pyhalov  
wrote:
 

 Hello.

All are welcome to test 
x11/library/mesa@12.0.2-2016.0.0.0:20160912T122345Z from 
http://buildzone.oi-build.r61.net:1000/


I've tested it only on VirtualBox / compiz. Testers with Intel and 
Radeon video adapters are welcome. (It shouldn't have impact on NVidia 
users, as NVidia ships own libGL).
-- 
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] GDB Error

[ken mays via oi-dev]

Provide: 'uname -a'
 

On Wednesday, September 7, 2016 3:58 PM, Franklin 
 wrote:
 

 Hi friends,

I try to debug with GDB but the error is raised: lwp_to_thread: 
td_ta_map_lwp2thr: Debugger service failed.

The curious thing is that yesterday was working normally. I updated my hipster 
today, but i'm not sure this is related.

Anyone has same problem?

$ gdb ./top 
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.11".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./top...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/fronald/Projects/OpenSource/top-3.8beta1/top 
[Thread debugging using libthread_db enabled]
lwp_to_thread: td_ta_map_lwp2thr: Debugger service failed.
(gdb)


-- 
Franklin Ronald
---

___
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] LFR: github pull requests

[ken mays via oi-dev]

Richard,
I had ported various bits for my Radeon 6870. I was awaiting our Xserver 1.18.3 
merge as I'm working on the AMDgpu backend as well for newer cards.
~ Ken
 

On Monday, September 5, 2016 4:59 AM, Richard PALO  
wrote:
 

 Le 05/09/16 08:35, Alexander Pyhalov a écrit :
> On 09/ 5/16 01:54 AM, Aurélien Larcher wrote:
>>> https://github.com/OpenIndiana/oi-userland/pull/2360 - X11 application stack
>>> updates
>>
>> I rebuilt the WIP X11 branch and updated my workstation: I am now
>> running Xorg 1.18.3 with a Quadro FX 3800 card.
>> It would be nice if more people could test it so that we can update
>> our X11 stack.
> 
> One thing to be noted. Newer Xorg doesn't support UMS radeon driver, so 
> updating Xorg means dropping Radeon support.
> 

Just take a look at pkgsrc x11/xf86-video-ati6
I've been using that for a long while now with a Radeon HD 5450 on recent 
[pkgsrc] Xorg bits
unfortunately I run omnios so can't say how the KMS integrated in hipster 
changes the equation.
cheers
-- 
Richard PALO


___
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] DIFF adding to MATE Compiz Special Effects to "Appearance Preferences > Visual Effects" tab used in the old Gnome2

[ken mays via oi-dev]

Martin,
Let us see how RM's implementation evolves. There is some work in doing USB 
certification driver testing.Having the adequate resources and time to test 
various situations is very time-consuming.

Strengthening and improving our graphics/sound stack and MATE desktop 
environment is time well spent for now.
~ Ken 

On Monday, August 29, 2016 12:15 PM, Мартин Бохниг  wrote:
 

 
Ken,

sure, I'm glad to do that. But my build machine is too outdated.
I perhaps should upgrade the entire host to Hipster's latest MATE iso level (or 
I do that on the old laptop for now).
And yes, thankfully there is already one where Alexander has included my 
DRM/KMS Sol12 backport diffs from July on August 20th (not the original iso/usb 
that were publicly announced 4 days earlier).
I fyi had requested the OpenSXCE community to test the Hipster iso (and also 
tested it myself on Ivy and reported to Hipster-core via OFFlist emails, as you 
know) :

https://twitter.com/OpenSXCE/status/768684093584379904 

http://pastebin.com/raw/MYba5A9q

As for xhci: Do you really think my instructions or now cancelled src port 
beginnings are still wanted or needed, now after RM published his webrev 
yesterday?

If you think yes, then I'm glad to publish the instructions how to make the 
Sol11 bins work on OpenSolaris (while at the same time making the entire 
installation fall under Oracle's Solaris 11 license terms) ?
As for my xhci src port: RM is much further with that, as I outlined earlier I 
started working on this only after I finished the Grub2 UEFI32 Atom Tablet port.
But the steps how to get Sol11's xhci and usb stack working if the user is  
willing and ready to turn his installation fully under Oracle's licensing, then 
no problem, glad to describe this if anybody wants.
This probably only applies to private non-commercial users, who are free to use 
Oracle Solaris 11 for testing for a while.
Businesses can only legally do this if they already have a valid commercial 
Oracle license. But those that do would probably not run OpenSolaris, but 
Solaris 11.x in the first place.

So just advise what the community wants (or perhaps the community itself should 
tell me).


--
best regards
%martin bochnig






 Понедельник, 29 августа 2016, 17:50 UTC от ken mays :
 
 
Martin,
Feel free to implement the full patch. I tested the ccsm and other methods but 
didn't like the 'user (non-GUI)' feel of it.I agree on the previous visual 
effects GUI model you mentioned..
We also have a recent GNOME ISO/USB build, but it may not have the DRM update. 
Check with Alp on that.I'd like to see us add the XHCI update as well so we can 
test all of this at current state...

~ Ken


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

Re: [oi-dev] DIFF adding to MATE Compiz Special Effects to "Appearance Preferences > Visual Effects" tab used in the old Gnome2

[ken mays via oi-dev]

Martin,
Feel free to implement the full patch. I tested the ccsm and other methods but 
didn't like the 'user (non-GUI)' feel of it.I agree on the previous visual 
effects GUI model you mentioned..
We also have a recent GNOME ISO/USB build, but it may not have the DRM update. 
Check with Alp on that.I'd like to see us add the XHCI update as well so we can 
test all of this at current state...

~ Ken


 

On Monday, August 29, 2016 8:18 AM, Мартин Бохниг via oi-dev 
 wrote:
 

 Hi Alexander,

thanks for testing on a new enough host.

My diff was the result of an alotted time slot of all in all 60 minutes on a 
Sunday evening.
It fixes a bug in OI's Mate port but no-where did I claim that it is 100% 
complete.

For some reason you missed the most important part of my message:

https://openindiana.org/pipermail/oi-dev/2016-August/004718.html 

"p.s. My build host's gtk2 is too old, so this is not yet fully tested 
(please do so).
This attached patch is mostly complete, but I don't rule out that it perhaps 
needs potential polishing."

So now let me know if you want me to fix it or wnat to fix it yourself.
As said, for this I must upgrade a few bits here  (configure complains about 
too old deps).


--
best regards
%martin bochnig



 Понедельник, 29 августа 2016, 12:07 UTC от Alexander Pyhalov :
 
 
On 08/28/16 09:55 PM, Мартин Бохниг via oi-dev wrote:

>
Hi, Martin.

The patch you proposed doesn't compile as it is :

   CCLD mate-appearance-properties
ld: warning: file 
/export/home/alp/srcs/oi-userland/components/desktop/mate/mate-control-center/build/i86/libwindow-settings/.libs/libmate-window-settings.so:
 
linked to ../../libwindow-settings/.libs/libmate-window-settings.so: 
attempted multiple inclusion of file
Undefined first referenced
  symbol in file
effects_init appearance-main.o


Other issue I see is that patch still refers to Gnome gconf settings for 
panel, metacity, etc... Mate corresponding applications already use 
dconf (gsetting) for these settings. Compiz still use gconf. So, it's 
necessary to fix this patch, so that it uses dconf for getting/setting 
Mate applications settings.
-- 
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] Mate is here (as well as new test ISOs)

[ken mays via oi-dev]

Alex,
I'm using the latest MATE Live-DVD ISO.
Not having as many problems 'yet' - but the key things from my point are:
1. Murrine GTK+ Cairo Engine is missing. Certain appearance themes don't look 
correctly without it (i.e. almost any theme thumbnail with the MATE symbol on 
it).Ref: https://download.gnome.org/sources/murrine/0.98/
2. Support for NTFS/exFAT-formatted storage USB devices. We can do this by 
including the Tuxera NTFS/exFAT and/or FOSS fuse support.

3. Boot menu still reads '2016.04'
Then, focus on VMware/Virtualbox support issues.
Thanks,Ken


 

On Tuesday, August 16, 2016 9:21 AM, Alexander Pyhalov  wrote:
 

 On 08/16/16 07:07 PM, Udo Grabowski (IMK) wrote:
> On 16/08/2016 17:32, Alexander Pyhalov wrote:
>> On 08/16/16 06:22 PM, Udo Grabowski (IMK) wrote:
>>> On 16/08/2016 17:10, Alexander Pyhalov wrote:
>>
 We'd like to hear your opinion, which images are necessary for next
 snapshot
 (supposedly, 2016.10). We think that minimal one, Mate and Gnome one
 are enough.
 We are going to avoid delivering Gnome ISO image after next snapshot
 (in 2017).

 Also we are interested to hear if community needs VM images, and if it
 needs,
 then what exactly (qcow2, vmdk or something else).
>>>
>>> Good work ! But under qemu-kvm, the MATE iso fails by starting Caja
>>> in an endless loop (visible in the lower panel), so the desktop remains
>>> mostly black, and Mate does not stop starting...
>>
>> Can you start with ssh enabled, login as jack remotely and see if
>> there are any
>> messages in ~/.xsession-errors?
>
> ssh connection refused (sshd is running) - either misconfigured or not
> starting
> correctly; if jack has an empty password

It's jack/jack

These two lines are bad...


> Connection failure: Connection refused

> The program caja received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadLength (poly request too large or internal Xlib
> lenght error (Details: serial 262 error_code 16 request_code 72
> minor_code 0)

If I new what connection is refused...  The closest thing I find is 
https://bugs.mysql.com/bug.php?id=55441 , but this looks strange.
Will look if we can reproduce this locally.
-- 
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] Stable Intel DRM/KMS Sol12 backport diffs and test bins

[ken mays via oi-dev]

Martin,
I've kept things current with the Intel 2D driver. Started to sync your work 
with the latest Intel DRM/Mesa 12.0.1for the next OI-Hipster release. Will work 
on OpenSXCE testing as time permits.  Intel Iris Pro P580 workswith your code.
Glad to send a donation to the cause.
~K 

On Wednesday, August 10, 2016 4:09 AM, Мартин Бохниг via oi-dev 
 wrote:
 

 Fortunately I'm now permitted to post to Illumos-devel again (under strict 
moderation, but it works nicely), thanks to Rich Lowe and Illumos for that :)


Here extra infos which are related and which will one day be part of the 
ReleaseNotes, hence need to be posted also here (just in case anybody will ever 
want KMS for anything, of which I'm not convinced anymore)

https://www.listbox.com/member/archive/182179/2016/08/sort/time_rev/page/1/entry/3:98/20160809131319:8D2306CC-5E54-11E6-B788-F6CA7ACD9AB7/
 





Вторник, 9 августа 2016, 16:21 UTC от "Albert Lee" :

Hi Martin, These changes provide a full KMS-based console too? That would be 
exciting. -Albert


Hi Albert,

what do you mean with "KMS based console", vconsole?
You cannot exit X11 and return to a working text console with this on Sol11.0 
or lower at the moment (including Illumos, while Sol11.0 is a special case in 
the middle, thanks to its half-way modernized gfx_private which got finished by 
Sun/Oracle only in 11.1 and hardly changed since then).
Same problem as on FreeBSD's latest KMS port bits (btw 2 years newer than what 
we have here, but more on that in the deferred long ReleaseNotes), without 
vbios support inside the kernel (unix) itself hooked into via gfx_private.
On 11.1++ the 100% identical kms bins do not have this issue.
But here on 11.0 and Illumos the same limitation also affects the use of this 
backport together with vconsole.
Restarting gdm is fine. Exiting X11 also works, stdin does function (only that 
you have a black screen until you blindly or via ssh restart Xorg).

Or are you referring to somebody else's effort to add VESA/VBE support to text 
mode?
If that's the case, then that's also in progress and his github is public, 
probably well-known - but not performed by me (I'm an Solaris/X11 blooded 
person since I started with OpenSolaris in 2005/2006). Text mode is nice but I 
personally don't need VBE  text mode for that so I never cared too much since 
it's not my focus.


But else:

Yes: You can run modern 2.21.x or 2.99.x intel_drv.so Xorg ddx's now, those are 
all kms-only since version 2.9 (dated 2010).
This brings you hw accelleration in Xorg and e.g. on Hipster or old OpenSXCE 
(which btw will get its long expected update asap hopefully next month) - on 
Hipster which is the best OpenSolaris distribution of all times by now (yes, I 
take my hat!), you can in vlc now watch raw .MTS files recorded in highest 
bandwidth 50P even on my main x86 machine (which still happens to be a slow 
Sandy Celeron G530 2.4GHz).
With the non-accellerated vesa_drv.so this was unimaginable

Also there is no need anymore to fiddle around with xorg.conf on the OI cd/dvd 
in single user mode and an explicit device line 
BusID   "PCI:0:2:0" to get Xorg up via vesa_drv.so, now autodetection works 
as designed by Xorg and no xorg.conf is required - Xorg will just start (that 
is, as soon as Hipster team adds these bits and brings out a new iso).


compiz should work mostly stable on most Intel 8xx, 9xx and internal GPU Ivy, 
Haswell based systems, no matter if the cpu is a Desktop, Mobile or Server 
variant (DRM/KMS internally distinguishes them and in a few files in the 915 
subdir treats them differently). Sandy (the chips themselves) were known on the 
intel-drm mailing list to have Errata (reported 5 years ago on LinUX) and while 
on Sol11.1++ this isn't reproducable on my Celeron G530, on the backport you 
may run into GPU faults every now and then, especially triggered if you watch 
videos in FireFox  ***in fullscreen***. It took me since last November, but I 
got more stability also on Sandy and now the GPU will silently fail and reset 
the GPU. If it gets really bad than svcadm restart gdm shall be sufficient now, 
no reboot will be necessary on Sandy in most cases. Ivy and Haswell don't 
appear to show this specific instability anyway.

And as said - it wasn't easy to find out what triggered the problems on Sandy.
It turned out that avoiding to watch youtube videos (html or flash plugin 
doesn't make the difference here) in fullscreen, on Sandy.


Well, just test  ;)
I would politely ask users to test and report.
This will be useful for Hipster's official KMS page for this backport:  
https://wiki.openindiana.org/oi/Intel+KMS+driver 







___
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] Mate 1.14

[ken mays via oi-dev]

Set aside some time for a test Live ISO and we can test MATE and all of the 
components.UEFI/BIOS and Intel KMS/DRM are other components to test.~K
 

On Monday, August 1, 2016 1:52 PM, Alexander Pyhalov  wrote:
 

 Alexander Pyhalov писал 01.08.2016 23:43:
>> I have modified version
>> (https://github.com/pyhalov/oi-userland/commit/3108f3427bc2dab346a6c8ca15df30de6210f2bf),
>> which just calls time-admin if it's found (modified more old patch
>> from jds).
>> The issue is that time-admin itself (as part of gnome-system-tools) is
>> gone from Mate.
>> Now they do date and time management using helper in
>> mate-settings-daemon, calls to which are
>> guarded by PoliciKit (which we miss).
> 
> BTW, does someone know why policykit wasn't ported? Was it considered
> needless in presence of proper RBAC?

s/policykit/polkit/g

Messed them up...

BTW, there's polkit in pkgsrc, which seems to build on Solaris/illumos.
---
System Administrator of Southern Federal University Computer Center

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

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

Re: [oi-dev] Wine 1.9.10 : compilation trial

[ken mays via oi-dev]

Ben,
Read this: http://www.dedoimedo.com/games/wine-directx.html



Ken 




On Tuesday, May 24, 2016 12:15 AM, Alexander Pyhalov  wrote:
On 05/24/2016 08:27, benta...@chez.com wrote:
> After a few tests it appears that every 3d stuff do not run.
> I tried a few Windows Application (SumatraPDF, LibreOffice 4.4.2.2,
> other minor application) and when I switched to some DirectX things, it
> crashes with error :
> fixme:ddraw:DirectDrawEnumerateExA flags 0x0006 not handled
> (0) : fatal error C9008: out of memory - malloc failed
> Cg compiler terminated due to fatal error
>
> I tried to install DX9 using winetricks but no luck.
>
> OpenGL works fine on the test machine as glxgear does work and various
> webgl demos on firefox work as well.
>
> I will check if I need to specify some configure switches later on.
> 2D stuff seems ok so far.
>

Yes, last time I've compiled wine on OI it was useless for directx 
games. And why else do you need wine? :)
-- 
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department

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

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

Re: [oi-dev] [OpenIndiana-discuss] OpenIndiana Docs - updated

[ken mays via oi-dev]

Hello,
The 'default' minimal hardware requires  =>768MB RAM. The achieved hardware 
minimum recently with the latest illumos kernel is 48MB RAM (i.e. in CLI mode). 
This was recently achieved by Peter Tribble.

Older recent Live CD distros like Milax required at least 128MB RAM for CLI 
mode and 256MB RAM for desktop mode.
Changes were made for installer purposes, ZFS/LiveCD overhead, etc. You can 
minimize a lot of this.

Sidenote: Just 10-12 years ago, very high-end 3D gaming systems used 2MB RAM 
and high-end computers used 512KB-2MB RAM.
illumos development may give more accurate numbers.
Hope that helps,Ken
 

On Monday, May 16, 2016 5:45 AM, Alexander Pyhalov  wrote:
 

 On 05/16/2016 06:58, Michael Kruger wrote:
> Hello All,
>
> Reporting my progress so nobody gets the idea this little technology
> demonstration project has been abandoned. Far from it, there has been
> continued development.
>
> See it all here: http://makruger.github.io/website/

Some notes:
http://makruger.github.io/website/pages/docs/faq.html:
1) Sun/Oracle’s proprietary OS/NET consolidation has been replaced with 
illumos-gate. => Sun OS/NET consolidation, closed by Oracle, has been 
replaced...  I mean, OS/NET was open until Oracle came;
2) What are the recommended hardware specifications... I'm not sure 
about 4GB... It can be true for desktop/decent server, but you shurely 
can run OI with 2GB RAM or even less. I've just checked, my OI VM with 
GUI has 2 GB RAM... Perhaps, we can distinguish minimal and recommended 
requirements?

http://makruger.github.io/website/pages/docs/handbook.html
Besides synchronizing to Handbook on the wiki, other notes:
1) Booting physical hardware - seems irrelevant, better to provide links 
to illumos HCL and OI community HCL.
2) 2.1.2. Booting Virtual Hardware
No special tricks are required for Virtualbox, just mention to select os 
type Solaris 11 64-bit.
3) 2.2. The OpenIndiana Boot Menu
  You should eventually be presented with a desktop. - irrelevant to 
Text Install images.
4) Perhaps, need to mention that UEFI boot is still not supported.
5) 4.2  When you boot from the text installer, it immediately begins the 
installation process using the previously described Text based Guided 
Install.
Not entirely true, it also can spawn shell and be used as recovery image.

Other general note. If we have to use some documentation tools to write 
OI documentation, they should be available in OI repository. Perhaps 
it's not true for IDEs, but basic tools should be there.
-- 
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department

___
openindiana-discuss mailing list
openindiana-disc...@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

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

Re: [oi-dev] MATE 1.14 Desktop for OpenIndiana

[ken mays via oi-dev]

Anything in /usr/local/libexec/* must go to /usr/local/lib/*
Ok, I'll build resend out a package with those fixes. The individual libexec 
files are executables so you can also test them individually.
~ Ken
 

On Thursday, May 12, 2016 12:01 PM, Till Wegmüller  
wrote:
 

 Hi

with dconf installed i can run some of the applications from a gnome 
session via console. like mate-about

They also spam the same error nikolam mentioned.

Caja does not want to launch. it runs but does not show up the gui

When i modify the xsession desktop file to feature the fullapth, i can 
launch a mate session.

But all the Icons are missing and some applets that require libexec 
helpers do not run.


Greetings

Toasterson


On 12.05.2016 10:07, Nikola M wrote:

> While in GNOME, mate-calc opens and seems to work, even if saying:
> (mate-calc:7503): GLib-GObject-WARNING **: cannot register existing 
> type 'AtkObject'
> ** (mate-calc:7503): CRITICAL **: atk_object_set_name: assertion 
> 'ATK_IS_OBJECT (accessible)' failed)
> but when launced on gnome, caja died:
>  ld.so.1: caja: fatal: libdconf.so.1: open failed: No such file or 
> directory 


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


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

[oi-dev] MATE 1.14 Desktop for OpenIndiana

[ken mays via oi-dev]

 

Hello,
The MATE 1.14 Desktop Environment is the continuation of GNOME 2. It provides 
an intuitive and attractive desktop environment using traditional metaphors for 
Linux and other Unix-like operating systems.
MATE 1.14 Desktop Environment

http://mate-desktop.org/blog/2016-04-08-mate-1-14-released/

About MATE: 
http://mate-desktop.org/blog/2014-02-07-stefano-presents-mate-at-fosdem/
Ref: http://wiki.openindiana.org/oi/MATE+1.14+Desktop
Contributed OpenIndiana MATE 1.14 Binaries: 
http://dlc.openindiana.org/mate-desktop/oi-mate-1.14-desktop-kmays_20160505.tar.xz
Mainly for testing, production use, and development. Comes with all the bells 
and whistles...

Enjoy!,Ken

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

Re: [oi-dev] Gstreamer 1.0

[ken mays via oi-dev]

Hello,
You'll want to test SoX as well at some point.
 Many of the legacy tools like SongBird and Moovida may get affected so we'll 
have to test everything afterwards ordecide to drop them
~ Ken
 

On Saturday, May 7, 2016 9:23 AM, Aurélien Larcher 
 wrote:
 

 



Hi. I think we have to test updating gstreamer before looking at mate, in this 
case we'll have less dependencies to rebuild.
However, integer overflow on 32-bit apps sounds terrible and is a blocker, I 
think we'll have a dozen of issues when try
to rebuild all current multimedia apps to be 64-bit. Also note, that such 
general framework as gstreamer should
be available for both archs.


OK. That's what I wanted to know.

So basically:
- I have now built and installed Pulseaudio 8.0 from Ken's component,
- I will try to fix the 32 bit versions of Gstreamer plugins,
- I will rebuild VLC agains that.

Note that older software like Rhythmbox 0.13.3 is only 0.10 compatible.

 


---
System Administrator of Southern Federal University Computer Center



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



-- 
---
Praise the Caffeine embeddings

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

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

[oi-dev] XDC 2016 - X.org Developer Conference - Sept 21-23 - Helsinki, Finland

[ken mays via oi-dev]

Hello,

Date:
September 21-23, 2016

Location:

Haaga-Helia University of Applied Sciences - Haaga campus is located at 
Pajuniityntie 11, 00320 Helsinki. 

The Haaga campus has approximately 1,100 students and a staff of about 70. 


Registration Cost:
FREE


Host:
Martin Peres - Intel Finland

The 2016 X.Org Developers Conference (3-day event) is the annual technical 
meeting for X Window System and Free Desktop developers. The attendees will 
gather to discuss outstanding technical issues related to the Open Source 
Graphics stack (X, Wayland, Mesa, DRI, ...) and its software ecosystem. The 
event is free of charge and open to the general public.

See:
http://wiki.openindiana.org/oi/XDC+2016
http://www.x.org/wiki/Events/XDC2016/

http://www.x.org/wiki/Events/XDC2015/Program/ (topics usually discussed at 
event)
http://www.x.org/wiki/Events/XDC2015/Program/#Fishel_status_drm_i915_solaris
If you are willing to give a talk at XDC2016 and require travel 

sponsorship, please send an email to board at foundation.x.org (CC: 
martin.peres at free.fr) with an estimate of the travel + accommodation cost 
and the abstract of your talk. Please send your applications as soon as 
possible.

Basic info:
* an extremely short description of what you work on (X11/Mesa/Wayland/graphic 
driver-related projects),
* where you live, and the nearest airport(s),
* how much it would cost to get to the Helsinki Airport (HEL) (please check 
around a
few airlines/websites/etc) -- don't worry about accommodations as they'll sort 
that out.
I'll review a sponsored bus tour to:

* Central Railway Station
* National Museum, Parliament House and Helsinki Music Centre
* Helsinki Olympic Stadium and Tower
* Sibelius monument
* Temppeliaukio Church
* Sokos Department Store
* Senate Square
* Market Square
* Swedish Theatre
* Café Ursula
* Flea Market

* Olympia Terminal

Enjoy,
Ken

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

[oi-dev] Security update: Update to LibreOffice 4.4.7

[ken mays via oi-dev]

Security update: Update to LibreOffice 4.4.7
Location: OI-SFE packaging
LibreOffice is an open source, community-developed office productivity
suite. It includes key desktop applications, such as a word processor, a
spreadsheet, a presentation manager, a formula editor, and a drawing
program. LibreOffice replaces OpenOffice and provides a similar but
enhanced and extended office suite.

It was discovered that LibreOffice did not properly restrict automatic link
updates. By tricking a victim into opening specially crafted documents, an
attacker could possibly use this flaw to disclose contents of files
accessible by the victim. (CVE-2015-4551)
An integer underflow flaw leading to a heap-based buffer overflow when
parsing PrinterSetup data was discovered. By tricking a user into opening a
specially crafted document, an attacker could possibly exploit this flaw to
execute arbitrary code with the privileges of the user opening the file.
(CVE-2015-5212)

An integer overflow flaw, leading to a heap-based buffer overflow, was
found in the way LibreOffice processed certain Microsoft Word .doc files.
By tricking a user into opening a specially crafted Microsoft Word .doc
document, an attacker could possibly use this flaw to execute arbitrary
code with the privileges of the user opening the file. (CVE-2015-5213)
It was discovered that LibreOffice did not properly sanity check bookmark
indexes. By tricking a user into opening a specially crafted document, an
attacker could possibly use this flaw to execute arbitrary code with the
privileges of the user opening the file. (CVE-2015-5214)
All libreoffice users are advised to upgrade to these updated packages,
which contain backported patches to correct these issues.___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

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

[ken mays via oi-dev]

On Monday, December 14, 2015 7:11 PM, Мартин Бохниг  
wrote:
 

 Hi Ken,

did you ever have a look at the hw support matrix of the last ums (aka non-kms) 
Intel 2.6.3->2.9.1  ddx???
It is suited for museum presentations, showing that DRM/DRI was already 
available in the steam/coal age.


For radeon: Sure, but that wasn't even scratched so far.
(and it is complicated/impossible to maintain the same drm submodule for 
different revisions of radeon-drm and intel-drm [must be based on the same 
revision]).
But as OI uses the final ums-radeon ddx and currently has no working modern kms 
based intel-drm, our only solution is to stick with the old stuff you just 
mentioned for the time being, unfortunately  ...


For new GPU's - for now - the only solution continues to be the vesa ddx plus 
the console-resolution change utility.


%martin

--->
Martin,
Yes. I reviewed the HW matrix and also wrote a wiki on Intel GPU tools I 
compiled/ported for OI as it evolves.

The bigger question is if the needed 'kernel source code to fully support 
XServer 1.17.x driver infrastructure' as implemented in Oracle Solaris is made 
publically available - as it relates to fully supporting 'any' 
Intel/Radeon/AMDGPU driver hardware accelerated capabilities and features.
I may have mistaken Randy's XDC 2015 presentation on drm/kms (i915) upstream 
driver support on this effort.See: http://lanyrd.com/2015/xdc2015/sdthhq/
Earlier this year we were going to push out XServer 1.17.x for oi-hipster and 
relax support for the Intel/Radeon drivers.The Nvidia driver works fine for any 
true 2D/3D graphics work. Intel/Radeon open source driver support is still 
'spotty'on Linux.  

Maybe, to move forward and not backward, we could do just that. Push out 
Xserver 1.17.4 and review alternative or unified methods to support 
Intel/Radeon drivers from that point.
Just a thought...

Ken
 



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

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

[ken mays via oi-dev]

Martin,
I'm all for forward movement, but we could review the use of XServer 1.7.7 w/ 
Intel 2.6.3->2.9.1 and Radeon 6.14.6.We know it works for the Intel driver code 
already, so we'd need to add the missing Radeon pieces.
Can use oi_151a9/OpenSXCE or others.
Might help keep legacy alive...?
Ken
 


On Monday, December 14, 2015 2:12 PM, Мартин Бохниг  
wrote:
 

 I forgot to mention, that I'm the only one in the world outside of MS or 
Caldera ('s court trial), who ever found out how it is possible to start the 
DOS32 extender shipped with Win9x/ME as VMM32.vxd on MS-DOS 6.22 and down to 
MS-DOS and (from the same src tree) IBM-DOS 5.00 and even non MS-DOS versions 
like DR-DOS 7 / Caldera OpenDOS, instead of the 16bit MS-DOS 7.00/7.10A/8.00 
still shipped in Win9x/ME (as IO.SYS and the old style MSDOS.SYS plus splash 
bmp then bundled together as IO.SYS [with MSDOS.SYS only being an ascii config 
file]).

I know how to start it on un-MS-messed-with legacy DOS and have a small TSR 
that I wrote, somewhere on one of my douzen old disks.
Somewhere where I also have a copy of the SoftICE debugger and the Win98DDK.

Haha, since 2004 I wanted to release it. One day I will.
This of course only as a nice distraction, because sure we won't incorporate 
this into oi  :)
My version however does not support VFAT (virtual LFN), only 8.3


The only others who ever succeeded in that (but with full VFAT support) were at 
the same time in a legal position to sue MS for a few hundred millions. Which 
they took, for not publishing this TSR:


http://www.it1me.com/learn?s=WinGlue


"Gross also hired Andrew Schulman (who had been, with Geoff Chappell, 
instrumental in identifying the AARD code in 1992) to work as a consultant and, 
in Andover, join Paul in his work on "WinGlue", a secret project to create a 
version of DR-DOS compatible with Windows 95, 98 and 98 SE and replace its 
MS-DOS 7.xx component.[22] This was demonstrated at CeBIT in March 1998,[22] 
and later, in a small team, developed into "WinBolt", both versions of DR-DOS, 
which remained unreleased as of 2014, but played an important role in the court 
case.[18][23]"

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

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

Re: [oi-dev] Thunderbird 38.4.0 integration

[ken mays via oi-dev]

Martin,

Latest Thunderbird 42.x or greater is fine.

Thanks,
Ken___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] Thunderbird 38.4.0 integration

[ken mays via oi-dev]

For those wanting to update to Thunderbird 38.4.0esr, we are now reviewing 
patches for oi-hipster integration:
https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/thunderbird

Source: 
http://ftp.mozilla.org/pub/thunderbird/releases/38.4.0/source/thunderbird-38.4.0.source.tar.bz2

~ Ken 


On Saturday, November 28, 2015 10:52 PM, Nikola M  
wrote:
 

 On 11/28/15 11:47 PM, Bob Friesenhahn wrote:
> On Sat, 28 Nov 2015, Nikola M wrote:
>
>> On 11/28/15 03:24 AM, Мартин Бохниг wrote:
>>> export 
>>> LD_LIBRARY_PATH=/usr/lib/firefox43.0b3/lib/firefox-43.0:$LD_LIBRARY_PATH 
>>>
>>> exec /usr/lib/firefox43.0b3/lib/firefox-43.0/firefox.exe "$@"
>>
>> With this your binary does not dump core on exit ,
>> but somehow shell (bash in gnome-teminal window) from what it is 
>> started, dies when firefox is closed.
>
> Unless you copied these lines into a script, and then executed that, 
> this would be expected behavior since 'exec' would replace the current 
> shell with firefox.

Thanks Bob.


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

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

Re: [oi-dev] FF 43b6 integration

[ken mays via oi-dev]

As for ESR or not ESR...
Due to people's work schedules and relaxation time, we are better off focusing 
on Firefox 43 for the next package release.
Work with the Mozilla enterprise developers and support teams on resolving 
remaining issues ASAP.
No longer provide distro support for Firefox < 43 by end of Y2015.
Thanks,Ken
 


On Saturday, November 28, 2015 7:39 AM, Мартин Бохниг  
wrote:
 

 Hi friends



Суббота, 28 ноября 2015, 13:45 +01:00 от Nikola M :


 On 11/27/15 08:31 PM, Nikola M wrote:
 Hey all if anyone noticed, there is FF 34b7 now on 
http://buildzone.oi-build.r61.net:1000/ userland
 (that I updated passwords form FF24 with resetting 
 signon.importedFromSqlite to default in about:config),


Cool, which src is it based on?




 and with old .mozilla profile I am not experiencing cores on exit anymore.
 Please test 43b7 more to confirm, so it can land to hipster.


Mhh, yes.
Did anyone (of those getting this glitch) test already if the wrapper was the 
silly reason? Or is it a real bug in the cleanup code?
Or maybe the patch Alexander mentioned would be the solution? We must test that 
all.





 -Also there would be nice to have one place (possibly at Martin's Github 
 or similar) where changes for illumos distros for Firefox port could be 
 placed so that now Firefox dev and testing train has been catched up to 
 continue it together.


Whatever you prefer,
>From me sure a +1.
I already thought of this from the beginning, and that's why there are subdirs 
for each distro in 
https://github.com/OpenSXCE-org/FireFox-43-port-for-all-OpenSolaris-distros/tree/master/oracle-userland-integration

(The DilOS subdir is still  empty, but if Igor has more time he and who-ever 
wants can get rw access.)
Must first check, though, how this is done on github or if bitbucked is better 
for our intended development model. Saw a few summaries last week, but first 
need to re-read them. Or probably many of you can already tell me the answer in 
1 sec. So I'm certainly open for suggestions.





 -I also propose to put thanks to Martin in Firefox in OI hipster 
 Help:about box ,
 under Firefox logo (not over it) , with text that one to thank for it is 
 Martin and it's Paypal mail address.
 It cold be there for a while and I think it is good idea.


This is a very kind proposal.
But I fear I cannot accept it.
Then also Alexander's name needed to be in every [About] box, and then maybe 1 
million others'names.


I need to take a full-day job as UNIX admin.
Problem in Berlin is only: No industry, no Solaris. And those few organizations 
who are still running Solaris in the de-industrialized East are most likely 
"such" ones which would __never__ __ever__ hire me.

But that's another dilemma.
I cannot stay in this damn country that this has become during the past 25 
years, which was my home country until 1989.
But such a donation button only for me would be unfair to others.
If you keep a small copy of my name somewhere in the FF About icon (without 
donation requests), then this would already be more than enough of an honor to 
me.


And: Don't forget to add Alexander also.
The core contributor system in OpenSolaris wasn't that bad actually.
Maybe we shall honor those who contribute by giving them contri and core contri 
status.
And this will be much more fair to _all_ contributors, depending on what and 
how much they contributed.

I think there are at least 10 persons here which deserve such credits right 
away.



TNX!




rgds.
   %martin



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

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

Re: [oi-dev] FF 43b6 integration

[ken mays via oi-dev]

We agreed that we could move to FF 43.x (now version 43.0b7 today) to resolve 
many rendering issues and migrate to the next ESR release or provide an 
additional package of the current 38.4.0 ESR release. 


Usually, if you need an older browser you can uninstall a current browser and 
install the old one (or place it in another directory - which I've done for 
years). The Oracle provided browser releases allows users to go back and do 
this (or we can support specific FF releases in IPS).

So technically, we could push forward with FF 43b7 today and then provide a FF 
38.4.0esr package as well for those
users that need/want it (as we do something similar with GCC or NVIDIA 
packaging).

The other issues like migration issues is something we document to alleviate 
those issues with developer support teams. This is standard software porting 
practice.

That way, you CAN still have your cake - while just eating some of it too!

We can then focus on updating our video/input drivers before end of year

Thanks,
Ken









On Friday, November 27, 2015 6:26 AM, Aurélien Larcher 
 wrote:



Hi,
I vote for integration as there is no critical regression, while on the other 
side security issues are addressed and broader testing is important.

On Debian stable and testing, in the past months, I have seen Iceweasel behave 
equally bad regarding Flash and crashes on exit (leading to zombified process), 
the same applies to Icedove for the latter issue.
This is not a justification, of course, but considering our resources, until we 
reach a stage when a release schedule is possible, consolidating oi-userland 
and facilitating testing (when no critical regression exists) should be a 
priority.

In an ideal time-unlimited world I would of course otherwise agree with Nikola. 
;)
He makes a valid point though about taking care of keeping /dev -> /hipster 
upgrades possible.

Best regards,

Aurelien




On Thu, Nov 26, 2015 at 8:33 PM, Alexander Pyhalov  wrote:

Hello.
>I'd like to ask for your opinions. Thanks to Martin we have new FF version 
>(https://github.com/pyhalov/oi-userland/tree/firefox/components/firefox).
>
>There is one issue with new version:
>- first of all, plugin wrapper sometimes crashes with Adobe Flash Player 10, 
>it's not random, it crashes on some specific applications and operations,
>and it's a regression.
>
>However, it's much more recent and has a lot of security fixes compared to our 
>FF. Also a lot of sites require fresh FF. Google docs started complaining
>about our FF version. I've tested icedtea plugin and it works with new FF. 
>Also Adobe Flash player 10 works with a lot of flash applications.
>Shumway is supported by new FF, but it's not ideal, a lot of sites are not 
>supported. BTW, I've seen that several sites switched from flash to HTML5
>players with new FF.
>
>So, the question is, should we update default OI Hipster FF to this version? 
>I'd say yes. What do you think?
>
>-- 
>System Administrator of Southern Federal University Computer Center
>
>___
>oi-dev mailing list
>oi-dev@openindiana.org
>http://openindiana.org/mailman/listinfo/oi-dev
>


-- 

---
Praise the Caffeine embeddings


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

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

Re: [oi-dev] FF 43b6 integration

[ken mays via oi-dev]

Hello,
Yes.
As for any plugin wrapper issues with Flash:
The industry giants are pushing away from any 'official' Flash support in 
browsers and the legacy Flash pluginsfor Solaris are now a potential security 
risk. This means any Flash plugin <= 11.2.x.x is now under UNOFFICIAL or 
FORBIDDEN (aka use only with care) use status when used on any 
Solaris/OpenSolaris-related OS platform during Internet use - especially in any 
business or academic environment.
Thanks,Ken

 


On Thursday, November 26, 2015 11:33 AM, Alexander Pyhalov  
wrote:
 

 Hello.
I'd like to ask for your opinions. Thanks to Martin we have new FF 
version 
(https://github.com/pyhalov/oi-userland/tree/firefox/components/firefox).

There is one issue with new version:
- first of all, plugin wrapper sometimes crashes with Adobe Flash Player 
10, it's not random, it crashes on some specific applications and 
operations,
and it's a regression.

However, it's much more recent and has a lot of security fixes compared 
to our FF. Also a lot of sites require fresh FF. Google docs started 
complaining
about our FF version. I've tested icedtea plugin and it works with new 
FF. Also Adobe Flash player 10 works with a lot of flash applications.
Shumway is supported by new FF, but it's not ideal, a lot of sites are 
not supported. BTW, I've seen that several sites switched from flash to 
HTML5
players with new FF.

So, the question is, should we update default OI Hipster FF to this 
version? I'd say yes. What do you think?

-- 
System Administrator of Southern Federal University Computer Center

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


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

[oi-dev] Security awareness: Update to Firefox 38.2.1 ESR or greater

[ken mays via oi-dev]

URL: http://ftp.mozilla.org/pub/firefox/releases/38.2.1esr/contrib/
Mozilla Firefox is an open source web browser. XULRunner provides the XUL
Runtime environment for Mozilla Firefox.

A flaw was found in the processing of malformed web content. A web page
containing malicious content could cause Firefox to crash or, potentially,
execute arbitrary code with the privileges of the user running Firefox.
(CVE-2015-4497)

A flaw was found in the way Firefox handled installation of add-ons.
An attacker could use this flaw to bypass the add-on installation prompt,
and trick the user into installing an add-on from a malicious source.
(CVE-2015-4498)

All Firefox users should upgrade to Firefox version 38.2.1 ESR or greater, 
whichcorrects these issues. After installing the update, Firefox must be 
restartedfor the changes to take effect.
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] ext2 on OI Hipster 20151003 follow-up

[ken mays via oi-dev]

Actually,Use the precompiled 64-bit code from the main site which is 2015.3.14. 
From there, you can use ext2 driver (or update it).You can read/write ext2/3/4.
http://jp-andre.pagesperso-orange.fr/openindiana-ntfs-3g.html
You can usually contact Jean-Pierre on any issues.
~ Ken

 


 On Monday, October 12, 2015 10:09 AM, Bruce Lilly  
wrote:
   

 NTFS wouldn't be practical for me; it is a "foreign" filesystem as far
as all of the installed OSes
are concerned.  Changing file modes would be a considerable problem,
and then there are
issues of mapping user and group IDs and possibly modification time,
not to mention tools
availability (fsck, etc.).  FAT also wouldn't work as it doesn't
support chmod, etc.

The 8-character mount probable-bug is disconcerting.  Even more so is
that the wiki page
listing source repositories (
http://wiki.openindiana.org/oi/Source+Repositories ) appears to be
quite out-of-date, so even if it were possible to easily find the
source there, it might not be
what's actually used.  Therefore I gave up trying to look (ever wonder
why there are so few
developers working on OI...?).

On Mon, Oct 12, 2015 at 6:51 AM, Nikolam  wrote:
> FUSE works right on Openindiana /hipster-2015, I installed it with with NTFS
> support from:
> http://jp-andre.pagesperso-orange.fr/openindiana-ntfs-3g.html
> I mount my NTFS partition in OI just right,
> only bug I see is that files copied from Ntfs partition are all marked
> executable when copied.
> If it could be used with ext2/3(4?) read-only, (if fs name is 8 characters
> ;))  that would be great.
>
> If FUSE and Ntfs is also included in OI repositories, that would be also
> more great.
>
> On Mon, Oct 12, 2015 at 6:12 AM, Bruce Lilly  wrote:
>>
>> Ken Mays kindly suggested using fuse from SFE and/or ntfs-3G.
>>
>> Fuse didn't work because of what looks like a bug in /sbin/mount:
>>
>> # mount -F fuse-ext2 /dev/dsk/c2t0d0p7 /mnt
>> mount: FSType fuse-ext2 exceeds 8 characters
>>
>> "fuse-ext2", the name of the fuse module for ext2 is indeed 9 characters
>> long.
>> Why /sbin/mount should have a problem with that is another matter.
>> The mount(1M) manual page, which has a recent date but doesn't look quite
>> like the usual illumos/openindiana man pages, gives no clue, but it
>> mentions
>> the man page mnttab(4).
>> The mnttab(4) man page also provides no insight, but refers to
>> /usr/include/sys/mntio.h.
>> With appropriate packages installed, /usr/include/sys/mntio.h shows
>> character
>> array mtl_fstype sized _ST_FSTYPSZ.
>> _ST_FSTYPSZ is defined in /usr/include/sys/stat.h as 16.
>> /sbin/mount has a compiled-in string "%s: FSType %s exceeds %d
>> characters".
>> So if mount is using something less than _ST_FSTYPSZ-1, what is it using
>> (evidently something that evaluates to 8) and why?
>>
>> This is apparently an old issue; it also shows up on a system running
>> oi_151a9.
>>
>> ntfs-3G might or might not have a more recent fuse driver, but no ext2
>> support per se,
>> so wouldn't help with this problem.
>>
>> This, incidentally, is on a triple-boot laptop which also has NetBSD 7.0
>> and
>> openSUSE 13.1 Linux installed (both with native ext2 support) and both
>> mounting
>> 5 ext2 data partitions in peaceful coexistence.
>>
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> http://openindiana.org/mailman/listinfo/oi-dev
>
>
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

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


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

Re: [oi-dev] nawk and awk

[ken mays via oi-dev]

Hi,
pkg install system/extended-system-utilitiespkg install text/gawk
~ Ken 


 On Sunday, October 11, 2015 1:02 PM, Peter Tribble 
 wrote:
   

 

On Sun, Oct 11, 2015 at 8:41 PM, G B via oi-dev  wrote:

What are the versions of nawk and awk in 1003 OI Hipster?

Whatever the version of illumos it was built from.
 Something like

mcs -p /usr/bin/awk

should give the illumos build the command matches.


# pkg search '\*/usr/bin/nawk'

Try

pkg search nawk

or

pkg search /usr/bin/nawk

(Basically, either the last component, or full pathname.)
 
# pkg contents -o pkg.name,path -a ='\*/usr/bin/nawk'

That would be

pkg contents -o pkg.name,path -a path=usr/bin/nawk

(note, without the leading / this time)
 
None of them return a package.  Also 'awk --version' or 'nawk --version' 
doesn't retrun anything.

That's because illumos has its own awk and nawk, rather than gawk.

(Unfortunately, the regular illumos awk - the one in /usr/bin/awk - is
pretty terrible, and best avoided.) 

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

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

Re: [oi-dev] Recent /dev a9 repository ?

[ken mays via oi-dev]

Udo,
Tribblix m15 is also built from oi_151a9. You may want to look at it to see how 
it was built as well as the resulting distro.
Ken
 


 On Wednesday, June 24, 2015 8:20 AM, Udo Grabowski (IMK) 
 wrote:
   

 Summary of what I've achieved up to now:

  - No, there are no torrentz outside, all you get
    are ad- and malware installers for MS-Doses, so
    just stay away from this harmful stuff (esp. if
    you have a Dose!)

Indeed, my starting point was a way too old StudioExpress
developer 12.0 special release with DLight which was not easily
"up-patchable" to the desired point.

Instead, I've found this: StudioExpress-sol-x86-2009-03-ii.sh,
which is very near the desired patchpoint, but differs from the
original "kernel-build" Studio in having, e.g., a few newer patches for
libsunperf and the like. I then extensively studied Oracles patch
matrices and tested them out to find out that these specific 5
patches are needed to get the C/C++ (yes, there's C++ needed for
the kernel build!) environment very close to the required one:

124864-12 124868-10 124873-07 126496-04 126498-13
(a premium support account for anything suffices to access these)

With these patches, most of the essential stuff has the correct
md5sums. Using ./nightly.sh illumos.sh production with SUN cc/CC
and no shadow gcc, I'm now able to reproduce the exact drivers
for mpt_sas, mr_sas, bge, and a couple of others. My earlier observation
that I only could produce mpt and some other ones was a red herring
since they are not compiled at all, but come from the closed-bins.
in fact, the objects shouldn't have the exact size and md5sums, since the
date is left in the .comment section (see mcs -p file), so you have to
delete (mcs -d file) this before actually comparing files.
On some others I still see differences (e.g.,mc-amd) in file size,
but the disassemblies are exactly the same, elfdump shows only differences
in e_shoff and some sh_offset entries by a couple of bytes, so I suspect
that one of these has different section alignments. I don't know if
this is a problem, but up to know I'm only planning to use those
drivers for which I can reproduce the exact oi object, hoping that
this is qualification enough to trust an updated version of that
driver.

What still absolutely puzzles me is that the dis command of
the host and that of the build zone (which is the same OS version)
give different output, although the command as well as all
dynamical linked libraries are exactly the same ! This caused
a lot of confusion since first I "dissed" on both and could not
prove equality. I still have no explanation for that (maybe it reads
something elsewhere), but only dis-ing on one circumvents that problem.
So I conclude that maybe the build environment contributes to the
remaining differences I see in the drivers.

Thanks for help so far !

On 19/06/2015 23:25, Jon Tibble wrote:
> Yeah, you've got different and missing binaries:
>
> --- mystudiomd5sums    2015-06-19 22:23:26.507840266 +0100
> +++ udostudiomd5sums    2015-06-19 22:20:02.514366537 +0100
> @@ -1,9 +1,9 @@
> -3265b6e5fea71b80d802b839a6271449  prod/bin/amd64/dbx
> -f3406e01f03dc70dda6111d937d7d147  prod/bin/amd64/dwarfdump
> -57b45df2b1c768089c91c96beccd8444  prod/bin/amd64/er_kernel
> +291efba7feafa0e0c7a4392a962a8c54  prod/bin/amd64/dbx
> +bce85c779015f30de1f649b13e983a93  prod/bin/amd64/dwarfdump
> +15cf5bc6d15504c2bcef6c6d06e69137  prod/bin/amd64/er_kernel
>    d38e359e98294eeac936db6fe68f9190  prod/bin/cc
> -11a514e2911a1cf950957f2ae1d9fe6e  prod/bin/ube
> -9a56841058b0eda6e34e8659f27eb3f7  prod/bin/fbe
> +a8ffc00586be7b3a04195fe2fe4e987c  prod/bin/ube
> +166eaf57e5d21b0ecb98b9336cd73609  prod/bin/fbe
>    ac781f9bdd73518794e5ca769c8c3ce6  prod/lib/CCrti.o
>    6d9a62efc4293a9fb58a11fa9227e63e  prod/lib/CCrtn.o
>    5ff76c1ea546050bc0500564ff054727  prod/lib/bb_link.o
> @@ -19,51 +19,46 @@
>    e7ae10ad47dc9776de4bac6a22f3e346  prod/lib/prof_func.o
>    1b5404db7308f056fe7417ebec2d73ce  prod/lib/prof_lib.o
>    70d444bcf05aca11558a97a1980aab77  prod/lib/prof_tsd.o
> -db9774ca4cb8eec3232641abb1a999fa  prod/lib/unsync_stdio.o
> +8662a745747d517e0e3dda5edb3cf2b4  prod/lib/unsync_stdio.o
>    e5af76c4530a8b62e240347b2ec4169e  prod/lib/values-xa.o
>    9320085eaf289a0e13c94165ca728e16  prod/lib/values-xc.o
>    77bb70c1ce724aeef4f2be283183af9e  prod/lib/values-xi.o
>    df89f1ce3fc7addd9bc93974a8035165  prod/lib/values-xpg4.o
>    5054a233497141647f1464bae5f3c959  prod/lib/values-xs.o
>    1b27c9bcd1ec74f2c45a7e2f292ffc09  prod/lib/values-xt.o
> -ba40d52e5565b76294597c7c2e4b43e1  prod/lib/libCrun.a
> -c46f2d60125b347c7acbdaaf55ddadc2  prod/lib/libCstd.a
> -62e3e8451de16f9fef09aa2d00ab0d21  prod/lib/libCsunimath.a
> -d7aa4ff11fb0d2195255ac5e1d13b050  prod/lib/libCsunimathios.a
> -3beb221642e72ac5baa2056de7b70ebe  prod/lib/libcplxsupp.a
> -4b128e3c1a42bb8bc6f3c8d8287ff1db  prod/lib/libdemangle.a
> -67513c6fdadf246b4f659fce04e02e52  prod/lib/libfai.a
> -b1badd7d564c37c2047168d14cc1

Re: [oi-dev] [oi-userland] update cmake to 2.8.12.2 (#1242)

[ken mays via oi-dev]

Aurelien,
Does "was broken for swig and delivered by Debian without testing which broke 
our finite element library." still apply?
Ken
 


 On Tuesday, June 9, 2015 6:45 AM, Aurélien Larcher 
 wrote:
   

 Also, actually 3.1 is safe.

On Tue, Jun 9, 2015 at 3:44 PM, Aurélien Larcher  
wrote:

I had the patchset in my branch for several weeks but did not merge it because 
of test failures, did you fix the them ?
Best

Aurelien


-- Forwarded message --
From: jeffpc 
Date: Tue, Jun 9, 2015 at 3:30 PM
Subject: [oi-userland] update cmake to 2.8.12.2 (#1242)
To: OpenIndiana/oi-userland 



You can view, comment on, or merge this pull request online at:
  https://github.com/OpenIndiana/oi-userland/pull/1242
Commit Summary
   
   - update cmake to 2.8.12.2

File Changes
   
   -  M components/cmake/Makefile (4) 
   -  M components/cmake/cmake.p5m (8) 
   -  M components/cmake/patches/cmake-2.8.6.patch (180) 
   -  A components/cmake/patches/demangle.patch (19) 

Patch Links:
   
   - https://github.com/OpenIndiana/oi-userland/pull/1242.patch
   - https://github.com/OpenIndiana/oi-userland/pull/1242.diff
—
Reply to this email directly or view it on GitHub.   


-- 
---
LARCHER Aurélien      | KTH, School of Computer Science and Communication
Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 Stockholm, SWEDEN
---




-- 
---
LARCHER Aurélien      | KTH, School of Computer Science and Communication
Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 Stockholm, SWEDEN
---

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

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

Re: [oi-dev] What happened to hipster-2014 repo? Who is who in OI?

[ken mays via oi-dev]

Who is who is OI?
A. For the contributors and 'staff' members past involvements, see:Human 
Resources - OpenIndiana - OpenIndiana Wiki

|   |
|   |   |   |   |   |
| Human Resources - OpenIndiana - OpenIndiana WikiName IRC Nickname Email 
Address Website Brief Blurb Alasdair Lumsden Alasdairrr alasdairrr at gmail   
Project Founder Kevin J. Woolley kjwcode kjw at pathillogical.com  
http://www.pathillogical.com/  |
|  |
| View on wiki.openindiana.org | Preview by Yahoo |
|  |
|   |

 



 On Friday, May 22, 2015 4:08 AM, Nikola M  wrote:
   

 

On 05/22/15 12:26 PM, Nikola M wrote:
> Hi,
> I would like to know where is hipster-2014 repo?
> Who deleted it (was it using too much space?) and who is managing OI 
> infastructure, anyway?
>
> I would also like to know who is ATM available inside OI for various 
> duties,
> who does what and who is doing what.
> That is main people infrastructure of people and that is the info i 
> was always missing in OI to know what is going on.
> (And to be able to move it further)
>
> Nikola M.
>

To respond to myself, after /hipster , there were /hipster-2014.1 repo 
(and now /hipster-2015).
(I used it but I forgot.. :,)

But qwestion about "who is who in OI" stays.
It is always good thing to know who is managing what and who to contact 
for what and for inclusion of new people.



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


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

Re: [oi-dev] drm

[ken mays via oi-dev]

Alex,
drm.bz2 and i915.bz2 relate to:kernel/misc/amd64/drm - new 64-bit kernel DRM 
APIkernel/drv/amd64/i915 - new test Intel DRM for Intel 2.99.917 driver testing
Should support all Intel GMA 900->Haswell GPUs.
Mainly for testing the Intel driver for now with Hipster 20150330 and above.~Ken


 



 On Saturday, April 11, 2015 11:07 AM, Alexander Pyhalov  
wrote:
   

 Hi.
What are  drm.bz2 and i915.bz2 files attached to 
https://www.illumos.org/issues/5637 ?

-- 
System Administrator of Southern Federal University Computer Center

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


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

Re: [oi-dev] [HEADSUP] X server update in OpenIndiana Hipster

[ken mays via oi-dev]

Jean-Pierre,
Power Mgt in BIOS
1. pfexec pkg install system/pciutils@3.2.0,5.11-2014.0.1.0:20140528T080827Z2. 
Use setpci -s "" F4.B=## (where ## is BB=light, 77=med)
Usually you can get the function keys on your laptop to do this if programmed 
correctly (BIOS).
I set up VESA using 1280x1024 and 1920x1080 so it'll work if your setup allows 
it.
Thanks,Ken
 

 On Thursday, March 5, 2015 3:32 AM, Jean-Pierre André 
 wrote:
   

 Hi Nikola,

Nikola M wrote:
>
> On 03/ 3/15 04:31 PM, Jean-Pierre André wrote:
>> Hi Ken,
>>
>> ken mays via oi-dev wrote:
>>> Hello,
>>>
>>> The lockdown (pkg freeze) is needed mainly on the XServer and Intel
>>> driver.
>>> You need to maintain Intel driver's 2.6.3 or 2.9.1 for XServer 1.7.7.
>>
>> I assume you mean Intel driver 2.9.1 is compatible with
>> current Xorg server 1.7.7, but where is it to be found ?
>>
>> The latest hipster ships with 2.99.917 (not compatible
>> with Xorg) and older one shipped with 2.6.3 (probably
>> not compatible with my hardware). An intermediate
>> version compatible with both Xorg server and hardware
>> would be nice...
>
> Hi Jean-Pierre,
>
> Could you please also state what is your hardware, brand, model,
> configuration and grahics card/integrated graphics model (included in
> motherboard, chipset or inside cpu).

scanpci shows :

pci bus 0x cardnum 0x02 function 0x00: vendor 0x8086 device 0x0116
  Intel Corporation 2nd Generation Core Processor Family Integrated 
Graphics Controller
  CardVendor 0x103c card 0x1894 (Hewlett-Packard Company, Card unknown)

On Windows 7 the card is displayed as "Intel(R) HD Graphics 3000"

Note : https://www.illumos.org/issues/5670 (from Ken) mentions
"Intel HD Graphics: 2000-6000" to be supported by the Intel
driver not ported to OI, which gives hope for the future.

Xorg.0.log shows on Hipster (any 2014 versions) :

(II) Module intel: vendor="X.Org Foundation"
        compiled for 1.7.7, module version = 2.6.3
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 6.0
(II) LoadModule: "vesa"
(II) Loading /usr/lib/xorg/modules/drivers/amd64/vesa_drv.so
(II) Module vesa: vendor="X.Org Foundation"
        compiled for 1.7.7, module version = 2.3.0
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 6.0
...
(II) UnloadModule: "intel"
(II) Unloading /usr/lib/xorg/modules/drivers/amd64/intel_drv.so

So Xorg tries to use the Intel driver 2.6.3 and gives up.
The vesa driver is used instead, which is not bad (I need
no 3D). The only problem is that I cannot adjust the
brightness, and maximum brightness is unbearable, hence
my initial question.

>
> How it behaves in hipster-2014.1 and maybe booting from live 20141010
> DVD/USB?

Same result (no surprise, this is the same driver
and same xorg server).

> Idea of freezing X and intel driver is if you freeze it in a working
> state, before one updates rest of the system to hipster-2015 for testing
> for new bugs. (Works for me for older intel graphics, e.g. 945)

I also tested hipster 2015. The Intel driver fails
because of undefined symbol RegionEmptyData. This is
probably the signature of Xorg server being incompatible
with Intel driver 99.99.917

> If also in hipster-2014.1 you do not have your graphics working
> correctly (explain how it works, does it display with low
> resolution/VESA or something) you can then try installing/booting from
> live DVDs of older Openindiana /dev and Hipster release DVDs.

Unfortunately this computer is not old enough (about
two years and a half), and it has always fallen back
to using the vesa driver. This appears to just be
caused by an unsupported graphic model.

I have also tried to configure /etc/X11/xorg.conf to
reject the vesa driver. This has only led to having no
graphics at all.

> If with no previous release it worked for you, see that you report a bug
> on it, too.
> https://www.illumos.org/projects/openindiana/issues

The conclusion will be to wait for the new Xorg
server...

Ken mentioned an Intel driver 2.9.1 which I could test
if I found it somewhere.

For now, having a way to adjust the brightness through
the vesa driver would be enough.

Jean-Pierre



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

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

Re: [oi-dev] [HEADSUP] X server update in OpenIndiana Hipster

[ken mays via oi-dev]

Hello,
The lockdown (pkg freeze) is needed mainly on the XServer and Intel driver.You 
need to maintain Intel driver's 2.6.3 or 2.9.1 for XServer 1.7.7.
If you've updated to hipster-2014.1, you've done well enough.
Thanks,Ken

 

 On Monday, March 2, 2015 6:43 AM, Nikola M  wrote:
   

 
On 02/28/15 04:22 PM, Jean-Pierre André wrote:
> Hi Alexander,
>
> Alexander Pyhalov wrote:
> [...]
>> I think we can look at downgrading
>> intel drivers to something like 2.9 (or even 2.6) which still supported
>> UMS until KMS work is ready. I don't know how much work it'll take to
>> make this crap work with new Xorg server, so no promises on time frame
>> for now. Until then you can use vesa.
>
> I have a computer with Intel graphics and Hipster
> 20140701 installed. Xorg refuses to use intel_drv.so
> and falls back on using vesa_drv.so, I understand
> this is not going to improve soon.
>
> The fall back to vesa is totally unusable because the
> brigthness is forced to maximum and hurts the eyes and
> the slider for brightness on "Power Management" has no
> effect.
>
> Is there another way to adjust the brightness level with
> the vesa driver ?
>
> Jean-Pierre
Hello, Jean-Pierre,

I found a workaround that could be used, if everyone declares that newer 
packages in hipster-2015
will not depend on newer X and Intel driver that is non working yet. 
(and that could allow testing if it is needed when things improve.

You update to latest hipster-2014.1 or install from 20141010 ISO if it 
is new install,
or in a working BE for your intel hardware,
and you enter: (with pfexec or sudo)
pfexec pkg freeze consolidation/X/X-incorporation
pfexec pkg freeze x11/server/xorg/driver/xorg-video-intel

And then add new repository (pkg set-publisher-g , -G to remove old) if 
needed, and update (pkg update -v).

That way , if new packages you have installed does not depend on newer X 
and intel driver that does not work, you get same packages as 
hipster-2015 except X and intel driver consolidations.
And hopefully newer packages won't depend on them, until it is once 
solved in illumos and you unfreeze them.


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

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

Re: [oi-dev] [HEADSUP] X server update in OpenIndiana Hipster

[ken mays via oi-dev]

No, we didn't. You'll see that it was all worth it. Ingenuity is risky business 
- just own it, and embrace it.Either breathe fire or blow smoke signals - or 
stand still.
~K
 

 On Tuesday, February 24, 2015 2:04 AM, Alexander Pyhalov  
wrote:
   

 On 02/24/2015 12:51, ken mays via oi-dev wrote:
> Nikola,
>
>  On Tuesday, February 24, 2015 12:03 AM, Nikola M  wrote:
>
>  On 02/24/15 01:18 AM, ken mays via oi-dev wrote:
>
>    Nikolai,

Nikola, Ken.

This time we seriously fucked up with intel drivers. Sorry, but I didn't 
have intel video adapter and couldn't test it. Intel 2.9.1 driver wasn't 
working with new Xorg, so I updated it to 2.18, which is what is in 
XstreamOS and hoped that if it worked for them, it could work for us. 
Unfortunately, it wasn't true. I understand that KMS work will not land 
to illumos-gate in the nearest time. I think we can look at downgrading 
intel drivers to something like 2.9 (or even 2.6) which still supported 
UMS until KMS work is ready. I don't know how much work it'll take to 
make this crap work with new Xorg server, so no promises on time frame 
for now. Until then you can use vesa.
-- 
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department

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


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

Re: [oi-dev] [HEADSUP] X server update in OpenIndiana Hipster

[ken mays via oi-dev]

Nikola,

 On Tuesday, February 24, 2015 12:03 AM, Nikola M  wrote:
  
 On 02/24/15 01:18 AM, ken mays via oi-dev wrote:
  
  Nikolai, 
   
 Hi, my name is Nikola (without 'i') ;)
 
  As far as Intel DRM work for illumos, that is proposed for GSoC 2015 
development which ends Q4 2015.  
 It is great to know. 
 It is then unknown what people with Intel graphics will do with their 
hardware, that want to install on and test Hipster in meantime?
 Also removing support for older graphics is never discussed anywhere as I know 
(we were just hit by update and people started reporting disastrous effects to 
their desktops). It is just done without asking.
 Maybe reconsider of leaving supported Xorg and drivers in their place or with 
an old/new name so it could be auto recognized and used?
 
  
 > They can use previous releases. There are many times when a new OS 
release drops support for previous hardware (or software) - without much 
forewarning to existing customers. But, we actually did mention it and it is 
mentioned if you follow the X release notes (and previous implementations and 
updates of Solaris X implementations and blogs/news/articles). There was a five 
year history to this discussion of moving to a newer X infrastructure for OI. 
You can only boil an egg so long before it cracks...

 As far as Martin, there is Martin's OpenSXCE distro. He currently mentioned a 
new release.  
 
 There's no source code that follows OpenSXCE releases, correct me if I am 
wrong.
 
---> Martin mentioned he'd provide source code to his supporters. This is 
mentioned on his distro release and was in a previous blog. Also, some of his 
work pulled from existing consolidation source models. Just ask him what his 
current process is if you want it.
 
  Also, there is Tribblix. Both distros are desktop-centric and support older 
Intel GPU chipsets (but not the newer ones). There is still the 
Hipster-20141010 ISO release you use today. 
   
 
 So you suggest moving from OI Hipster to other distro if wanting to continue 
using existing hardware?
 
---> No, we'd like for you to stay. But, I do mention similar alternatives that 
may meet your needs today or use of the officially provided OI 'releases'. 
 It is funny to call Hipster ISOs - releases, because it could be said that 
then publishers that are installed with them could receive updates and support?
 Which I am not sure it right, because actual reason ISOs and freezes of 
Hipster exist is because Hipster re-build all packages all the time and because 
updating takes longer and longer, there is need for starting from blank history 
of updates, so that installing packages dont' consume so much RAM and takes so 
long, not tend to give support?
 Also ISOs are there in Hipster to be able to install it on bare metal/hardware 
, because updating from /dev to Hipster last time worked almost 2 years ago and 
no one actually care to have release that could update from /dev.
 
---> There is no official release yet. The lead release manager usually tests 
migration to the latest ISO release and backward compatibility. But that is due 
to workload and volunteer resources available to handle that. 
  
  As far as Hipster, there are the supported ISO releases. The Hipster-2015 IPS 
repo is a moving target (considered 'dev', bleeding edge, or 'hair on fire' 
development) not for general production or day-to-day operations. There are 
other snapshots that may produce 'tested' package releases - which is really 
what you are discussing. True development releases are never for the general 
public (aka users) - if untested by 'QA'.  
 
 We need then something that actually IS for end users as a product of an 
effort.
 Hipster is not that kind of product, and yes, there is need for tested product.
 
 As I used Hipster for exactly everyday work for a long time (and reported all 
bugs I could on IRC and lists) , I must confess I have seen accumulation of 
bugs without fixing.
 Is it better "updating everything and not caring for introduced bugs" or "have 
working  AND development releases separate from each other", with clear intent 
that updates work - is maybe better solution?
 
 
  
  If you are tracking new releases from Hipster Dev which happens to plunge 
your desktop environment into a dark abyss, remember the rule: Either press the 
panic button or don't do it!!!  
 That would not be the case IF Hipster would have "entire" package numbered on 
every update,
 so that user can update to specific point in time in Hipster updates, 
 to debug what change break what already working function of an OS.
 You always get "latest" Hipster , with no way of turning a step back and think 
if update was introducing more bugs of fixing existing ones.
 
With Boot Environments on top of ZFS, we using and testing OI have best 
possible solutions for testin

Re: [oi-dev] [HEADSUP] X server update in OpenIndiana Hipster

[ken mays via oi-dev]

Nikolai,
As far as Intel DRM work for illumos, that is proposed for GSoC 2015 
development which ends Q4 2015.
As far as Martin, there is Martin's OpenSXCE distro. He currently mentioned a 
new release.Also, there is Tribblix. Both distros are desktop-centric and 
support older Intel GPU chipsets (but not the newer ones). There is still the 
Hipster-20141010 ISO release you use today. 
As far as Hipster, there are the supported ISO releases. The Hipster-2015 IPS 
repo is a moving target (considered 'dev', bleeding edge, or 'hair on fire' 
development) not for general production or day-to-day operations. There are 
other snapshots that may produce 'tested' package releases - which is really 
what you are discussing. True development releases are never for the general 
public (aka users) - if untested by 'QA'.
If you are tracking new releases from Hipster Dev which happens to plunge your 
desktop environment into a dark abyss, remember the rule: Either press the 
panic button or don't do it!!!
The drop of support for the older Intel driver is by design of the newer X 
infrastructure - not us. We are moving to the newer Xorg Intel driver(s) and 
when Intel DRM for illumos is in place - we will strike the iron while hot... 
~ Ken 

 On Monday, February 23, 2015 10:58 AM, Nikola M  wrote:
   

 
On 02/22/15 05:56 PM, Alexander Pyhalov wrote:
> Hi.
> Unfortunately, we hit an issue, when older Intel video drivers don't 
> compile with newer Xorg and newer one require DRM update.
> Until kernel drm work is done vesa driver can be used with Intel chips.
> This sounds awful, but I don't have better sollution now.
>
> https://www.illumos.org/issues/5637

Is there any time frame for DRM update , anyone doing work on this also 
on other illumos desktop distros or we are looking at the dark here?

If issue was known prior to updates, could it be considered to have 
other (older) Xorg packages as current workaround? (And maybe 
auto-selected during update from 20141010 if problem with Intel graphics 
is already known ?)

Intel graphics could be considered as very huge user base problem for 
anyone trying to install Hipster then, I can suppose this can only turn 
more people off.
As I am not to be expected to use OI Hipster for everyday tasks on my 
hardware with current state of drivers, but could keep updating BE and 
try debugging and testing whenever asked.


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


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

Re: [oi-dev] [HEADSUP] X server update in OpenIndiana Hipster

[ken mays via oi-dev]

Hello,
Try: xrandr | grep maximum
Thanks,Ken
 

 On Sunday, February 22, 2015 7:49 AM, Nikola M  wrote:
   

 On 02/15/15 05:13 AM, Alexander Pyhalov wrote:
> Hello.
> We are ready to announce Xorg update in OpenIndiana Hipster.
> X server was updated to 1.12.4, x11/server/xdmx server was added.
> Xvnc was rebuilt on the base of the new X server.
> xorg-video-intel 2.18.0

As mentioned on intel 945, resolution is locked to 1024X768, therefore 
unusable and also LCD panel brightness is not able to be set wiith GNOME 
panel addon.


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


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

Re: [oi-dev] xf86-video-ati 6.4.16 driver

[ken mays via oi-dev]

Alex,
My goal was to get the current Mesa 10.5.0-devel core libraries built and the 
software renderer working properly - which I just achieved on OI-hipster!!
You can bump intel to 2.9.1 without KMS usage
~K 

 On Friday, February 6, 2015 11:53 PM, Alexander Pyhalov  
wrote:
   

 Hello.
I've updated xf86-video-ati and tested it with ATI Radeon X1650.

drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed
[drm] failed to load kernel module "radeon"

As kernel support is missing, swrast dri module is used. Overall 
performance is not the best.
New module claims to support ATI Radeon HD 4250, which is mentioned in 
https://www.illumos.org/issues/2898,
but not
Radeon HD 7350
Radeon HD 7450
Radeon HD 7470
Radeon HD 7570
Radeon HD 7670,
which are mentioned in https://www.illumos.org/issues/2954.

Anyway, without kernel support for DRI, using ATI or Intel video adapter 
is troublesome.

-- 
System Administrator of Southern Federal University Computer Center



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


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

Re: [oi-dev] Stats

[ken mays via oi-dev]

The current analogy is:
1. Solaris 10/11 - production2. OpenIndiana - development/testing (but CAN be 
used in 24/7 production)
Hipster snapshots, the latest versions, work reliably on specific hardware and 
when using specific applications.
As for the small developer support, much of what was needed is done. The major 
needs are usually listed in the Wiki and bug reports. Most of the FOSS apps 
that run on Solaris can run on OpenIndiana in a 24/7 stable condition (I have 
both CAD/CAM and FlightGear simulators that ran reliable for months on 
OpenIndiana (hipster)).But the misconception of OpenIndiana stems from people 
supporting the desktop model versus server model - and the external indirect 
development community within most third-party IHV/ISVs.
Historically, the Schillix/Milax/Tribblix/OpenSXCE/Korona (aka Martux) distros 
were 1-2 staffed crews. About 89% of the non-major Linux distros have no more 
than 2-5 'developers' at the helm. 
The key misconception is understanding that now that we have a core distro - 
other distro makers are launchingtheir own 'spins' with their own support dev 
teams (but with a rebranded distro name).
So from one river, many oceans.
~ Ken




 

 On Friday, December 12, 2014 6:42 PM, Bob Friesenhahn 
 wrote:
   

 On Sat, 13 Dec 2014, Alexander Pyhalov wrote:

> OI Hipster change log can be found here:
> http://wiki.openindiana.org/oi/oi_hipster

I think that this looks impressive.  The main issue (feature-wise) 
seems to be the loss of SFE binary packages, and that SFE packages are 
not yet ready for GCC (mostly a build-options problem).

There has recently been some minor discussion of OI Hipster on the SFE 
development list.

Bob
-- 
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

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


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

Re: [oi-dev] Ruby 1.8 - should we preserve it?

[ken mays via oi-dev]

There is no need to support Ruby 1.8. Ruby 1.9.3 and higher is preferred for 
professional development.Suggest: Ruby 1.9.3-p551
~ Ken
 

 On Monday, November 24, 2014 10:13 AM, Alexander Pyhalov  
wrote:
   

 Hello.
I'm working on a set of changes to make ruby to 1.9 the default one.
Ruby 1.8 has already gone from upstream Solaris 12 userland repository. 
What do you think about it? Do we have to support it or is it useless in 
presence of 1.9?
-- 
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department

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


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

Re: [oi-dev] GDB in hipster

[ken mays via oi-dev]

Aurelien,

Can you use 'pstack' and 'pflags' ?  They are included.

~K





On Monday, September 29, 2014 10:47 PM, Alexander Pyhalov  wrote:
 


On 09/30/2014 03:24, Aurélien Larcher wrote:
> Hi Alexander,
> thank you for your reply.
> The only specific thing is that the code I develop uses MPI.
> I just checked if just calling a simple MPI_Init causes issues but I do not
> have much time right now so I just quickly copied a code snippet.
> I will get back to you later this week possibly.
>
> --
> alarcher@phainos> cat mpi_init.c
> #include 
>
> int main(int argc, char* argv[])
> {
>int initialized;
>MPI_Initialized(&initialized);
>
>if(!initialized)
>{
> MPI_Init(&argc, &argv);
>}
>return 0;
> }
> alarcher@phainos> gcc -ggdb mpi_init.c `pkg-config --libs mpich`
> alarcher@phainos> gdb ./a.out
> GNU gdb (GDB) 7.6.2
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later >
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i386-pc-solaris2.11".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /home/alarcher/hipster/gdb/a.out...done.
> (gdb) run
> Starting program: /home/alarcher/hipster/gdb/./a.out
> procfs:3974 -- process not stopped.
> procfs: ...giving up...
> (gdb) q
> A debugging session is active.
>
>  Inferior 1 [process 3696] will be killed.
>
> Quit anyway? (y or n)

Still no luck.
$ gdb ./a.out
(gdb) break MPI_Init
(gdb) run
Starting program: /export/home/alp/srcs/tests/./a.out
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
[Switching to Thread 1 (LWP 1)]

Breakpoint 1, 0xfecb4b06 in PMPI_Init () from 
/usr/lib/mpich/gcc/lib/libmpi.so.12
(gdb) bt
#0  0xfecb4b06 in PMPI_Init () from /usr/lib/mpich/gcc/lib/libmpi.so.12
#1  0x08051f2f in main (argc=1, argv=0x8047da4) at mpi-init.c:10
(gdb) kill

or just

(gdb) run
Starting program: /export/home/alp/srcs/tests/./a.out
[Thread debugging using libthread_db enabled]
[Inferior 1 (process 13897) exited normally]
(gdb)

It seems, more complex example is required.


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

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

Re: [oi-dev] OpenSXCE It is illegal to sell without source code.

[ken mays via oi-dev]

Hi Joerg,

Then, the solution is easy. People should offer him 'payable work' before 
asking for HIS contributions.

Martin asked for donations for his contribution - people have the freedom not 
to pay him as well as not use his work.
We pay bills to get provided services - but no payment means no services. How 
many established FOSS distro provides ask for
'payment' for their supported distro versions made 98% from FOSS 
contributions???

Some non-profit companies try to get funding since 'free work or trading' comes 
with a high utility overhead bill.

So if those asking for Martin's contributions won't make a donation to support 
his work - why should he do it???

People in the USA get paid $80/day to flip hamburgers and less to 
cut/trim/treat home lawns and wash vehicles...

He could easily update distros to Xnv 1.12.4 for both Schillix and OI in 1-2 
days. Probably add in LibreOffice 4.1.3 and other software,
many things not 'maintained' consistently by most existing Illumos-based 
distros. Oh, and port over the Xorg Intel/Radeon drivers.

Many work projects 'not existing' today for OI or even Solaris 11.x. Many good 
contributions. Everybody wins.

~K





On Friday, September 19, 2014 1:35 AM, Joerg Schilling 
 wrote:
 


ken mays via oi-dev  wrote:


> As for Martin, he did provide source for his initial releases and was going 
> to make the latest patches available.
> He pretty much told others what he was doing to solve various issues and even 
> where he was picking up some ideas and code. This was posted in a README and 
> his blogs. Does he even have to spell it out for some people?!?
>
>
> Yet, 'demanding' one give you something for FREE without supporting them or 
> funding their work is very petty and fruitless.
> Case in point, the various websites of BSD/Linux/other OS distros (and many 
> commercial websites) where this topic comes up to
> gain patched source code for FREE (when an 'open source' license is being 
> enforced).

Yes, Martin was even the only person that mentioned that his distro was based 
on 
SchilliX.

He did a lot of interesting things and it would be a great value for the 
community if he would offer his recent work for collaboration. 

His problem is that he likes to enforce payment for his work. This is not how 
things work. You get payed if you do something that is of what a customer 
demands. First doing work and then trying to enforce payment does not work.
I understand that his situation is not easy but OSS is givong away things for 
free and get payed for other things.

I work for a research institute for living and thus I am free to work for 
SchilliX in parts of my time. If I got a successful project, I may hire a 
student for SchilliX, but then I would hire someone to work on the most urgent 
goals and cannot pay Martin for something that has already been done. I hope 
that Martin will be able to get a job for living - the way others do too.



Jörg

-- 
EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/'___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OpenSXCE It is illegal to sell without source code.

[ken mays via oi-dev]

Joerg said: "I believe, we should rather encourage Oracle to share their code 
again following the CDDL."


On Thursday, September 18, 2014 2:13 AM, Joerg Schilling 
 wrote:
 


Nikola M.  wrote:

>
> Or the difference exist because I think CDDL forces treating files that 
> change previous code as patches and you maybe say, that treating files 
> that change existing code as patches is - optional?

If you add code in new files, it is fully optional to the author whether the 
new files are put under CDDL.

> I don't think text i quoted only allows - I think it _requires_ to treat 
> files that change previous code as contribution and that it is Not 
> optional. That is how copyleft works anyway anything one change is 
> destined to be glued into next release (except of course additional 
> files that do not change anything in previous code).
> So there are 2 types of files, ones that change something in previous 
> code and others that do not.

This was one of the main topics during a long phone call I had with the 
initiators of the CDDL in December 2004. As a result, all really ambiguous and 
wrong text was changed following my proposals (e.g. making the CDDL compatible
with the EU Copyright law). Fir the text you quoted, it was (after the 
discussion) obvious that this explains an option (not the default) for newly 
added files.

> > They cannot change the license of code they do not own and aprox. 1/3 
> > of the code in "hsfs" is owned by me because I was not payed for that 
> > code and because I did not sign a contract that transfers the code to Sun.
> If that is such obvious, maybe they could just make a deal and monetize 
> to you your parts since trey are using it in Solaris 11.
> Maybe you could ask them for compensation since they are obviously not 
> following CDDL and not releasing S11 source code in any part. Maybe 
> reaching some ground could be Ok for them, results of talks disclosed or 
> not.

This is of course an option for Oracle, but they did not chose this option as 
they currently illegaly distribute code. The interesting aspect of the German 
law is that it introduces a lever that never becomes statute-barred as long as 
the code in question is distributed ignoring the law.


> I have to mention, we have seen some source code leak at the S11 release 
> time (with CDDL all over it, probably still is, bu it is unknown outside 
> Orcl circles) so one can compare what they actually had inside at a time.
> It was strongly advised Not to look at it or reading it for reasons of 
> spoiling one's brain with something one can't use openly. Yet, I needed 
> to mention it :P

I believe, we should rather encourage Oracle to share their code again 
following the CDDL. THe uestion is whether we should sue Oracle and whether 
there would be people to support me if I did.

Jörg

-- 
EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/'


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



Not happening anytime soon in its entirety - but most things are already 
available enough for people to work on various parts.
Or, you can always beg and borrow the OSX/BSD/Linux streams. 

As for Martin, he did provide source for his initial releases and was going to 
make the latest patches available.
He pretty much told others what he was doing to solve various issues and even 
where he was picking up some ideas and code. This was posted in a README and 
his blogs. Does he even have to spell it out for some people?!?


Yet, 'demanding' one give you something for FREE without supporting them or 
funding their work is very petty and fruitless.
Case in point, the various websites of BSD/Linux/other OS distros (and many 
commercial websites) where this topic comes up to
gain patched source code for FREE (when an 'open source' license is being 
enforced).

What happens, usually, is that the patches are REMOVED, and you are given the 
original source - you then pay for the contributed work through support 
channel, funding, or some donation.

Reality: You can demand nothing when you offer nothing. No penny, no code.

Most of the major distros are funded. But, without money or 'perks' - they lose 
their developers.

As Martin said, he did his work to gain employment. He had a goal in mind, as 
many other people have done in the past and are now either a CEO/CTO or Lead 
Engineer, or Architect at their place of work.

People like Joerg and Martin are CERTIFIED or high-experienced Solaris 
admins/programmers. They do know their material.
They have both developed their own distros before many others did - and Martin 
supported SPARC equipment better than most open source distros did in the past.

I don't have to 'blow smoke' up anyone's 

Re: [oi-dev] Resignation

[ken mays via oi-dev]

Milan was one of the great ones... his contributions will be missed by all.

There actually was talks of making an oi_151a9 ISO... but I think there was a 
need to pull in the updated JDS fixes from Milan

~K
 


On Monday, August 11, 2014 3:16 PM, Andrew M. Hettinger 
 wrote:
  


Milan Jurik  wrote on 08/11/2014 01:22:07 PM:
> Hi,
> 
> based on the current situation with OI - lack of old OI non-hipster
> branch - and because of bad situation (according my view) of Illumos -
> like stupid ideas to include large chunks of 3rd party code to ON gate
> which makes it unmaintainable (why did Sun and Oracle invest so much to
> remove OpenSSL, SunSSH and ksh from ON gate? See how bad is ksh in
> Illumos and how old is Illumos SSH) I have to finalize my decision about
> my participation. Illumos and its distros are not for me anymore.
> 
> opensolaris.cz will be up for some time but no more updates to JDS and
> SFE. Do not hestitate to contact me in private if you think I still know
> something but I will not spend more time on the lists.
> If anybody is interested in some older bits then:
> 
> http://www.opensolaris.cz/builds/illumos-wpa-enterprise/webrev/
> http://www.opensolaris.cz/builds/tnf/webrev/
> http://www.opensolaris.cz/builds/ext2-merge/webrev/
> 
> Time to go
> 
> Milan 
> 

I have to admit, parts of this are a bit confusing to me. While there are some 
things coming into illumos, there is more going out. It's looking vary much 
like OpenSSL is going to be gone (from what I can tell, it's just a matter of 
making sure nothing depends on it, which is being worked on now), WU-ftpd is 
looking like it's going to be removed, SUN DHCPd is looking to be going too. 
Cardbus was just dropped, which is part of removing legacy PM.

I definitely understand the lack of stable OI releases (or any apparent desire 
to make a stable release from hipster) being frustrating.

At any rate, best of luck. You'll be missed.

Andrew Hettinger
http://Prominic.NET | Skype: AndrewProminic
Tel: 866.339.3169 (toll free) -or- 1.217.356.2888 x. 110 (int'l)
Fax: 866.372.3356 (toll free) -or- 1.217.356.3356            (int'l)


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

Re: [oi-dev] Update ftp package to Proftpd 1.3.5

[ken mays via oi-dev]

Oracle has already replaced wu-ftpd for proftpd.

See: 
http://pkg.oracle.com/solaris/release/manifest/0/service%2Fnetwork%2Fftp@1.3.4.0.3%2C5.11-0.175.2.0.0.42.1%3A20140623T021355Z
 (Proftpd 1.3.4)

So, we should replace OI service/network/ftp with proftpd 1.3.5.


Thanks,
Ken




On Thursday, July 31, 2014 9:57 AM, Alexander Pyhalov  wrote:
 


On 07/28/2014 10:13, Alexander Pyhalov wrote:
> On 07/27/2014 21:38, ken mays wrote:
>> Alex,
>>
>> We are using WU-ftpd which is the legacy ftp server used for the
>> service/network/ftp package.
>>
>> Upstream replaced it with Proftpd awhile ago in userland.
>>
>> Ref:
>> service/network/ftp

Hello.

I'd like to ask the following question. illumos-gate provides 
service/network/ftp and related packages (sources are in 
usr/src/cmd/cmd-inet/usr.sbin/in.ftpd). What do you think about it? I 
mean, for example, we can replace service/network/ftp with proftpd. Or 
add one more service/network/proftpd package, perhaps moving some 
proftpd files so that they don't conflict with wu-ftpd. Or perhaps, just 
ignore it and wait until illumos folk replace it with proftpd...

-- 
Best regards,
Alexander Pyhalov,
system administrator of Computer Center of Southern Federal University___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Review GCC 48

[ken mays via oi-dev]

Hello,

1. 'Whether the whole oi-userland should be rebuilt after updating GCC' - 
Answer: No, due to backward compatibility. Long-term, you'd want to ensure the 
new compiler does compile oi-userland and other consolidations without issues 
from a 'reassurance' perspective.

2. Becoming sketchy to keep supporting GCC 3.4.3. With GCC 4.8.3 passing GCC 
testsuite at near 100%, is there a true need to keep GCC 3.4.3? 

~ Kenaac "pci1028,3"
aac "pci1028,a"
aac "pci9005,285"
aac "pci9005,286"
aac "pciex9005,285"
aac "pciex9005,286"
acpinex "acpivirtnex"
adpu320 "pci9005,8000"
adpu320 "pci9005,800f.9005.5f"
adpu320 "pci9005,8010"
adpu320 "pci9005,8011"
adpu320 "pci9005,8012"
adpu320 "pci9005,8014"
adpu320 "pci9005,8015"
adpu320 "pci9005,8016"
adpu320 "pci9005,8017"
adpu320 "pci9005,801d"
adpu320 "pci9005,801e"
adpu320 "pci9005,801f"
adpu320 "pci9005,808f"
afe "pci10b7,9300"
afe "pci1113,1216"
afe "pci1317,1985"
afe "pci1317,9511"
afe "pci1317,9513"
afe "pci1317,981"
afe "pci1317,985"
afe "pci13d1,ab02"
afe "pci13d1,ab03"
afe "pci13d1,ab08"
afe "pci1737,ab08"
agptarget "pci1022,7454"
agptarget "pci8086,1130"
agptarget "pci8086,2560"
agptarget "pci8086,2570"
agptarget "pci8086,2580"
agptarget "pci8086,2590"
agptarget "pci8086,2770"
agptarget "pci8086,27a0"
agptarget "pci8086,27ac"
agptarget "pci8086,2970"
agptarget "pci8086,2980"
agptarget "pci8086,2990"
agptarget "pci8086,29a0"
agptarget "pci8086,29b0"
agptarget "pci8086,29c0"
agptarget "pci8086,29d0"
agptarget "pci8086,2a00"
agptarget "pci8086,2a10"
agptarget "pci8086,2a40"
agptarget "pci8086,2e00"
agptarget "pci8086,2e10"
agptarget "pci8086,2e20"
agptarget "pci8086,2e30"
agptarget "pci8086,2e40"
agptarget "pci8086,3575"
agptarget "pci8086,3580"
agptarget "pci8086,40"
agptarget "pci8086,44"
agptarget "pci8086,62"
agptarget "pci8086,6a"
agptarget "pci8086,7120"
agptarget "pci8086,7122"
agptarget "pci8086,7124"
ahci "pciclass,010601"
amd64_gart "pci1022,1103"
amd8111s "pci1022,7462"
amd_iommu "pci1002,5a23"
amd_iommu "pci1022,11ff"
amr "pci1000,1960.1000,532"
amr "pci101e,1960.1028,493"
amr "pci1000,1960.1028,518"
amr "pci1000,1960.1028,520"
arcmsr "pci17d3,1110"
arcmsr "pci17d3,1120"
arcmsr "pci17d3,1130"
arcmsr "pci17d3,1160"
arcmsr "pci17d3,1170"
arcmsr "pci17d3,1201"
arcmsr "pci17d3,1210"
arcmsr "pci17d3,1220"
arcmsr "pci17d3,1230"
arcmsr "pci17d3,1260"
arcmsr "pci17d3,1270"
arcmsr "pci17d3,1280"
arcmsr "pci17d3,1380"
arcmsr "pci17d3,1381"
arcmsr "pci17d3,1680"
arcmsr "pci17d3,1681"
arcmsr "pci17d3,1880"
arcmsr "pci17d3,1882"
asy "pci11c1,480"
ata "ide"
atge "pciex1969,1026"
atge "pciex1969,1048"
atge "pciex1969,1062"
atge "pciex1969,1063"
atge "pciex1969,1073"
atge "pciex1969,1083"
atge "pciex1969,2060"
atge "pciex1969,2062"
axf "usb7b8,420a"
axf "usbb95,7720"
axf "usbb95,772a"
axf "usb2001,1a00"
axf "usb77b,2226"
axf "usb846,1040"
axf "usbb95,1720"
axf "usb8dd,90ff"
axf "usb557,2009"
axf "usb411,3d"
axf "usb6189,182d"
axf "usb7aa,17"
axf "usb1189,893"
axf "usb1631,6200"
axf "usb13b1,18"
axf "usb1557,7720"
axf "usb7d1,3c05"
axf "usb2001,3c05"
axf "usb5ac,1402"
bcm_sata "pci1166,24a"
bfe "pci14e4,170c"
bfe "pci14e4,4401"
bfe "pci14e4,4402"
bge "SUNW,bge"
bge "pci108e,1647"
bge "pci108e,1648"
bge "pci108e,16a7"
bge "pci108e,16a8"
bge "pci14e4,1600"
bge "pci14e4,1601"
bge "pci14e4,1644"
bge "pci14e4,1645"
bge "pci14e4,1647"
bge "pci14e4,1648"
bge "pci14e4,1649"
bge "pci14e4,1653"
bge "pci14e4,1654"
bge "pci14e4,1657"
bge "pci14e4,1659"
bge "pci14e4,165d"
bge "pci14e4,165e"
bge "pci14e4,165f"
bge "pci14e4,1668"
bge "pci14e4,1669"
bge "pci14e4,166a"
bge "pci14e4,166e"
bge "pci14e4,1677"
bge "pci14e4,1678"
bge "pci14e4,1679"
bge "pci14e4,167d"
bge "pci14e4,1693"
bge "pci14e4,1696"
bge "pci14e4,1699"
bge "pci14e4,169b"
bge "pci14e4,169c"
bge "pci14e4,16a6"
bge "pci14e4,16a7"
bge "pci14e4,16a8"
bge "pci14e4,16c7"
bge "pciex14e4,1655"
bge "pciex14e4,1656"
bge "pciex14e4,1657"
bge "pciex14e4,165a"
bge "pciex14e4,165b"
bge "pciex14e4,165c"
bge "pciex14e4,165f"
bge "pciex14e4,1673"
bge "pciex14e4,1674"
bge "pciex14e4,1677"
bge "pciex14e4,167a"
bge "pciex14e4,167b"
bge "pciex14e4,1680"
bge "pciex14e4,1681"
bge "pciex14e4,1684"
bge "pciex14e4,1688"
bge "pciex14e4,1689"
bge "pciex14e4,1690"
bge "pciex14e4,1691"
bge "pciex14e4,1692"
bge "pciex14e4,1694"
bge "pciex14e4,1698"
bge "pciex14e4,169d"
bge "pciex14e4,16fd"
bge "pciex14e4,1713"
bnx "pci14e4,1639"
bnx "pci14e4,163a"
bnx "pci14e4,163b"
bnx "pci14e4,163c"
bnx "pci14e4,164a"
bnx "pci14e4,164c"
bnx "pci14e4,16aa"
bnx "pci14e4,16ac"
bnxe "pci14e4,164e"
bnxe "pci14e4,164f"
bnxe "pci14e4,1650"
bnxe "pciex14e4,164e"
bnxe "pciex14e4,164f"
bnxe "pciex14e4,1650"
bscbus "SVI0101"
ce "pci100b,35"
ce "pci108e,abba"
chxge "pci1425,7"
chxge "pci1425,a"
cpqary3 "pci103c,3211"
cpqary3 "pci103c,3212"
cpqary3 "pci103c,3223"
cpqary3 "pci103c,3225"
cpqary3 "pci103c,3234"
cpqary3 "pci103c,3235"
cpqary3 "pci103c,3237"
cpqary3 "pci103c,323d"
cpqary3 "pci103c,3241"
cpqary3 "pci103c,3243"
cpqary3 "pci103c,3245"
cpqary3 "pci103c,3247"
cpqary3 "