Re: [oi-dev] Firefox 52 preliminary testing

[bentahyr]

Hi Alexander, 
I noticed that there are issues with JS engine. 
For example, sites with banners that change over time, circle through the 
various items without any delay : 
http://www.pbtech.co.nz 
http://www.hardware.fr 

The followings keeps on being reloaded : 
http://www.metservice.com/towns-cities/wellington/wellington-city 
https://www.stuff.co.nz/ 

Best regards. 
Ben 

On 12/05/17 18:45, Alexander Pyhalov wrote: 


On 12.05.2017 09:43, Alexander Pyhalov wrote: 


Hello. 

It seems I've reached the state when FF doesn't crash now and then. 
Some testing is required. 

I've prepared two packages, debug and non-debug. 

Debug package: 
pkg://userland/web/browser/firefox@52.1.1,5.11-2017.0.0.0:20170511T214409Z 
( size ~ 2 GB ) 
Release package: 
pkg://userland/web/browser/firefox@52.1.1,5.11-2017.0.0.0:20170512T061040Z 
( size ~ 283 MB) 
Both packages are available from http://buildzone.oi-build.r61.net:1000/ 

Don't forget to backup your ~/.mozilla directories before updating. 

So far it seems there's issue with high CPU usage (two FF processes 
eat ~ 100% cpu for just communicating to each other). 
a) Need to confirm this on other installations. 
b) Need help in debugging the issue :) 



For those who wants to build it himself, component is here: 
https://github.com/pyhalov/oi-userland/tree/firefox-52 


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

Re: [oi-dev] Updated Graphics DRM support for OI

[bentahyr]

Hi Gordon,

Thank you.
I've tried it on a Dell Latitude E4300 (i965) and it seems to work fine at 
first glance.
I have my login screen, I can login and work as usual.
I tried some GL stuff and despite that it works, I have some errors on the 
terminal ouput.
$ glxinfo | more
[intel_init_bufmgr:1166] Error initializing buffer manager.
libGL error: failed to create dri screen
libGL error: failed to load driver: i965
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
[...]
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
GLX_SGI_make_current_read
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa Project (0x)
Device: Software Rasterizer (0x)
[...]

$ glxgears 
[intel_init_bufmgr:1166] Error initializing buffer manager.
libGL error: failed to create dri screen
libGL error: failed to load driver: i965
1535 frames in 5.0 seconds = 306.871 FPS

glxgear works despite the output errors.
Please find the Xorg.log at the following link :
https://share.gns.cri.nz/C1GRBFOKELRB/Xorg.0.log.html

Nothing of interest in syslog/dmesg

Best regards.
Ben

- Mail original -
De: "Gordon Ross" 
À: "_oi-announce" , 
annou...@lists.illumos.org
Cc: "_oi-dev" , "_illumos-dev" 

Envoyé: Lundi 28 Novembre 2016 05:33:47
Objet: [oi-dev] Updated Graphics DRM support for OI

We have some new graphics direct rendering manager (DRM) code to
announce for OpenIndiana/hipster.  This version should work better
on systems where hipster currently shows only a black screen.

If you'd like to try out the new DRM code, you can create a
(temporary) testing boot environment as described here:
https://www.illumos.org/projects/gfx-drm/wiki/
 How_to_create_a_BE_running_the_new_DRM_code

Alternatively, you can download and boot the ISO images here:
  http://dlc-int.openindiana.org/hipster/20161124/
and see how it works for you without installing.

Thanks to Alexander Pyhalov  for both the ISO images
and the instructions for creating a test BE.

Please report issues with this code on this tracker:
  https://www.illumos.org/projects/gfx-drm/issues

There's one fairly significant known issue (so far) which is that
the DRM driver does not restore VGA text mode when Xorg does its
last close of a DRM driver handle.


Developers interested in this code should note that we've imported
all the DRM code (both drivers and libraries) into its own source
repository.  The reasons for that are several: The DRM driver and
library components usually need to be updated together.  The DRM
driver code (formerly in illumos-gate) is being maintained under
different rules than illumos gate (i.e. no cstyle -- all this code
needs to track an upstream).  The new source repo. is:
  github.com/illumos/gfx-drm

Later, the old DRM code in illumos-gate can be removed.


There are some prerequisite changes for illumos needed by the new
DRM source repository.  I'll be working on getting those integrated
into illumos, but if you don't want to wait for that, you can get
those changes here:
   https://github.com/gwr/illumos-gate/commits/drm8
At a minimum, you need to build the gfx_private module there and
update that on the system where you'll install the updated DRM
drivers


If you feel the need to "reply to all" on this message, please
discuss the illumos changes (gfx_private updates etc.) on
develo...@list.illumos.org and other DRM driver and library
work on oi-dev@openindiana.org  (Please trim your CC list to
just ONE of those -- thanks!)

___
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] Wine 1.9.10 : compilation trial

[bentahyr]

Thanks for the link but DirectX installation went fine, and since 2010, 
winetricks appeared and helped to automate quite a lot of these tiedous tasks.

What I had no luck with is that with or without DirectX native implementation, 
I have the same memory error.
I'll keep that under the hood when have some time amd try to see with the Wine 
guys if we can get it to work.

As it used to work on opensolaris, I though it should work but I tried wine 
1.7.7 on OI151a9 and if it doesn't expose the same issue, it doesn't render 
(this is a very quick test with a very limited number of software so someone 
might have different results).

Just as a ref, wine is quite used to have access to proprietary music software 
and one may want to use it for picture/photo manipulation software as well (I 
known, I kind of lost my sense of humor lately but I'm working on it).

I personally use wine for Win32 legacy software so I'm glad with the current 
situation but I'd like to propose a complete solution. I'm running out of time 
regarding this so I'll pile it up with the other things I would like to 
port/package to OI.

Best regards.
Ben

On Tue, May 24, 2016 at 11:37:41AM +, ken mays via oi-dev wrote:
> 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

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

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

[bentahyr]

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.

Best regards.
Ben

On Tue, May 24, 2016 at 02:34:28AM +0200, Aurélien Larcher wrote:
>  Yes, you're right...
>  I was reading what I sent and realized that I may have redefined gregs
>  being regs.
>  Then I read your mail.
>
>;)
>
>
>  Ok... here is the state :
>  [...]
>  gmake[1]: Leaving directory
>  '/home/ben/tmp/wine-1.9.10/programs/winetest'
>  Wine build complete.
>
>  Cool,
>
>  To sum up
>  $ ./configure CFLAGS="-std=gnu99" CXXFLAGS="-std=gnu99"
>  Patch dlls/ntdll/signal_i386.c to add
>  #if defined(__sun) && defined(__SVR4)
>  #include 
>  #endif
>  $ gmake -j8
>  Et voila!!
>
>La grande classe ;)
>
>
>  I'm running gmake test and will test a few software.
>  But it already made my day.
>
>  Thanks for your help
>  Did I say "Cool!!" ?
>
>You are welcome. You can write a quick recipe for oi-userland and PR so
>that people can help you with testing :)
>
>If we follow the tradition it should be put in components/encumbered and
>have the same metadata as:
>
>
> [1]http://pkg.openindiana.org/sfe-encumbered/info/0/desktop%2Fwine%401.5.22%2C5.11-0.151.1.7%3A20130130T190158Z
>
>Best regards
>
>Aurélien
>
>
>  Best regards.
>  Ben
>
>  On Tue, May 24, 2016 at 01:45:41AM +0200, Aurélien Larcher wrote:
>  >On Tue, May 24, 2016 at 1:27 AM, <[1][2]benta...@chez.com> wrote:
>  >
>  >  Ok, good one...
>  >  The regset.h was the reason for this one :
>  >  #ifdef _SCO_DS
>  >  #include 
>  >  #define gregs regs
>  >  #endif
>  >
>  >  I'm not sure how in wine's world you define you're on OI/Solaris,
>  but
>  >  for the sake of trial, I just put the include and define out the
>  ifdef
>  >  block.
>  >
>  >The correct conditional for Solaris/illumos is:
>  >
>  >#if defined(__sun) && defined(__SVR4)
>  >#include 
>  >#endif
>  >
>  >
>  >  So I go a little bit further away :
>  >  $ gmake 2>&1 | head
>  >  gcc -c -o signal_i386.o signal_i386.c -I. -I../../include
>  -D__WINESRC__
>  >  -D_NTSYSTEM_ -D_REENTRANT -fPIC \
>  >-Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
>  >  -Wempty-body -Wignored-qualifiers \
>  >-Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter
>  -Wvla
>  >  -Wwrite-strings -Wpointer-arith \
>  >-Wlogical-op -fno-omit-frame-pointer -std=gnu99
>  >  signal_i386.c: In function ‘get_trap_code’:
>  >  signal_i386.c:362:54: error: ‘mcontext_t’ has no member named
>  ‘regs’
>  >   #define TRAP_sig(context)
>   ((context)->uc_mcontext.gregs[TRAPNO])
>  >^
>  >  signal_i386.c:564:12: note: in expansion of macro ‘TRAP_sig’
>  >   return TRAP_sig(sigcontext);
>  >
>  >  I checked and the ucontext.h is included but it is true that
>  >  sys/mcontext.h doesn't export any regs attribute/member for
>  mcontext_t.
>  >  I just wonder why it wants to find a member named ‘regs’ in
>  >  uc_mcontext.gregs, shouldn't it be a gregs member?
>  >
>  >You just wrote "I just put the include *and* define out the ifdef"
>  so that
>  >"gregs" is "regs" *kaboom* :P
>  >Put the include only without define as I wrote.
>  >
>  >
>  >  Best regards.
>  >  Ben
>  >
>  >  On Mon, May 23, 2016 at 11:44:46PM +0200, Thomas Wagner wrote:
>  >  > Ben,
>  >  >
>  >  > I took this as a trigger and had a look at wine 1.9.10 in SFE.
>  >  >
>  >  > The tricky part has been a missing symbol export in "port.o",
>  >  > but I got it right after some testing with compiler options.
>  >  >
>  >  > At the moment the final compile is running and if the result is
>  >  > at least a little bit usable, I'll push that into SVN.
>  >  > After a while the automatic builds should pick it up.
>  >  >
>  >  > I'll let you know if this attempt has been successful.
>  >  >
>  >  > In the 

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

[bentahyr]

Yes, you're right...
I was reading what I sent and realized that I may have redefined gregs being 
regs.
Then I read your mail.

Ok... here is the state :
[...]
gmake[1]: Leaving directory '/home/ben/tmp/wine-1.9.10/programs/winetest'
Wine build complete.

Cool,

To sum up
$ ./configure CFLAGS="-std=gnu99" CXXFLAGS="-std=gnu99"
Patch dlls/ntdll/signal_i386.c to add
#if defined(__sun) && defined(__SVR4)
#include 
#endif
$ gmake -j8
Et voila!!

I'm running gmake test and will test a few software.
But it already made my day.

Thanks for your help
Did I say "Cool!!" ?

Best regards.
Ben

On Tue, May 24, 2016 at 01:45:41AM +0200, Aurélien Larcher wrote:
>On Tue, May 24, 2016 at 1:27 AM, <[1]benta...@chez.com> wrote:
> 
>  Ok, good one...
>  The regset.h was the reason for this one :
>  #ifdef _SCO_DS
>  #include 
>  #define gregs regs
>  #endif
> 
>  I'm not sure how in wine's world you define you're on OI/Solaris, but
>  for the sake of trial, I just put the include and define out the ifdef
>  block.
> 
>The correct conditional for Solaris/illumos is:
> 
>#if defined(__sun) && defined(__SVR4)
>#include 
>#endif
> 
> 
>  So I go a little bit further away :
>  $ gmake 2>&1 | head
>  gcc -c -o signal_i386.o signal_i386.c -I. -I../../include -D__WINESRC__
>  -D_NTSYSTEM_ -D_REENTRANT -fPIC \
>    -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
>  -Wempty-body -Wignored-qualifiers \
>    -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla
>  -Wwrite-strings -Wpointer-arith \
>    -Wlogical-op -fno-omit-frame-pointer -std=gnu99
>  signal_i386.c: In function ‘get_trap_code’:
>  signal_i386.c:362:54: error: ‘mcontext_t’ has no member named ‘regs’
>   #define TRAP_sig(context)     ((context)->uc_mcontext.gregs[TRAPNO])
>                                                        ^
>  signal_i386.c:564:12: note: in expansion of macro ‘TRAP_sig’
>       return TRAP_sig(sigcontext);
> 
>  I checked and the ucontext.h is included but it is true that
>  sys/mcontext.h doesn't export any regs attribute/member for mcontext_t.
>  I just wonder why it wants to find a member named ‘regs’ in
>  uc_mcontext.gregs, shouldn't it be a gregs member?
> 
>You just wrote "I just put the include *and* define out the ifdef" so that
>"gregs" is "regs" *kaboom* :P
>Put the include only without define as I wrote.
> 
> 
>  Best regards.
>  Ben
> 
>  On Mon, May 23, 2016 at 11:44:46PM +0200, Thomas Wagner wrote:
>  > Ben,
>  >
>  > I took this as a trigger and had a look at wine 1.9.10 in SFE.
>  >
>  > The tricky part has been a missing symbol export in "port.o",
>  > but I got it right after some testing with compiler options.
>  >
>  > At the moment the final compile is running and if the result is
>  > at least a little bit usable, I'll push that into SVN.
>  > After a while the automatic builds should pick it up.
>  >
>  > I'll let you know if this attempt has been successful.
>  >
>  > In the upcoming SVN commit for SFEwine.spec you can see
>  > what I did to compile wine.
>  >
>  > Regards,
>  > Tom
>  >
>  > On Mon, May 23, 2016 at 09:40:22AM +, Aur?lien Larcher wrote:
>  > > Illumos changed inclusion of regset.h some months ago.
>  > > You need to include sys/regset.h
>  > >
>  > >
>  > > À lun. mai 23 04:25:12 2016 GMT+0200, [2]benta...@chez.com a écrit
>  :
>  > > > Hi
>  > > > I have a bit of free time today and thought I could give wine
>  compilation a go.
>  > > >
>  > > > configure stage is ok
>  > > > I need to add the -std=gnu99  to C(XX)FLAGS to pass first error
>  then unfortunately it fails a lot later with the following error :
>  > > >
>  > > > gmake[1]: Entering directory
>  '/home/franck/tmp/wine-1.9.10/dlls/ntdll'
>  > > > gcc -c -o signal_i386.o signal_i386.c -I. -I../../include
>  -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC \
>  > > >   -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
>  -Wempty-body -Wignored-qualifiers \
>  > > >   -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter
>  -Wvla -Wwrite-strings -Wpointer-arith \
>  > > >   -Wlogical-op -fno-omit-frame-pointer -std=gnu99
>  > > > In file included from signal_i386.c:60:0:
>  > > > signal_i386.c: In function 'init_handler':
>  > > > signal_i386.c:342:60: error: 'FS' undeclared (first use in this
>  function)
>  > > >  #define FS_sig(context)      ((context)->uc_mcontext.gregs[FS])
>  > > >                                                             ^
>  > > > ../../include/windef.h:337:52: note: in definition of macro
>  'LOWORD'
>  > > >  #define LOWORD(l)              ((WORD)((DWORD_PTR)(l) & 0x))
>  > > >                   

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

[bentahyr]

Ok, good one...
The regset.h was the reason for this one :
#ifdef _SCO_DS
#include 
#define gregs regs
#endif

I'm not sure how in wine's world you define you're on OI/Solaris, but for the 
sake of trial, I just put the include and define out the ifdef block.

So I go a little bit further away :
$ gmake 2>&1 | head
gcc -c -o signal_i386.o signal_i386.c -I. -I../../include -D__WINESRC__ 
-D_NTSYSTEM_ -D_REENTRANT -fPIC \
  -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body 
-Wignored-qualifiers \
  -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla 
-Wwrite-strings -Wpointer-arith \
  -Wlogical-op -fno-omit-frame-pointer -std=gnu99
signal_i386.c: In function ‘get_trap_code’:
signal_i386.c:362:54: error: ‘mcontext_t’ has no member named ‘regs’
 #define TRAP_sig(context) ((context)->uc_mcontext.gregs[TRAPNO])
  ^
signal_i386.c:564:12: note: in expansion of macro ‘TRAP_sig’
 return TRAP_sig(sigcontext);

I checked and the ucontext.h is included but it is true that sys/mcontext.h 
doesn't export any regs attribute/member for mcontext_t.
I just wonder why it wants to find a member named ‘regs’ in uc_mcontext.gregs, 
shouldn't it be a gregs member?

Best regards.
Ben


On Mon, May 23, 2016 at 11:44:46PM +0200, Thomas Wagner wrote:
> Ben,
> 
> I took this as a trigger and had a look at wine 1.9.10 in SFE.
> 
> The tricky part has been a missing symbol export in "port.o",
> but I got it right after some testing with compiler options.
> 
> At the moment the final compile is running and if the result is
> at least a little bit usable, I'll push that into SVN. 
> After a while the automatic builds should pick it up.
> 
> I'll let you know if this attempt has been successful.
> 
> In the upcoming SVN commit for SFEwine.spec you can see 
> what I did to compile wine.
> 
> Regards,
> Tom
> 
> On Mon, May 23, 2016 at 09:40:22AM +, Aur?lien Larcher wrote:
> > Illumos changed inclusion of regset.h some months ago.
> > You need to include sys/regset.h
> > 
> > 
> > À lun. mai 23 04:25:12 2016 GMT+0200, benta...@chez.com a écrit :
> > > Hi
> > > I have a bit of free time today and thought I could give wine compilation 
> > > a go.
> > > 
> > > configure stage is ok
> > > I need to add the -std=gnu99  to C(XX)FLAGS to pass first error then 
> > > unfortunately it fails a lot later with the following error :
> > > 
> > > gmake[1]: Entering directory '/home/franck/tmp/wine-1.9.10/dlls/ntdll'
> > > gcc -c -o signal_i386.o signal_i386.c -I. -I../../include -D__WINESRC__ 
> > > -D_NTSYSTEM_ -D_REENTRANT -fPIC \
> > >   -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement 
> > > -Wempty-body -Wignored-qualifiers \
> > >   -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla 
> > > -Wwrite-strings -Wpointer-arith \
> > >   -Wlogical-op -fno-omit-frame-pointer -std=gnu99
> > > In file included from signal_i386.c:60:0:
> > > signal_i386.c: In function 'init_handler':
> > > signal_i386.c:342:60: error: 'FS' undeclared (first use in this function)
> > >  #define FS_sig(context)  ((context)->uc_mcontext.gregs[FS])
> > > ^
> > > ../../include/windef.h:337:52: note: in definition of macro 'LOWORD'
> > >  #define LOWORD(l)  ((WORD)((DWORD_PTR)(l) & 0x))
> > > ^
> > > signal_i386.c:965:18: note: in expansion of macro 'FS_sig'
> > >  *fs = LOWORD(FS_sig(sigcontext));
> > >   ^
> > > signal_i386.c:342:60: note: each undeclared identifier is reported only 
> > > once for each function it appears in
> > >  #define FS_sig(context)  ((context)->uc_mcontext.gregs[FS])
> > > ^
> > > ../../include/windef.h:337:52: note: in definition of macro 'LOWORD'
> > >  #define LOWORD(l)  ((WORD)((DWORD_PTR)(l) & 0x))
> > > ^
> > > signal_i386.c:965:18: note: in expansion of macro 'FS_sig'
> > >  *fs = LOWORD(FS_sig(sigcontext));
> > >   ^
> > > signal_i386.c:343:60: error: 'GS' undeclared (first use in this function)
> > >  #define GS_sig(context)  ((context)->uc_mcontext.gregs[GS])
> > > ^
> > > ../../include/windef.h:337:52: note: in definition of macro 'LOWORD'
> > >  #define LOWORD(l)  ((WORD)((DWORD_PTR)(l) & 0x))
> > > ^
> > > signal_i386.c:970:18: note: in expansion of macro 'GS_sig'
> > >  *gs = LOWORD(GS_sig(sigcontext));
> > >   ^
> > > signal_i386.c:337:60: error: 'CS' undeclared (first use in this function)
> > >  #define CS_sig(context)  ((context)->uc_mcontext.gregs[CS])
> > > ^
> > > signal_i386.c:983:29: 

[oi-dev] Wine 1.9.10 : compilation trial

[bentahyr]

Hi
I have a bit of free time today and thought I could give wine compilation a go.

configure stage is ok
I need to add the -std=gnu99  to C(XX)FLAGS to pass first error then 
unfortunately it fails a lot later with the following error :

gmake[1]: Entering directory '/home/franck/tmp/wine-1.9.10/dlls/ntdll'
gcc -c -o signal_i386.o signal_i386.c -I. -I../../include -D__WINESRC__ 
-D_NTSYSTEM_ -D_REENTRANT -fPIC \
  -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body 
-Wignored-qualifiers \
  -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla 
-Wwrite-strings -Wpointer-arith \
  -Wlogical-op -fno-omit-frame-pointer -std=gnu99
In file included from signal_i386.c:60:0:
signal_i386.c: In function 'init_handler':
signal_i386.c:342:60: error: 'FS' undeclared (first use in this function)
 #define FS_sig(context)  ((context)->uc_mcontext.gregs[FS])
^
../../include/windef.h:337:52: note: in definition of macro 'LOWORD'
 #define LOWORD(l)  ((WORD)((DWORD_PTR)(l) & 0x))
^
signal_i386.c:965:18: note: in expansion of macro 'FS_sig'
 *fs = LOWORD(FS_sig(sigcontext));
  ^
signal_i386.c:342:60: note: each undeclared identifier is reported only once 
for each function it appears in
 #define FS_sig(context)  ((context)->uc_mcontext.gregs[FS])
^
../../include/windef.h:337:52: note: in definition of macro 'LOWORD'
 #define LOWORD(l)  ((WORD)((DWORD_PTR)(l) & 0x))
^
signal_i386.c:965:18: note: in expansion of macro 'FS_sig'
 *fs = LOWORD(FS_sig(sigcontext));
  ^
signal_i386.c:343:60: error: 'GS' undeclared (first use in this function)
 #define GS_sig(context)  ((context)->uc_mcontext.gregs[GS])
^
../../include/windef.h:337:52: note: in definition of macro 'LOWORD'
 #define LOWORD(l)  ((WORD)((DWORD_PTR)(l) & 0x))
^
signal_i386.c:970:18: note: in expansion of macro 'GS_sig'
 *gs = LOWORD(GS_sig(sigcontext));
  ^
signal_i386.c:337:60: error: 'CS' undeclared (first use in this function)
 #define CS_sig(context)  ((context)->uc_mcontext.gregs[CS])
^
signal_i386.c:983:29: note: in expansion of macro 'CS_sig'
 if (!wine_ldt_is_system(CS_sig(sigcontext)) ||
 ^
signal_i386.c:340:60: error: 'SS' undeclared (first use in this function)
 #define SS_sig(context)  ((context)->uc_mcontext.gregs[SS])
^
signal_i386.c:984:29: note: in expansion of macro 'SS_sig'
 !wine_ldt_is_system(SS_sig(sigcontext)))  /* 16-bit mode */
 ^
signal_i386.c:353:60: error: 'ESP' undeclared (first use in this function)
 #define ESP_sig(context) ((context)->uc_mcontext.gregs[ESP])
^
signal_i386.c:995:21: note: in expansion of macro 'ESP_sig'
 return (void *)(ESP_sig(sigcontext) & ~3);
 ^
signal_i386.c: In function 'save_context':
signal_i386.c:329:60: error: 'EAX' undeclared (first use in this function)
 #define EAX_sig(context) ((context)->uc_mcontext.gregs[EAX])
^
signal_i386.c:1108:29: note: in expansion of macro 'EAX_sig'
 context->Eax  = EAX_sig(sigcontext);
 ^
signal_i386.c:330:60: error: 'EBX' undeclared (first use in this function)
 #define EBX_sig(context) ((context)->uc_mcontext.gregs[EBX])
^
signal_i386.c:1109:29: note: in expansion of macro 'EBX_sig'
 context->Ebx  = EBX_sig(sigcontext);
 ^
signal_i386.c:331:60: error: 'ECX' undeclared (first use in this function)
 #define ECX_sig(context) ((context)->uc_mcontext.gregs[ECX])
^
signal_i386.c:1110:29: note: in expansion of macro 'ECX_sig'
 context->Ecx  = ECX_sig(sigcontext);
 ^
signal_i386.c:332:60: error: 'EDX' undeclared (first use in this function)
 #define EDX_sig(context) ((context)->uc_mcontext.gregs[EDX])
^
signal_i386.c::29: note: in expansion of macro 'EDX_sig'
 context->Edx  = EDX_sig(sigcontext);
 ^
signal_i386.c:333:60: error: 'ESI' undeclared (first use in this function)
 #define ESI_sig(context) ((context)->uc_mcontext.gregs[ESI])
^

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

[bentahyr]

Hi,
 After unconmpressing the archive from / (so location of binaries are in 
/usr/local/bin), most of the binaries complains about not having access to 
libdconf.so.1 which isn't in the archive nor standard repos.
Calculator works fine, though


Best regards.
Ben

On Sun, May 08, 2016 at 03:35:25PM +, ken mays via oi-dev wrote:
>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
> 
>[1]http://mate-desktop.org/blog/2016-04-08-mate-1-14-released/
>About MATE:
>[2]http://mate-desktop.org/blog/2014-02-07-stefano-presents-mate-at-fosdem/
>Ref: [3]http://wiki.openindiana.org/oi/MATE+1.14+Desktop
>Contributed OpenIndiana MATE 1.14 Binaries:
>
> [4]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
> 
> References
> 
>Visible links
>1. http://mate-desktop.org/blog/2016-04-08-mate-1-14-released/
>2. http://mate-desktop.org/blog/2014-02-07-stefano-presents-mate-at-fosdem/
>3. http://wiki.openindiana.org/oi/MATE+1.14+Desktop
>4. 
> http://dlc.openindiana.org/mate-desktop/oi-mate-1.14-desktop-kmays_20160505.tar.xz


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

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

[bentahyr]

Hi 

I' m glad to hear this excellent news  but mate-panel (and quite a few other) 
fails to start due to missing libdconf.so.1 which is not part of the archive 
nor current repos. 

Best regards. 
Ben 

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

Re: [oi-dev] Pull request : how to get back on track (git lost)

[bentahyr]

Thanks Aurélien, 
Considering the number of commits and the size of the components it was easier 
to cherry-pick one commit at a time rather than rebase or other bulk method. 


So here I am with my 2 branches (Maybe I should think about naming branches) : 
$ git branch 
libconfig 
* oi/hipster 
sslh 

$ git show-branch --topo-order 
! [libconfig] Use of $(MACH64) in p5m file 
* [oi/hipster] Add component libconfig as a requirement for sslh 
! [sslh] Update license headers from Opensolaris to Illumos CDDL Clean Makefile 
of unnecessary bits Clean p5m of unnecessary bits p5m generated from Makefile 
info Patch to sslh Makefile includes not compressed man page SMF manifest has 
been stripped out of unnecessary things SMF method script has been completely 
rewritten 
 
+ [sslh] Update license headers from Opensolaris to Illumos CDDL Clean Makefile 
of unnecessary bits Clean p5m of unnecessary bits p5m generated from Makefile 
info Patch to sslh Makefile includes not compressed man page SMF manifest has 
been stripped out of unnecessary things SMF method script has been completely 
rewritten 
+ [sslh^] No need to specify SMG FMRI, defined by XML file 
+ [sslh~2] Remove unused commented properties 
+ [sslh~3] Consistency between hardcoded configuration file lookup and method 
+ [sslh~4] Add component sslh 
+ + [libconfig] Use of $(MACH64) in p5m file 
+ + [libconfig^] Change license header from Opensolaris to Illumos CDDL 
+ + [libconfig~2] Removed dir actions Added tabs to aligned action parameters 
+ + [libconfig~3] Fixed P5M file : - build from make sample-manifest - remove 
.a .la files - include 64bits files as well 
+ + [libconfig~4] Add component libconfig as a requirement for sslh 
* [oi/hipster] Add component libconfig as a requirement for sslh 
+*+ [libconfig~5] Use of in p5m file 
++*+ [libconfig~6] Update license headers from Opensolaris to Illumos CDDL 
Clean Makefile of unnecessary bits Clean p5m of unnecessary bits p5m generated 
from Makefile info Patch to sslh Makefile includes not compressed man page SMF 
manifest has been stripped out of unnecessary things SMF method script has been 
completely rewritten 

But I'm not sure of where I am because when I try to create a pull request on 
github on a specific branch, I can see all the commit from the other branch. 
Pfiuu, I have to admit that I spend more time to do git/github stuff than 
actually "doing work". 
As Jim said, there's many schools so you can find documents out there that 
through you in many various direction. 

Best regards. 
Ben 

On 21/03/16 12:32, Aurélien Larcher wrote: 



Hello, 






Hi, 

I have hard time to get through the git way of doing things right now. 

So, I forked oi-userland, added components or changes to it and did a pull 
request. 
Ok, I understand that I should have done one component at a time. 





Whenever there is a dependency of said component at build time yes: PR the 
dependency first. 



It seems that the git way of doing this is to create one branch per component 
which I haven't done. 

Now I have all my commits in oi/hipster and how can I reach the situation where 
I can pull request one component only ? 





In your case it is easy because there is no dependency between commits. 

I would say the easiest is to create a new branch (git checkout -b libconfig) 
and git cherry-pick the commits related to libconfig. 


Is branching per component the best way to make pull request ? 





In general features and fixes should live in separate branches yes and one for 
each component: exception is made in case dependencies or lack thereof allow 
several fixes in one PR. 

If you think how the build server works it makes sense. 





Best regards. 
Ben 






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

[oi-dev] Pull request : how to get back on track (git lost)

[bentahyr]

Hi,

I have hard time to get through the git way of doing things right now. 

So, I forked oi-userland, added components or changes to it and did a pull 
request.
Ok, I understand that I should have done one component at a time.
It seems that the git way of doing this is to create one branch per component 
which I haven't done.

Now I have all my commits in oi/hipster and how can I reach the situation where 
I can pull request one component only ?

Is branching per component the best way to make pull request ?

Best regards.
Ben

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

Re: [oi-dev] Pull request #1701 for sslh+libconfig

[bentahyr]

Ok, I already found issues :
sslh.8.gz is not in gzip format (make publish scramble the gzip format of 
the file)
  I'm not sure what is happening here as after make install, the file in 
the prototype directory tree is good.

service doesn't start with SMF while ok with command line (sslh fails to 
setid/gid to nobody)
  I suspect SMF starts the daemon with some particular privileges that 
prevent sslh to switch to user nobody, I'll check how it is done in manifest 
for apache for example.

I'll cover that the next days

best regards
Ben

- Mail original -
De: benta...@chez.com
À: "OpenIndiana Developer mailing list" 
Envoyé: Mardi 16 Février 2016 17:27:34
Objet: [oi-dev] Pull request #1701 for sslh+libconfig

Hi,

I just did a pull request for sslh and libconfig component.
These are new components.

This is my first contribution so please, look in depth as I tried to follow as 
much as I can the rules and docs.

Pfiuu, it was quite a work to go through all the package publishing process. 
I'm not used to the exercise and IPS doesn't make it easy but I'll get used to.


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

Best regards.
Ben

___
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] Pull request #1701 for sslh+libconfig

[bentahyr]

Hi,

I just did a pull request for sslh and libconfig component.
These are new components.

This is my first contribution so please, look in depth as I tried to follow as 
much as I can the rules and docs.

Pfiuu, it was quite a work to go through all the package publishing process. 
I'm not used to the exercise and IPS doesn't make it easy but I'll get used to.


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

Best regards.
Ben

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

[oi-dev] Userland dev, Zone and processes

[bentahyr]

Hi,

I created a zone with oi-userland dev and tools and I finally made my 2 first 
packages.
I gave up on cloning the dev zone (zoneadm clone doesn't work) to try to 
install the package and relied VBox as I don't need much power to test the 
package.

Now I would like to install these packages on my dev zone so I can work on a 
third package depending on the 2 first ones but here I am with a new issue. I 
can't seem to add publisher and use packages from my dev zone.
Adding publisher is ok but when I issue the pkg install command I get :

-pkg install: Invalid child image publisher configuration.  Child image 
publisher
-configuration must be a superset of the parent image publisher configuration.
-Please update the child publisher configuration to match the parent.  If the
-child image is a zone this can be done automatically by detaching and
-attaching the zone.
-
-The parent image has the following enabled publishers:
-PUBLISHER 0: openindiana.org
-PUBLISHER 1: hipster-encumbered
-
-The child image has the following enabled publishers:
-PUBLISHER 0: userland
-PUBLISHER 1: openindiana.org
-PUBLISHER 2: hipster-encumbered
-PUBLISHER 3: localhostoih

So I was wondering what am I doing wrong in the zone as it seems IPS is highly 
tighten to the global zone. Is there a more independent way to set the zone ?

Second question is what should be the process to add new packages to userland 
on github ?
- open feature request on OI bug tracker ?
- pull request on github oi-userland repo ?
- mail to oi-dev ?

Best regards.
Ben

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

[oi-dev] oi-userland component build and directory structure

[bentahyr]

Hi,
I'm trying to build simple software as packages.
If I understand correctly, the way the oi-userland works is package is compiled 
in a build directory different from the source tarball extraction.

My issue is that some include files are not transferred from the source to the 
build directory and the code refer to "#include " so the make fails 
whereas going into the source directory and perform the build works fine.

How would be the oi way to tackle this ?

Ben

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

Re: [oi-dev] libjpeg-turbo and VLC

[bentahyr]

I'll answer my own mail :
nvidia graphic driver is required by ffmpeg
postgres libs are required by qt4.

Best regards.

- Mail original -
De: benta...@chez.com
À: "OpenIndiana Developer mailing list" 
Envoyé: Dimanche 10 Janvier 2016 16:43:05
Objet: Re: [oi-dev] libjpeg-turbo and VLC

Hi,
I plugged the hardware and was about to test vlc.
I noticed the package vlc v2.2.1 in hipster-encumbered. I tried to installed it 
but when I do so it pulls out :
- postgres libs
database/postgres-93/library 9.3.10-2015.0.2.0
- nvidia graphic
driver/graphics/nvidia 0.340.93-2015.0.1.0

If the first one in not really an issue but rather a matter of curiosity, why 
and where the dependency comes from.
The second is an issue as I use an old graphic card (Nvidia Quadro FX3500), I 
need an old driver (v304 is the latest that support this graphic card). I'm 
just wondering where this dependency comes from as well ?

Best regards.
Franck

- Mail original -
De: benta...@chez.com
À: "OpenIndiana Developer mailing list" 
Envoyé: Mardi 22 Décembre 2015 15:18:13
Objet: Re: [oi-dev] libjpeg-turbo and VLC

Hi,

I performed some additional tests and they went fine decoding any video from 
"Vidéo for Everybody" test page but performance was underneath firefox 
(framerate, slugish video).
I couldn't play a dvd due to rights and access to DVD drive through virtualbox.

I really need to test on hardware for DVD and performance. I'll see that after 
new years day.
It looks very promising to me.

Best regards.
Ben

- Mail original -
De: benta...@chez.com
À: "OpenIndiana Developer mailing list" 
Envoyé: Vendredi 18 Décembre 2015 11:38:17
Objet: Re: [oi-dev] libjpeg-turbo and VLC

Hi,
I'm kind of digging out this but as I'm slow to do things.
I did a compile of vlc out of the oi-userland component you made and it 
compiled fine.

I tried a few video and old stuff MPEG, mp3,.. are fine.
Regarding MP4 (x264) I have issues (XCB messages in console) but I'm not sure 
how much the "run in vbox" situation is responsible from that.
I'll try more tests with DVDs next week.
After end of year break, I'll be able to test based on hardware rather than 
virtual machine.

Like I said, I amazed how you guys caught back on those key softwares.

Best regards.
Ben

- Mail original -
De: "Aurélien Larcher" 
À: "OpenIndiana Developer mailing list" 
Envoyé: Samedi 12 Décembre 2015 14:31:10
Objet: Re: [oi-dev] libjpeg-turbo and VLC



Hello, 






- navigator 

Firefox 43 beta is available on Hipster: 
http://www.openindiana.org/2015/11/30/firefox-43b/ 



- office suite 



LibreOffice available from SFE: sfe.opencsw.org 



- multimedia player 



VLC 2.2.1 soon I promise ;) 



I think we cover nearly 80% of generic desktop computer needs. 



So we are almost good ? ;) 



I'll try my best to contribute, the very few hours per week I got have been 
diverted by a SGI Octane lately, I have to focus on tiny things I can achieve. 



Oh an Octane, nice :) I just have Indies and O2s, not super beefy. 


I submitted a PR for IJG's libjpeg: 

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

but I am confused.. I do not know what it is the best option... 

Best regards, 


Aurelien 



Best regards 
Ben 

- Mail original - 
De: "Aurélien Larcher" < aurelien.larc...@gmail.com > 
À: "OpenIndiana Developer mailing list" < oi-dev@openindiana.org > 
Envoyé: Samedi 12 Décembre 2015 05:40:40 
Objet: Re: [oi-dev] libjpeg-turbo and VLC 




Hi, 
maybe are you missing the hipster-encumbered repository ? 

http://pkg.openindiana.org/hipster-encumbered/en/index.shtml 

Some libs are still missing (like live55) but they are only optional. 

The only showstopper is that VLC uses libjpeg-turbo's jpeg_mem_src so I 
prepared several libjpeg components to provide IJG's and the Turbo 
implementations in separate subdirectory. 

If you have the time, you can contribute the missing optional libraries listed 
here: 

http://wiki.openindiana.org/oi/Multimedia 


After adding libjpeg-turbo with 6b compliance, VLC 2.2.1 compile out of the box 
provided that you add some flags: 

CFLAGS=" -DLUA_COMPAT_ALL=1 -DGL_GLEXT_PROTOTYPES -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 " 


The first is to enable backward compatibility mode with Lua 5.1, but I think 
our 5.2 needs recompile with the backward compatibility flag. 

The second is to address a compilation error. 

The last bits are to make sure that the macros is declared in a consistent way 
but I am not sure that is the case as some warnings still show up. 


If you have more time than I have, I can push my VLC branch so that you can 
finish up the component and test with the optional libraries. 

But before we can add VLC to oi-userland/encumbered, I need to push the libjpeg 
components in any case. 
Best regards 

Aurélien 










On Fri, Dec 11, 2015 at 1:27 AM, < 

Re: [oi-dev] libjpeg-turbo and VLC

[bentahyr]

Hi,
I plugged the hardware and was about to test vlc.
I noticed the package vlc v2.2.1 in hipster-encumbered. I tried to installed it 
but when I do so it pulls out :
- postgres libs
database/postgres-93/library 9.3.10-2015.0.2.0
- nvidia graphic
driver/graphics/nvidia 0.340.93-2015.0.1.0

If the first one in not really an issue but rather a matter of curiosity, why 
and where the dependency comes from.
The second is an issue as I use an old graphic card (Nvidia Quadro FX3500), I 
need an old driver (v304 is the latest that support this graphic card). I'm 
just wondering where this dependency comes from as well ?

Best regards.
Franck

- Mail original -
De: benta...@chez.com
À: "OpenIndiana Developer mailing list" 
Envoyé: Mardi 22 Décembre 2015 15:18:13
Objet: Re: [oi-dev] libjpeg-turbo and VLC

Hi,

I performed some additional tests and they went fine decoding any video from 
"Vidéo for Everybody" test page but performance was underneath firefox 
(framerate, slugish video).
I couldn't play a dvd due to rights and access to DVD drive through virtualbox.

I really need to test on hardware for DVD and performance. I'll see that after 
new years day.
It looks very promising to me.

Best regards.
Ben

- Mail original -
De: benta...@chez.com
À: "OpenIndiana Developer mailing list" 
Envoyé: Vendredi 18 Décembre 2015 11:38:17
Objet: Re: [oi-dev] libjpeg-turbo and VLC

Hi,
I'm kind of digging out this but as I'm slow to do things.
I did a compile of vlc out of the oi-userland component you made and it 
compiled fine.

I tried a few video and old stuff MPEG, mp3,.. are fine.
Regarding MP4 (x264) I have issues (XCB messages in console) but I'm not sure 
how much the "run in vbox" situation is responsible from that.
I'll try more tests with DVDs next week.
After end of year break, I'll be able to test based on hardware rather than 
virtual machine.

Like I said, I amazed how you guys caught back on those key softwares.

Best regards.
Ben

- Mail original -
De: "Aurélien Larcher" 
À: "OpenIndiana Developer mailing list" 
Envoyé: Samedi 12 Décembre 2015 14:31:10
Objet: Re: [oi-dev] libjpeg-turbo and VLC



Hello, 






- navigator 

Firefox 43 beta is available on Hipster: 
http://www.openindiana.org/2015/11/30/firefox-43b/ 



- office suite 



LibreOffice available from SFE: sfe.opencsw.org 



- multimedia player 



VLC 2.2.1 soon I promise ;) 



I think we cover nearly 80% of generic desktop computer needs. 



So we are almost good ? ;) 



I'll try my best to contribute, the very few hours per week I got have been 
diverted by a SGI Octane lately, I have to focus on tiny things I can achieve. 



Oh an Octane, nice :) I just have Indies and O2s, not super beefy. 


I submitted a PR for IJG's libjpeg: 

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

but I am confused.. I do not know what it is the best option... 

Best regards, 


Aurelien 



Best regards 
Ben 

- Mail original - 
De: "Aurélien Larcher" < aurelien.larc...@gmail.com > 
À: "OpenIndiana Developer mailing list" < oi-dev@openindiana.org > 
Envoyé: Samedi 12 Décembre 2015 05:40:40 
Objet: Re: [oi-dev] libjpeg-turbo and VLC 




Hi, 
maybe are you missing the hipster-encumbered repository ? 

http://pkg.openindiana.org/hipster-encumbered/en/index.shtml 

Some libs are still missing (like live55) but they are only optional. 

The only showstopper is that VLC uses libjpeg-turbo's jpeg_mem_src so I 
prepared several libjpeg components to provide IJG's and the Turbo 
implementations in separate subdirectory. 

If you have the time, you can contribute the missing optional libraries listed 
here: 

http://wiki.openindiana.org/oi/Multimedia 


After adding libjpeg-turbo with 6b compliance, VLC 2.2.1 compile out of the box 
provided that you add some flags: 

CFLAGS=" -DLUA_COMPAT_ALL=1 -DGL_GLEXT_PROTOTYPES -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 " 


The first is to enable backward compatibility mode with Lua 5.1, but I think 
our 5.2 needs recompile with the backward compatibility flag. 

The second is to address a compilation error. 

The last bits are to make sure that the macros is declared in a consistent way 
but I am not sure that is the case as some warnings still show up. 


If you have more time than I have, I can push my VLC branch so that you can 
finish up the component and test with the optional libraries. 

But before we can add VLC to oi-userland/encumbered, I need to push the libjpeg 
components in any case. 
Best regards 

Aurélien 










On Fri, Dec 11, 2015 at 1:27 AM, < benta...@chez.com > wrote: 


Hi Aurélien, 

This is great news. 
I tried myself and my results are way less optimistic than yours. 
How did you compiled the libraries necessary for VLC ? 
After installing all I could from repo, I'm still left to compile the following 
: 
a52 bluray caca chromaprint dca dvbpsi dvdcss 

Re: [oi-dev] libjpeg-turbo and VLC

[bentahyr]

I made some tests, these are some minor (integration) issues I noticed :

- When I insert  a DVD, the icon appears on the desktop, if I right click and 
do "Open with/vlc", vlc fails with the following logs :
[08062798] core libvlc: Lancement de vlc avec l'interface par défaut. Utilisez 
« cvlc » pour démarrer VLC sans interface.
libdvdnav: Using dvdnav version 5.0.3
libdvdread: Encrypted DVD support unavailable.
libdvdread: Attempting to use device /dev/rdsk/c3t2d0s2 mounted on 
/media/TINTIN_MYSTERY_GOLDEN_FLEECE for CSS authentication
libdvdnav: Can't read name block. Probably not a DVD-ROM device.
libdvdnav: vm: dvd_read_name failed
libdvdnav: DVD disk reports itself with Region mask 0x00f5. Regions: 2 4
[083bc530] core input error: ES_OUT_RESET_PCR called
[083bc530] core input error: ES_OUT_RESET_PCR called

If I start it from the command line using  "vlc dvd:///dev/rdsk/c3t2d0s2" it 
work fine (I still have these core input error message but it works.

As general, if I right click a media and choose Open with VLC, it will pop up 
and disapear immediatly.

I noticed as well playing a cd audio failed for right reasons (for rythmbox and 
totem as well, maybe more behind).

Otherwise, it played anything. Good job.. outstanding, really.

- Mail original -
De: benta...@chez.com
À: "OpenIndiana Developer mailing list" 
Envoyé: Dimanche 10 Janvier 2016 16:43:05
Objet: Re: [oi-dev] libjpeg-turbo and VLC

Hi,
I plugged the hardware and was about to test vlc.
I noticed the package vlc v2.2.1 in hipster-encumbered. I tried to installed it 
but when I do so it pulls out :
- postgres libs
database/postgres-93/library 9.3.10-2015.0.2.0
- nvidia graphic
driver/graphics/nvidia 0.340.93-2015.0.1.0

If the first one in not really an issue but rather a matter of curiosity, why 
and where the dependency comes from.
The second is an issue as I use an old graphic card (Nvidia Quadro FX3500), I 
need an old driver (v304 is the latest that support this graphic card). I'm 
just wondering where this dependency comes from as well ?

Best regards.
Franck

- Mail original -
De: benta...@chez.com
À: "OpenIndiana Developer mailing list" 
Envoyé: Mardi 22 Décembre 2015 15:18:13
Objet: Re: [oi-dev] libjpeg-turbo and VLC

Hi,

I performed some additional tests and they went fine decoding any video from 
"Vidéo for Everybody" test page but performance was underneath firefox 
(framerate, slugish video).
I couldn't play a dvd due to rights and access to DVD drive through virtualbox.

I really need to test on hardware for DVD and performance. I'll see that after 
new years day.
It looks very promising to me.

Best regards.
Ben

- Mail original -
De: benta...@chez.com
À: "OpenIndiana Developer mailing list" 
Envoyé: Vendredi 18 Décembre 2015 11:38:17
Objet: Re: [oi-dev] libjpeg-turbo and VLC

Hi,
I'm kind of digging out this but as I'm slow to do things.
I did a compile of vlc out of the oi-userland component you made and it 
compiled fine.

I tried a few video and old stuff MPEG, mp3,.. are fine.
Regarding MP4 (x264) I have issues (XCB messages in console) but I'm not sure 
how much the "run in vbox" situation is responsible from that.
I'll try more tests with DVDs next week.
After end of year break, I'll be able to test based on hardware rather than 
virtual machine.

Like I said, I amazed how you guys caught back on those key softwares.

Best regards.
Ben

- Mail original -
De: "Aurélien Larcher" 
À: "OpenIndiana Developer mailing list" 
Envoyé: Samedi 12 Décembre 2015 14:31:10
Objet: Re: [oi-dev] libjpeg-turbo and VLC



Hello, 






- navigator 

Firefox 43 beta is available on Hipster: 
http://www.openindiana.org/2015/11/30/firefox-43b/ 



- office suite 



LibreOffice available from SFE: sfe.opencsw.org 



- multimedia player 



VLC 2.2.1 soon I promise ;) 



I think we cover nearly 80% of generic desktop computer needs. 



So we are almost good ? ;) 



I'll try my best to contribute, the very few hours per week I got have been 
diverted by a SGI Octane lately, I have to focus on tiny things I can achieve. 



Oh an Octane, nice :) I just have Indies and O2s, not super beefy. 


I submitted a PR for IJG's libjpeg: 

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

but I am confused.. I do not know what it is the best option... 

Best regards, 


Aurelien 



Best regards 
Ben 

- Mail original - 
De: "Aurélien Larcher" < aurelien.larc...@gmail.com > 
À: "OpenIndiana Developer mailing list" < oi-dev@openindiana.org > 
Envoyé: Samedi 12 Décembre 2015 05:40:40 
Objet: Re: [oi-dev] libjpeg-turbo and VLC 




Hi, 
maybe are you missing the hipster-encumbered repository ? 

http://pkg.openindiana.org/hipster-encumbered/en/index.shtml 

Some libs are still missing (like live55) but they are only optional. 

The only showstopper is that VLC uses libjpeg-turbo's 

Re: [oi-dev] libjpeg-turbo and VLC

[bentahyr]

Hi,

I performed some additional tests and they went fine decoding any video from 
"Vidéo for Everybody" test page but performance was underneath firefox 
(framerate, slugish video).
I couldn't play a dvd due to rights and access to DVD drive through virtualbox.

I really need to test on hardware for DVD and performance. I'll see that after 
new years day.
It looks very promising to me.

Best regards.
Ben

- Mail original -
De: benta...@chez.com
À: "OpenIndiana Developer mailing list" 
Envoyé: Vendredi 18 Décembre 2015 11:38:17
Objet: Re: [oi-dev] libjpeg-turbo and VLC

Hi,
I'm kind of digging out this but as I'm slow to do things.
I did a compile of vlc out of the oi-userland component you made and it 
compiled fine.

I tried a few video and old stuff MPEG, mp3,.. are fine.
Regarding MP4 (x264) I have issues (XCB messages in console) but I'm not sure 
how much the "run in vbox" situation is responsible from that.
I'll try more tests with DVDs next week.
After end of year break, I'll be able to test based on hardware rather than 
virtual machine.

Like I said, I amazed how you guys caught back on those key softwares.

Best regards.
Ben

- Mail original -
De: "Aurélien Larcher" 
À: "OpenIndiana Developer mailing list" 
Envoyé: Samedi 12 Décembre 2015 14:31:10
Objet: Re: [oi-dev] libjpeg-turbo and VLC



Hello, 






- navigator 

Firefox 43 beta is available on Hipster: 
http://www.openindiana.org/2015/11/30/firefox-43b/ 



- office suite 



LibreOffice available from SFE: sfe.opencsw.org 



- multimedia player 



VLC 2.2.1 soon I promise ;) 



I think we cover nearly 80% of generic desktop computer needs. 



So we are almost good ? ;) 



I'll try my best to contribute, the very few hours per week I got have been 
diverted by a SGI Octane lately, I have to focus on tiny things I can achieve. 



Oh an Octane, nice :) I just have Indies and O2s, not super beefy. 


I submitted a PR for IJG's libjpeg: 

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

but I am confused.. I do not know what it is the best option... 

Best regards, 


Aurelien 



Best regards 
Ben 

- Mail original - 
De: "Aurélien Larcher" < aurelien.larc...@gmail.com > 
À: "OpenIndiana Developer mailing list" < oi-dev@openindiana.org > 
Envoyé: Samedi 12 Décembre 2015 05:40:40 
Objet: Re: [oi-dev] libjpeg-turbo and VLC 




Hi, 
maybe are you missing the hipster-encumbered repository ? 

http://pkg.openindiana.org/hipster-encumbered/en/index.shtml 

Some libs are still missing (like live55) but they are only optional. 

The only showstopper is that VLC uses libjpeg-turbo's jpeg_mem_src so I 
prepared several libjpeg components to provide IJG's and the Turbo 
implementations in separate subdirectory. 

If you have the time, you can contribute the missing optional libraries listed 
here: 

http://wiki.openindiana.org/oi/Multimedia 


After adding libjpeg-turbo with 6b compliance, VLC 2.2.1 compile out of the box 
provided that you add some flags: 

CFLAGS=" -DLUA_COMPAT_ALL=1 -DGL_GLEXT_PROTOTYPES -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 " 


The first is to enable backward compatibility mode with Lua 5.1, but I think 
our 5.2 needs recompile with the backward compatibility flag. 

The second is to address a compilation error. 

The last bits are to make sure that the macros is declared in a consistent way 
but I am not sure that is the case as some warnings still show up. 


If you have more time than I have, I can push my VLC branch so that you can 
finish up the component and test with the optional libraries. 

But before we can add VLC to oi-userland/encumbered, I need to push the libjpeg 
components in any case. 
Best regards 

Aurélien 










On Fri, Dec 11, 2015 at 1:27 AM, < benta...@chez.com > wrote: 


Hi Aurélien, 

This is great news. 
I tried myself and my results are way less optimistic than yours. 
How did you compiled the libraries necessary for VLC ? 
After installing all I could from repo, I'm still left to compile the following 
: 
a52 bluray caca chromaprint dca dvbpsi dvdcss dvdnav dvdread faad2 \ 
ffmpeg fluid gme goom gsm jpeg kate \ 
lame libmpeg2 live555 mad matroska modplug mpcdec nettle \ 
postproc shout sidplay2 taglib twolame upnp vncserver vpx x264 x265 zvbi 

I know I can live without the blueray support even if it would be nice to have 
but DVD/x264 seem to me quite important. 

Did you compile those ? Did you got them from SFE ? 

Best regards. 
Ben 

- Mail original - 
De: "Aurélien Larcher" < aurelien.larc...@gmail.com > 
À: "OpenIndiana Developer mailing list" < oi-dev@openindiana.org > 
Envoyé: Jeudi 3 Décembre 2015 08:56:18 
Objet: [oi-dev] libjpeg-turbo and VLC 













Hello, 
this afternoon I compiled VLC 2.2.1 quick and dirty (no patching involved \o/) 
for use on my (work-)workstation. This was made easier thanks to: 

- update of gnu-gettext 0.19.6 by Alexander [1] 
- 

Re: [oi-dev] libjpeg-turbo and VLC

[bentahyr]

Hi,
I'm kind of digging out this but as I'm slow to do things.
I did a compile of vlc out of the oi-userland component you made and it 
compiled fine.

I tried a few video and old stuff MPEG, mp3,.. are fine.
Regarding MP4 (x264) I have issues (XCB messages in console) but I'm not sure 
how much the "run in vbox" situation is responsible from that.
I'll try more tests with DVDs next week.
After end of year break, I'll be able to test based on hardware rather than 
virtual machine.

Like I said, I amazed how you guys caught back on those key softwares.

Best regards.
Ben

- Mail original -
De: "Aurélien Larcher" 
À: "OpenIndiana Developer mailing list" 
Envoyé: Samedi 12 Décembre 2015 14:31:10
Objet: Re: [oi-dev] libjpeg-turbo and VLC



Hello, 






- navigator 

Firefox 43 beta is available on Hipster: 
http://www.openindiana.org/2015/11/30/firefox-43b/ 



- office suite 



LibreOffice available from SFE: sfe.opencsw.org 



- multimedia player 



VLC 2.2.1 soon I promise ;) 



I think we cover nearly 80% of generic desktop computer needs. 



So we are almost good ? ;) 



I'll try my best to contribute, the very few hours per week I got have been 
diverted by a SGI Octane lately, I have to focus on tiny things I can achieve. 



Oh an Octane, nice :) I just have Indies and O2s, not super beefy. 


I submitted a PR for IJG's libjpeg: 

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

but I am confused.. I do not know what it is the best option... 

Best regards, 


Aurelien 



Best regards 
Ben 

- Mail original - 
De: "Aurélien Larcher" < aurelien.larc...@gmail.com > 
À: "OpenIndiana Developer mailing list" < oi-dev@openindiana.org > 
Envoyé: Samedi 12 Décembre 2015 05:40:40 
Objet: Re: [oi-dev] libjpeg-turbo and VLC 




Hi, 
maybe are you missing the hipster-encumbered repository ? 

http://pkg.openindiana.org/hipster-encumbered/en/index.shtml 

Some libs are still missing (like live55) but they are only optional. 

The only showstopper is that VLC uses libjpeg-turbo's jpeg_mem_src so I 
prepared several libjpeg components to provide IJG's and the Turbo 
implementations in separate subdirectory. 

If you have the time, you can contribute the missing optional libraries listed 
here: 

http://wiki.openindiana.org/oi/Multimedia 


After adding libjpeg-turbo with 6b compliance, VLC 2.2.1 compile out of the box 
provided that you add some flags: 

CFLAGS=" -DLUA_COMPAT_ALL=1 -DGL_GLEXT_PROTOTYPES -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 " 


The first is to enable backward compatibility mode with Lua 5.1, but I think 
our 5.2 needs recompile with the backward compatibility flag. 

The second is to address a compilation error. 

The last bits are to make sure that the macros is declared in a consistent way 
but I am not sure that is the case as some warnings still show up. 


If you have more time than I have, I can push my VLC branch so that you can 
finish up the component and test with the optional libraries. 

But before we can add VLC to oi-userland/encumbered, I need to push the libjpeg 
components in any case. 
Best regards 

Aurélien 










On Fri, Dec 11, 2015 at 1:27 AM, < benta...@chez.com > wrote: 


Hi Aurélien, 

This is great news. 
I tried myself and my results are way less optimistic than yours. 
How did you compiled the libraries necessary for VLC ? 
After installing all I could from repo, I'm still left to compile the following 
: 
a52 bluray caca chromaprint dca dvbpsi dvdcss dvdnav dvdread faad2 \ 
ffmpeg fluid gme goom gsm jpeg kate \ 
lame libmpeg2 live555 mad matroska modplug mpcdec nettle \ 
postproc shout sidplay2 taglib twolame upnp vncserver vpx x264 x265 zvbi 

I know I can live without the blueray support even if it would be nice to have 
but DVD/x264 seem to me quite important. 

Did you compile those ? Did you got them from SFE ? 

Best regards. 
Ben 

- Mail original - 
De: "Aurélien Larcher" < aurelien.larc...@gmail.com > 
À: "OpenIndiana Developer mailing list" < oi-dev@openindiana.org > 
Envoyé: Jeudi 3 Décembre 2015 08:56:18 
Objet: [oi-dev] libjpeg-turbo and VLC 













Hello, 
this afternoon I compiled VLC 2.2.1 quick and dirty (no patching involved \o/) 
for use on my (work-)workstation. This was made easier thanks to: 

- update of gnu-gettext 0.19.6 by Alexander [1] 
- support of strerror_l to illumos [2] 

The only issue was that our libjpeg6b is quite old and not compatible with VLC, 
installing libjpeg-turbo (which is libjpeg8 compliant) solved the problem. 

Is it realistic to consider modifiying the libjpeg component and use 
libjpeg-turbo with v8 compatility as drop-in replacement ? The performance 
difference is quite impressive. 


VLC 2.2.1 just works fine, the only issue related to loading the Lua plugin is 
not OI specific and to be fixed upstream. 
Best regards 

Aurelien 






[1] https://github.com/OpenIndiana/oi-userland/pull/1544 
[2] 

Re: [oi-dev] libjpeg-turbo and VLC

[bentahyr]

Aurélien,

I have as well the LUA and QT messages but I "discarded" them as you mentioned 
it in previous post.
I haven't gone through the issues in VLC/LUA bug report systems to see how 
things were going upstream yet.

The more time I spend with the git repos (oi-userland/oi-hipster), the more I 
understand them and how to use/manipulate them.
I hope to reach the point of being able to produce components myself.

Ben

- Mail original -
De: "Aurélien Larcher" 
À: "OpenIndiana Developer mailing list" 
Envoyé: Vendredi 18 Décembre 2015 13:19:06
Objet: Re: [oi-dev] libjpeg-turbo and VLC




Hello, 
thanks for your feedback ! 







I did a compile of vlc out of the oi-userland component you made and it 
compiled fine. 



Cool :) I like using oi-userland like a ports system to install stuff locally, 
with the time I find it really easy going. 



I tried a few video and old stuff MPEG, mp3,.. are fine. 


Regarding MP4 (x264) I have issues (XCB messages in console) but I'm not sure 
how much the "run in vbox" situation is responsible from that. 



I tried also a few format and so far did not have issues playing local files 
but less sucess opening some streams. 


I woud like to fix the lua plugin issue as well as some qt4 warnings. 




I'll try more tests with DVDs next week. 



Thank you ! 



Like I said, I amazed how you guys caught back on those key softwares. 



Alexander did a very good thing pushing oi-userland forward to allow easy 
contribution process, let us hope that more people will git clone oi-userland 
and jump aboard ! 


Best regards 


Aurelien 




Best regards. 
Ben 

- Mail original - 
De: "Aurélien Larcher" < aurelien.larc...@gmail.com > 
À: "OpenIndiana Developer mailing list" < oi-dev@openindiana.org > 
Envoyé: Samedi 12 Décembre 2015 14:31:10 


Objet: Re: [oi-dev] libjpeg-turbo and VLC 



Hello, 






- navigator 

Firefox 43 beta is available on Hipster: 
http://www.openindiana.org/2015/11/30/firefox-43b/ 



- office suite 



LibreOffice available from SFE: sfe.opencsw.org 



- multimedia player 



VLC 2.2.1 soon I promise ;) 



I think we cover nearly 80% of generic desktop computer needs. 



So we are almost good ? ;) 



I'll try my best to contribute, the very few hours per week I got have been 
diverted by a SGI Octane lately, I have to focus on tiny things I can achieve. 



Oh an Octane, nice :) I just have Indies and O2s, not super beefy. 


I submitted a PR for IJG's libjpeg: 

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

but I am confused.. I do not know what it is the best option... 

Best regards, 


Aurelien 



Best regards 
Ben 

- Mail original - 
De: "Aurélien Larcher" < aurelien.larc...@gmail.com > 
À: "OpenIndiana Developer mailing list" < oi-dev@openindiana.org > 
Envoyé: Samedi 12 Décembre 2015 05:40:40 
Objet: Re: [oi-dev] libjpeg-turbo and VLC 




Hi, 
maybe are you missing the hipster-encumbered repository ? 

http://pkg.openindiana.org/hipster-encumbered/en/index.shtml 

Some libs are still missing (like live55) but they are only optional. 

The only showstopper is that VLC uses libjpeg-turbo's jpeg_mem_src so I 
prepared several libjpeg components to provide IJG's and the Turbo 
implementations in separate subdirectory. 

If you have the time, you can contribute the missing optional libraries listed 
here: 

http://wiki.openindiana.org/oi/Multimedia 


After adding libjpeg-turbo with 6b compliance, VLC 2.2.1 compile out of the box 
provided that you add some flags: 

CFLAGS=" -DLUA_COMPAT_ALL=1 -DGL_GLEXT_PROTOTYPES -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 " 


The first is to enable backward compatibility mode with Lua 5.1, but I think 
our 5.2 needs recompile with the backward compatibility flag. 

The second is to address a compilation error. 

The last bits are to make sure that the macros is declared in a consistent way 
but I am not sure that is the case as some warnings still show up. 


If you have more time than I have, I can push my VLC branch so that you can 
finish up the component and test with the optional libraries. 

But before we can add VLC to oi-userland/encumbered, I need to push the libjpeg 
components in any case. 
Best regards 

Aurélien 










On Fri, Dec 11, 2015 at 1:27 AM, < benta...@chez.com > wrote: 


Hi Aurélien, 

This is great news. 
I tried myself and my results are way less optimistic than yours. 
How did you compiled the libraries necessary for VLC ? 
After installing all I could from repo, I'm still left to compile the following 
: 
a52 bluray caca chromaprint dca dvbpsi dvdcss dvdnav dvdread faad2 \ 
ffmpeg fluid gme goom gsm jpeg kate \ 
lame libmpeg2 live555 mad matroska modplug mpcdec nettle \ 
postproc shout sidplay2 taglib twolame upnp vncserver vpx x264 x265 zvbi 

I know I can live without the blueray support even if it would be nice to have 
but DVD/x264 seem to me quite important. 

Did you compile 

Re: [oi-dev] libjpeg-turbo and VLC

[bentahyr]

Indeed I didn't have the encumbered repo.
I found about it after posting.

I installed Hipster on refurbished Ultra 20 and I'm pretty amazed of the work 
you guys have done.
If we have recent :
- navigator
- office suite
- multimedia player

I think we cover nearly 80% of generic desktop computer needs.
I'll try my best to contribute, the very few hours per week I got have been 
diverted by a SGI Octane lately, I have to focus on tiny things I can achieve.

Best regards
Ben

- Mail original -
De: "Aurélien Larcher" 
À: "OpenIndiana Developer mailing list" 
Envoyé: Samedi 12 Décembre 2015 05:40:40
Objet: Re: [oi-dev] libjpeg-turbo and VLC


Hi, 
maybe are you missing the hipster-encumbered repository ? 

http://pkg.openindiana.org/hipster-encumbered/en/index.shtml 

Some libs are still missing (like live55) but they are only optional. 

The only showstopper is that VLC uses libjpeg-turbo's jpeg_mem_src so I 
prepared several libjpeg components to provide IJG's and the Turbo 
implementations in separate subdirectory. 

If you have the time, you can contribute the missing optional libraries listed 
here: 

http://wiki.openindiana.org/oi/Multimedia 


After adding libjpeg-turbo with 6b compliance, VLC 2.2.1 compile out of the box 
provided that you add some flags: 

CFLAGS=" -DLUA_COMPAT_ALL=1 -DGL_GLEXT_PROTOTYPES -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 " 


The first is to enable backward compatibility mode with Lua 5.1, but I think 
our 5.2 needs recompile with the backward compatibility flag. 

The second is to address a compilation error. 

The last bits are to make sure that the macros is declared in a consistent way 
but I am not sure that is the case as some warnings still show up. 


If you have more time than I have, I can push my VLC branch so that you can 
finish up the component and test with the optional libraries. 

But before we can add VLC to oi-userland/encumbered, I need to push the libjpeg 
components in any case. 
Best regards 

Aurélien 










On Fri, Dec 11, 2015 at 1:27 AM, < benta...@chez.com > wrote: 


Hi Aurélien, 

This is great news. 
I tried myself and my results are way less optimistic than yours. 
How did you compiled the libraries necessary for VLC ? 
After installing all I could from repo, I'm still left to compile the following 
: 
a52 bluray caca chromaprint dca dvbpsi dvdcss dvdnav dvdread faad2 \ 
ffmpeg fluid gme goom gsm jpeg kate \ 
lame libmpeg2 live555 mad matroska modplug mpcdec nettle \ 
postproc shout sidplay2 taglib twolame upnp vncserver vpx x264 x265 zvbi 

I know I can live without the blueray support even if it would be nice to have 
but DVD/x264 seem to me quite important. 

Did you compile those ? Did you got them from SFE ? 

Best regards. 
Ben 

- Mail original - 
De: "Aurélien Larcher" < aurelien.larc...@gmail.com > 
À: "OpenIndiana Developer mailing list" < oi-dev@openindiana.org > 
Envoyé: Jeudi 3 Décembre 2015 08:56:18 
Objet: [oi-dev] libjpeg-turbo and VLC 













Hello, 
this afternoon I compiled VLC 2.2.1 quick and dirty (no patching involved \o/) 
for use on my (work-)workstation. This was made easier thanks to: 

- update of gnu-gettext 0.19.6 by Alexander [1] 
- support of strerror_l to illumos [2] 

The only issue was that our libjpeg6b is quite old and not compatible with VLC, 
installing libjpeg-turbo (which is libjpeg8 compliant) solved the problem. 

Is it realistic to consider modifiying the libjpeg component and use 
libjpeg-turbo with v8 compatility as drop-in replacement ? The performance 
difference is quite impressive. 


VLC 2.2.1 just works fine, the only issue related to loading the Lua plugin is 
not OI specific and to be fixed upstream. 
Best regards 

Aurelien 






[1] https://github.com/OpenIndiana/oi-userland/pull/1544 
[2] 
https://github.com/illumos/illumos-gate/commit/b599bd937c305a895426e8c412ca920ce7824850
 






-- 




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


-- 




--- 
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] libjpeg-turbo and VLC

[bentahyr]

Hi Aurélien,

This is great news.
I tried myself and my results are way less optimistic than yours.
How did you compiled the libraries necessary for VLC ?
After installing all I could from repo, I'm still left to compile the following 
:
a52 bluray caca chromaprint dca dvbpsi dvdcss dvdnav dvdread faad2 \
ffmpeg fluid gme goom gsm jpeg kate \
lame libmpeg2 live555 mad matroska modplug mpcdec nettle \
postproc shout sidplay2 taglib twolame upnp vncserver vpx x264 x265 zvbi

I know I can live without the blueray support even if it would be nice to have 
but DVD/x264 seem to me quite important.

Did you compile those ? Did you got them from SFE ?

Best regards.
Ben

- Mail original -
De: "Aurélien Larcher" 
À: "OpenIndiana Developer mailing list" 
Envoyé: Jeudi 3 Décembre 2015 08:56:18
Objet: [oi-dev] libjpeg-turbo and VLC











Hello, 
this afternoon I compiled VLC 2.2.1 quick and dirty (no patching involved \o/) 
for use on my (work-)workstation. This was made easier thanks to: 

- update of gnu-gettext 0.19.6 by Alexander [1] 
- support of strerror_l to illumos [2] 

The only issue was that our libjpeg6b is quite old and not compatible with VLC, 
installing libjpeg-turbo (which is libjpeg8 compliant) solved the problem. 

Is it realistic to consider modifiying the libjpeg component and use 
libjpeg-turbo with v8 compatility as drop-in replacement ? The performance 
difference is quite impressive. 


VLC 2.2.1 just works fine, the only issue related to loading the Lua plugin is 
not OI specific and to be fixed upstream. 
Best regards 

Aurelien 






[1] https://github.com/OpenIndiana/oi-userland/pull/1544 
[2] 
https://github.com/illumos/illumos-gate/commit/b599bd937c305a895426e8c412ca920ce7824850
 






-- 




--- 
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] Effort focus

[bentahyr]

Hi Aurélien,

I actually didn't meet this issue as I partially built MATE against GTK2.
I supposed I assumed that building something that looks like Gnome 2 would be 
easier on a platform that supports Gnome 2 already.
This was my first mistake learning wisdom is a long path.

These dependencies are related to GTK3, when I come back in September I'll try 
to set up a GTK3 build.
Then, I'll see what breaks.

Desktop wise, I was thinking would it be wiser to keep a close look to what the 
BSD guys are doing as they have the same issue than OI which is more and more 
dependencies on linux core features (systemd, udev, 
authentication/authorisation mechanism,... ).

Best regards.
Ben

- Mail original -
De: Aurélien Larcher aurelien.larc...@gmail.com
À: OpenIndiana Developer mailing list oi-dev@openindiana.org
Envoyé: Mardi 28 Juillet 2015 02:20:24
Objet: Re: [oi-dev] Effort focus






Hello, 

Welcome Ben ! 
I also tried to build MATE but I encountered dependency issues immediately. 
atk 2.14 would be a first target [2] but requires also building a newer 
gobject-introspection and make sure that nothing breaks. 

Best regards 


Aurelien 


[1] http://wiki.openindiana.org/oi/MATE+1.10+Sandbox 
[2] https://www.illumos.org/issues/6055 







On Mon, Jul 27, 2015 at 11:39 AM,  benta...@chez.com  wrote: 


Having GTK3 spec files are a good news. I'll focus on that then so we got a 
GTK3 to build on. 

I'll leave MATE aside for the moment as we have a working desktop. 
GTK3 will open more option to desktops alternative or application. 

Best regards. 
Franck 

- Mail original - 
De: Alexander Pyhalov  a...@rsu.ru  
À: OpenIndiana Developer mailing list  oi-dev@openindiana.org  
Cc: benta...@chez.com 
Envoyé: Lundi 27 Juillet 2015 17:17:09 
Objet: Re: [oi-dev] Effort focus 

benta...@chez.com писал 27.07.2015 07 :21: 
 Hi, 
 
 I've been trying for the last 2 month to get some updates to OI in 
 particular Hipster. 
 I tried to update the DE by compiling MATE, then I tried to get an 
 alternative browser to work copnsidering the issue with Firefox and 
 started to compile Midori. 
 
 Of course, MATE is a hell to compile as it is fragmented all over the 
 place with each modules having its on dependencies. But I reach an 
 interesting point where quite a lot of application were compile but 
 not the main modules (panel, ...) 
 
 Midori is hard on dependencies as well (GTK+3 - Glib - automake,) 
 
 I have a very limited time to dedicate (and skills, I have to admit) 
 and would like to make the best out of it so I ask you. 
 Does it make sense to try to get MATE up and running to replace GNOME 
 2, or get another type desktop, or keep the current one ? 
 Midori has already moved to GTK+3 and more and more applications are 
 designed on top of it, does it make sense to focus the effort on 
 building a functionnal GTK+3 on OI as a starting point ? 

Hi. 
I think that MATE would be a valuable thing, and it worth to try making 
it work, 
but you can underestimate the work wich is necessary to make it 
functional. 

What about GTK3, you can look at 
https://java.net/projects/solaris-desktop/sources/spec-files/ , 
it has base-specs/gtk3.spec, SUNWgtk3.spec and SUNWgtk3-engines.spec. 
They are a valuable starting point. Note, that I couldn't find when you 
can witch branches 
int web ui, perhaps you'll have to clone the repo and switch manually to 
gnome-2-30-s12 
branch to see the specs. 

--- 
System Administrator of Southern Federal University Computer Center 



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


-- 


--- 
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] Effort focus

[bentahyr]

Having GTK3 spec files are a good news. I'll focus on that then so we got a 
GTK3 to build on.

I'll leave MATE aside for the moment as we have a working desktop.
GTK3 will open more option to desktops alternative or application.

Best regards.
Franck

- Mail original -
De: Alexander Pyhalov a...@rsu.ru
À: OpenIndiana Developer mailing list oi-dev@openindiana.org
Cc: benta...@chez.com
Envoyé: Lundi 27 Juillet 2015 17:17:09
Objet: Re: [oi-dev] Effort focus

benta...@chez.com писал 27.07.2015 07:21:
 Hi,
 
 I've been trying for the last 2 month to get some updates to OI in
 particular Hipster.
 I tried to update the DE by compiling MATE, then I tried to get an
 alternative browser to work copnsidering the issue with Firefox and
 started to compile Midori.
 
 Of course, MATE is a hell to compile as it is fragmented all over the
 place with each modules having its on dependencies. But I reach an
 interesting point where quite a lot of application were compile but
 not the main modules (panel, ...)
 
 Midori is hard on dependencies as well (GTK+3 - Glib - automake,)
 
 I have a very limited time to dedicate (and skills, I have to admit)
 and would like to make the best out of it so I ask you.
 Does it make sense to try to get MATE up and running to replace GNOME
 2, or get another type desktop, or keep the current one ?
 Midori has already moved to GTK+3 and more and more applications are
 designed on top of it, does it make sense to focus the effort on
 building a functionnal GTK+3 on OI as a starting point ?

Hi.
I think that MATE would be a valuable thing, and it worth to try making 
it work,
but you can underestimate the work wich is necessary to make it 
functional.

What about GTK3, you can look at 
https://java.net/projects/solaris-desktop/sources/spec-files/ ,
it has base-specs/gtk3.spec, SUNWgtk3.spec and SUNWgtk3-engines.spec.
They are a valuable starting point. Note, that I couldn't find when you 
can witch branches
int web ui, perhaps you'll have to clone the repo and switch manually to 
gnome-2-30-s12
branch to see the specs.

---
System Administrator of Southern Federal University Computer Center



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

Re: [oi-dev] Effort focus

[bentahyr]

Sorry, my English is really bad.. I'll try to re-read my next post a few time 
next time.

Best regards.
Ben

- Mail original -
De: benta...@chez.com
À: oi-dev@openindiana.org
Envoyé: Lundi 27 Juillet 2015 16:19:23
Objet: [oi-dev] Effort focus

Hi,

I've been trying for the last 2 month to get some updates to OI in particular 
Hipster.
I tried to update the DE by compiling MATE, then I tried to get an alternative 
browser to work copnsidering the issue with Firefox and started to compile 
Midori.

Of course, MATE is a hell to compile as it is fragmented all over the place 
with each modules having its on dependencies. But I reach an interesting point 
where quite a lot of application were compile but not the main modules (panel, 
...)

Midori is hard on dependencies as well (GTK+3 - Glib - automake,)

I have a very limited time to dedicate (and skills, I have to admit) and would 
like to make the best out of it so I ask you.
Does it make sense to try to get MATE up and running to replace GNOME 2, or get 
another type desktop, or keep the current one ?
Midori has already moved to GTK+3 and more and more applications are designed 
on top of it, does it make sense to focus the effort on building a functionnal 
GTK+3 on OI as a starting point ?

In other words, what would be the most interesting thing ?

Ben

___
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