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

[Albert Lee]

On Fri, Feb 14, 2014 at 10:23 AM, Keith Wesolowski
 wrote:
> On Thu, Feb 13, 2014 at 11:52:53PM -0500, Gordon Ross wrote:
>
>> I'm not sure if you were aware of this, but the GSoC program
>> organizers have in the past expressed a prefer that related projects
>> "band together" with shared applications.  That makes less work for
>> them.
>>
>> I recommend we tell GSoC in our application that we will entertain
>> projects using any and all illumos distributions.
>> OpenIndiana is one of several good choices.  I see no harm in
>> mentioning their inclusion.
>> Would you be more comfortable if we mentioned other open-source distros as 
>> well?
>
> I'll turn that on its head: would everyone else be comfortable with the
> addition of SmartOS-specific work to the projects list?  I certainly
> would not be, if I were a partisan of a different distribution.  And I
> don't even consider most of the projects the OI folks have listed as
> being in any way related to the development of an operating system (nor
> would many SmartOS-specific projects I might come up with).
>

I think this view is overly narrow of related communities. A stated
goal is to attract high quality active contributors. My criteria for
involvement in GSoC would be not be my perception of merit of the
project per se, but whether the project allows people to demonstrate
skills that we do value, and the availability and interest of mentors
with established technical credentials.

-Albert

-- 
Albert Lee 
Nexenta Systems, Inc.

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

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

[Albert Lee]

On Thu, Feb 13, 2014 at 11:02 AM, Garrett D'Amore
wrote:

>
> We have about 24 hours to decide whether we are going to do GSoC this year.
>
> Do we have mentoring volunteers and a coordinator willing to do so, and
> with sufficient time?  I can mentor someone in So Cal, but experience is
> that most candidates for GSoC come from overseas.
>
>
After talking to others, I've been convinced that it's a good idea to
continue participating this year, and I'm willing to be the organisation
admin provided we try to size projects appropriately to account for risk,
testing and review. I'm working on the application.

If anyone has strong objections let me know. If OI is interested in
applying as well we should coordinate to see if a combined application is
appropriate. Slots can be divided amongst the respective mentors.

Gordon has volunteered as a mentor.

-Albert

-- 
Albert Lee 
Nexenta Systems, Inc. <http://www.nexenta.com>
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] feature.h and __XOPEN_SOURCE_EXTENDED

[Albert Lee]

On Thu, Jun 6, 2013 at 5:15 AM, Alexander Pyhalov  wrote:

> Ok, while building ncurses I encountered the following problem.
>
> It seems that a lot of projects define __XOPEN_SOURCE_EXTENDED macros.
> When it is tested in feature_tests.h the value of __XOPEN_SOURCE is
> ignored, and we have problems - _XPG5 is not defined for gcc 3.4 and _XPG5
> and _XPG6 are not defined for gcc4.7.
> So, we miss some declarations in wchar.h/wchar_iso.h
> for example because of  the following macro
> #if (!defined(_XPG4) && !defined(_XPG4_2) || defined(_XPG5))
>
> and possibly receive the following error with gcc 4.7 from feature_test.h:
>
> if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6))
> #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \
> and pre-2001 POSIX applications"
>
> It seems the following patch solves the problem.
> Is it a correct solution or I just don't see potential problems?
> Or, alternavely we could add && (_XOPEN_SOURCE - 0 < 500) condition to
>
> #elif (defined(_XOPEN_SOURCE) && _XOPEN_SOURCE_EXTENDED - 0 == 1)
>
>
This condition is used in the first #if branch.
>
> --- 
> /export/home/build/srcs/**illumos-gate/usr/src/uts/**common/sys/feature_tests.h
> 2013-05-29 16:15:49.497379177 +0400
> +++ /usr/include/sys/feature_**tests.h2013-06-06 12:57:43.994292322
> +0400
> @@ -275,8 +275,9 @@
>  #define_XPG4_2
>  #define_XPG4
>  #define_XPG3
> +#endif
>  /* X/Open CAE Specification, Issue 5 */
> -#elif  (_XOPEN_SOURCE - 0 == 500)
> +#if(_XOPEN_SOURCE - 0 == 500)
>  #define_XPG5
>  #define_XPG4_2
>  #define_XPG4
>
>
Alternatively, you could reverse the order of the conditional blocks. I'm
not sure what the implications of defining _XPG3 as well as _XPG5 are
offhand.

-Albert

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

Re: [oi-dev] [discuss] Re: hit problem when make iso image, is there anyone could help me?

[Albert Lee]

You need to use a full set of consolidations to build an image, not just
ON. And you need an updated 'entire' if you want to use your on-nightly
osnet incorporation in it.

Packaging questions should be directed to oi-dev.

-Albert

On Tue, Mar 5, 2013 at 8:40 AM, Put FreeBSD/TonyBSD to Work for Your
Business.  wrote:

> is there no people hit similar issue?
>
> Thanks
> Tony
>
>
> On Mon, Mar 4, 2013 at 7:34 AM, Put FreeBSD/TonyBSD to Work for Your
> Business.  wrote:
>
>> Hello everyone,
>>
>>
>> (sorry for any interruptions, I'm not sure if it is correct to send my
>> question to this mail list.)
>>
>>
>> now, I have built illumos from source and succeeded on Openindiana, I
>> want to make a ISO image to test the latest build.
>>
>> uname -a
>> SunOS solx 5.11 oi_151a7 i86pc i386 i86pc Solaris
>>
>>
>> the problem is that:  when I run following command, and get error, (I
>> need help to resolve the issues)
>>
>>
>> following is my screen dump, is there someone could help me  resolve it?
>>
>>
>> root@solx:~# /usr/bin/distro_const build /tmp/new_slim_cd_x86.xml
>>
>> /usr/share/distro_const/DC-
>> manifest.defval.xml validates
>> /tmp/new_slim_cd_x86_temp_22552.xml validates
>> Simple Log: /rpool/dc/logs/simple-log-2013-03-03-15-35-27
>> Detail Log: /rpool/dc/logs/detail-log-2013-03-03-15-35-27
>> Build started Sun Mar  3 15:35:27 2013
>> Distribution name: TEST-MARCH01
>> Build Area dataset: rpool/dc
>> Build Area mount point: /rpool/dc
>>  im-pop: Image area creation
>> Initializing the IPS package image area: /rpool/dc/build_data/pkg_image
>> Setting preferred publisher: on-nightly
>> Origin repository: http://localhost:8152
>> Verifying the contents of the IPS repository
>> pkg list: no packages matching 'pkg:/system/install/gui-install,
>> pkg:/entire, pkg:/slim_install, pkg:/system/install/media/internal' allowed
>> by installed incorporations, or image variants that are known or installed
>> Use -af to allow all versions.
>> Traceback (most recent call last):
>>   File "/usr/share/distro_const/im_pop.py", line 515, in 
>> "repository")
>> Exception: /usr/share/distro_const/im_pop.py: Unable to verify the
>> contents of the specified IPS repository
>> Child returned err 1
>> Build completed Sun Mar  3 15:35:30 2013
>> Build failed.
>> root@solx:~#
>>
>>
>> following is the lines I changed in new_slim_cd_x86.xml
>>
>>
>> 
>>
>>  
>> > url="http://localhost:8152";
>> authname="on-nightly"/>
>>
>>
>> the build software repository is :
>> /code/illumos-gate/packages/i386/nightly-nd/repo.redist
>>
>> root@solx:/code/illumos-gate/packages/i386/nightly-nd/repo.redist#
>> pkgrepo info -s "http://localhost:8152";
>> PUBLISHER  PACKAGES STATUS   UPDATED
>> on-nightly 839  online   2013-03-03T00:25:24.013482Z
>> root@solx:/code/illumos-gate/packages/i386/nightly-nd/repo.redist#
>> root@solx:/code/illumos-gate/packages/i386/nightly-nd/repo.redist# uname
>> -a
>> SunOS htsys 5.11 oi_151a7 i86pc i386 i86pc Solaris
>> root@solx:/code/illumos-gate/packages/i386/nightly-nd/repo.redist#
>>
>>
>>
>> Thanks and best wishes
>>
>> Tony
>>
>> On Mon, Mar 4, 2013 at 12:28 AM, Put FreeBSD/TonyBSD to Work for Your
>> Business.  wrote:
>>
>>> Hello everyone,
>>>
>>> sorry for any interruptions, I'm not sure if it is correct to send my
>>> question to this mail list.
>>>
>>> now, I have built illumos from source and succeeded on Openindiana, I
>>> want to make a ISO image to test the latest build.
>>>
>>> uname -a
>>> SunOS solx 5.11 oi_151a7 i86pc i386 i86pc Solaris
>>>
>>>
>>> the problem is that:  when I run following command, and get error, (I
>>> need help to resolve the issues)
>>>
>>> root@solx:~# /usr/bin/distro_const build /tmp/new_slim_cd_x86.xml
>>>
>>> /usr/share/distro_const/DC-manifest.defval.xml validates
>>> /tmp/new_slim_cd_x86_temp_22552.xml validates
>>> Simple Log: /rpool/dc/logs/simple-log-2013-03-03-15-35-27
>>> Detail Log: /rpool/dc/logs/detail-log-2013-03-03-15-35-27
>>> Build started Sun Mar  3 15:35:27 2013
>>> Distribution name: TEST-MARCH01
>>> Build Area dataset: rpool/dc
>>> Build Area mount point: /rpool/dc
>>>  im-pop: Image area creation
>>> Initializing the IPS package image area: /rpool/dc/build_data/pkg_image
>>> Setting preferred publisher: on-nightly
>>> Origin repository: http://localhost:8152
>>> Verifying the contents of the IPS repository
>>> pkg list: no packages matching 'pkg:/system/install/gui-install,
>>> pkg:/entire, pkg:/slim_install, pkg:/system/install/media/internal' allowed
>>> by installed incorporations, or image variants that are known or installed
>>> Use -af to allow all versions.
>>> Traceback (most recent call last):
>>>   File "/usr/share/distro_const/im_pop.py", line 515, in 
>>> "repository")
>>> Exception: /usr/share/distro_const/im_pop.py: Unable to verify the
>>> contents of the specified IPS repository
>>> Child returned e

Re: [oi-dev] status of lx brand

[Albert Lee]

Hi Carlos,

I previously created a code drop for reversing the lx brand backout. See
https://www.illumos.org/issues/104
I'm not sure if keremet used that or has done additional work.

develo...@lists.illumos.org would be more useful for questions about
branded zones.

Thanks,
-Albert

On Tue, Apr 3, 2012 at 12:51 PM, carlos antonio neira bustos <
cneirabus...@gmail.com> wrote:

> I already emailed keremet , So his version should be a good starting point
> to updating the lx brand?.Or I need to start all over pulling sources from
> onnv-b142(which  i think was the last before the lx brand was pulled out)
> ,because that is what I'm doing.
>
>
>
> On Tue, Apr 3, 2012 at 1:42 PM, Bayard G. Bell <
> buffer.g.overf...@gmail.com> wrote:
>
>> On Tue, 2012-04-03 at 19:40 +0300, Maxim Kondratovich wrote:
>> > Ask kere...@solaris.kirov.ru
>> > As I know he did it for oi151a but not updated for current prestable
>> release
>>
>> What I've seen is that keremet revived the version that wasn't
>> maintained and thus pulled from OpenSolaris. It's almost certainly not
>> going into OI unless there's a current and maintained version in the
>> upstream.
>>
>> > *From:* carlos antonio neira bustos 
>> > *Sent:* Tuesday, April 03, 2012 19:18 (UTC+0300)
>> > *To:* oi-dev@openindiana.org
>> > *Subject:* [oi-dev] status of lx brand
>> >
>> >
>> >
>> > > Hi All,
>> > >
>> > > I want to know if there some work being done on Resurrecting and
>> > > updating  the lx brand, I noticed that this is a project idea so i
>> > > wanted to know if someone is working on it,
>> > > because I started working on it a couple of days ago  and i don't want
>> > > to duplicate the efforts or step in someone else toes.
>> > >
>> > > Best Regards.
>>
>>
>>
>> ___
>> 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] About oi-build, oi-sfe, icore and illumos-userland

[Albert Lee]

On Sun, Nov 13, 2011 at 11:24 AM, Sriram Narayanan  wrote:
> How do these relate to each other ?
>
> Here's what I see:
> oi-build - > a build system (scripts, etc) which produce binaries
> icore -> something similar, but with the debian build system (similar
> to oi-build with respect to building packages), but with the goal of
> creating a deb based core distro
> oi-sfe -> hosted at illumos.org, but may have packages common with oi-build.
> illumos-userland -> may have packages common to oi-sfe and oi-build.
> iCore may use these.
>
> Is my understanding correct ?
>
> -- Sriram

illumian (formerly iCore) is a child of oi-build and other OI binary
packages, since oi-build doesn't cover the entire distribution yet. It
uses the same package metadata *and* data as OpenIndiana.

OI and illumos intend to migrate all of the common infrastructure from
oi-build to illumos-userland. Most likely, this means oi-build will be
basically renamed as OI remains responsible for the project. illumian
will branch from that to include Debian packaging specific changes.

oi-sfe is an unrelated project to deliver binaries from SFE.

-Albert

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

Re: [oi-dev] Illumos/OI Bug 1161 (nvidia crash)

[Albert Lee]

2011/7/1 Albert Lee :
> 2011/7/1 Hernán Saltiel :
>> On 07/01/2011 01:02 AM, Albert Lee wrote:
>>>
>>> 2011/6/30 Hernán Saltiel:
>>>>
>>>> Hi!
>>>> Finally I freezed my machine again (it does this randomly, so it took me
>>>> more time than expected).
>>>> My answers in between your lines.
>>>>
>>>> On 06/29/2011 08:42 AM, Julian Wiesener wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, 2011-06-29 at 00:15 -0300, Hernan Saltiel wrote:
>>>>>>
>>>>>> Nope...it hung again some minutes ago, having no visual effects
>>>>>> enabled.
>>>>>> Something makes it freeze the entire system.
>>>>>
>>>>> what does "freeze the entire system" mean?
>>>>
>>>> After trying some tricks, I realised that is not the entire system what
>>>> is
>>>> freezing, only the GUI.
>>>>>
>>>>> If you move the mouse, is the cursor still moving?
>>>>
>>>> No.
>>>>>
>>>>> Can you switch to a console?
>>>>
>>>> No.
>>>>>
>>>>> Can you remote login using ssh?
>>>>
>>>> Yes! It worked!
>>>>>
>>>>> If so, what happends if you restart gdm?
>>>>
>>>> It restarts, I can log in, and start my apps again.
>>>
>>> Can you save and attach your /var/log/Xorg.0.log after the freeze to
>>> the bug? (Xorg.0.log.old if you restart X).
>>>
>>> -Albert
>>>
>>> ___
>>> oi-dev mailing list
>>> oi-dev@openindiana.org
>>> http://openindiana.org/mailman/listinfo/oi-dev
>>
>> Hi Albert!
>> Attached you'll find my Xorg.0.log.old, and the new Xorg.0.log too.
>> Thanks for your help!
>> Best regards,
>>
>> HeCSa.
>>
>
> That Xorg.0.log.old is from a Linux system with some S3 card.
>

Nevermind, too many copies of Xorg.0.log.old locally.


Unfortunately, the X driver did not notice any problems at the time.
I'm starting to suspect there may be a common issue with compiz that
is affecting both Intel and NVIDIA cards, though.

-Albert

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

Re: [oi-dev] Illumos/OI Bug 1161 (nvidia crash)

[Albert Lee]

2011/7/1 Hernán Saltiel :
> On 07/01/2011 01:02 AM, Albert Lee wrote:
>>
>> 2011/6/30 Hernán Saltiel:
>>>
>>> Hi!
>>> Finally I freezed my machine again (it does this randomly, so it took me
>>> more time than expected).
>>> My answers in between your lines.
>>>
>>> On 06/29/2011 08:42 AM, Julian Wiesener wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Wed, 2011-06-29 at 00:15 -0300, Hernan Saltiel wrote:
>>>>>
>>>>> Nope...it hung again some minutes ago, having no visual effects
>>>>> enabled.
>>>>> Something makes it freeze the entire system.
>>>>
>>>> what does "freeze the entire system" mean?
>>>
>>> After trying some tricks, I realised that is not the entire system what
>>> is
>>> freezing, only the GUI.
>>>>
>>>> If you move the mouse, is the cursor still moving?
>>>
>>> No.
>>>>
>>>> Can you switch to a console?
>>>
>>> No.
>>>>
>>>> Can you remote login using ssh?
>>>
>>> Yes! It worked!
>>>>
>>>> If so, what happends if you restart gdm?
>>>
>>> It restarts, I can log in, and start my apps again.
>>
>> Can you save and attach your /var/log/Xorg.0.log after the freeze to
>> the bug? (Xorg.0.log.old if you restart X).
>>
>> -Albert
>>
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> http://openindiana.org/mailman/listinfo/oi-dev
>
> Hi Albert!
> Attached you'll find my Xorg.0.log.old, and the new Xorg.0.log too.
> Thanks for your help!
> Best regards,
>
> HeCSa.
>

That Xorg.0.log.old is from a Linux system with some S3 card.

-Albert

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

Re: [oi-dev] Illumos/OI Bug 1161 (nvidia crash)

[Albert Lee]

2011/6/30 Hernán Saltiel :
> Hi!
> Finally I freezed my machine again (it does this randomly, so it took me
> more time than expected).
> My answers in between your lines.
>
> On 06/29/2011 08:42 AM, Julian Wiesener wrote:
>>
>> Hi,
>>
>> On Wed, 2011-06-29 at 00:15 -0300, Hernan Saltiel wrote:
>>>
>>> Nope...it hung again some minutes ago, having no visual effects
>>> enabled.
>>> Something makes it freeze the entire system.
>>
>> what does "freeze the entire system" mean?
>
> After trying some tricks, I realised that is not the entire system what is
> freezing, only the GUI.
>>
>> If you move the mouse, is the cursor still moving?
>
> No.
>>
>> Can you switch to a console?
>
> No.
>>
>> Can you remote login using ssh?
>
> Yes! It worked!
>>
>> If so, what happends if you restart gdm?
>
> It restarts, I can log in, and start my apps again.
>>

Can you save and attach your /var/log/Xorg.0.log after the freeze to
the bug? (Xorg.0.log.old if you restart X).

-Albert

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

Re: [oi-dev] Transitioning from Sun Studio to gcc & clang/llvm

[Albert Lee]

On Mon, May 23, 2011 at 11:22 AM, Alasdair Lumsden  wrote:
> Hi Albert,
>
> Thanks for the feedback, partial answers inline below!
>
> On 23 May 2011, at 16:05, Albert Lee wrote:
>> Should we be linking libgcc statically (apparently adds on the order
>> of 10k to every binary) or will every application depend on a package
>> with the gcc libraries?
>
> Still open for discussion - what are you/others thoughts? Beyond just the 
> on-disk size, there's the in-memory size and presumably a performance 
> difference.
>

It's mostly for math routines that the compiler didn't feel like
inlining, as well as exception handling for some languages [1]. There
may be a cache benefit from having a single copy in memory.

>>> 2. Follow the library layout guidelines set down by SFE
>>> 3. Compile gcc to use Sun ld, but GNU as
>>> 4. Use libstdc++ only where localisation is not affected
>>
>> libstdc++'s ABI is quite volatile, which can lead to a sad trail of
>> objects with incompatible ABI versions, and all software depending on
>> it will have to be rebuilt.
>
> This is why the gcc version supplied will be fixed for a 5+ year period - I 
> doubt we'll be changing the gcc version any time soon after doing this. When 
> we do update to a newer GCC or to llvm/clang or another compiler, we can 
> continue to supply the library, via a compat package.
>
> So I don't see this as an issue, unless I've missed something.
>

If we have any application binaries we wish to support beyond that N
year period, this means keeping around a parallel world of of C++
libraries for them to depend on (SFE uses /usr/gnu for this). This may
be unavoidable independent of the choice of libstdc++ if we transition
to e.g. libc++ anyway, though.

>>> 5. Compile and supply llvm/clang
>>
>> And libc++?
>
> Yes, I don't see why not.
>
>>> 6. Ensure software we transition from Sun Studio compiles with both gcc and 
>>> llvm/clang
>>> 7. Use gcc as the shipping default with a view to switching to llvm/clang 
>>> at a future date, but allow either to be picked easily when it achieves 
>>> performance and feature parity
>>>
>>> We can begin this process by applying the policy on new software we add to 
>>> OI. How we transition our core consolidations can be discussed later on.
>>>
>>> If anyone has any serious objections to the above, let me know, otherwise 
>>> I'll get this written up on the wiki as a policy.
>>>
>>
>> This will cause problems with tools, possibility impacting debugging.
>
> Could you elaborate a little bit more on this?
>

Are we going to try to finish the effort started by Rich to port the
gcc 3.4 changes to 4.x? I believe the most important ones for us are
to add argument saving (for mdb at least, maybe pstack).

>> This also affects illumos builds as g++ and libgcc-linked objects will be
>> involved.
>
> Again, could you go into more detail?
>

This will need testing, but the bits of C++ software in illumos which
will most likely be a non-issue if they continue to be built with
Studio (as I don't believe any of them have direct external
consumers). There may be dependencies on external C++ libraries,
hopefully very limited.

libgcc_s may be accidentally pulled in when linking some objects.

>> Will SPARC support require the gccfss patches?
>
> Are you proposing we use the GCC frontend with Sun Studio backend for SPARC? 
> Or is there a patch set for GCC that improves patch support, from the gccfss 
> source?
>

There are changes for correct SPARC code generation which I believe
introduced in gccfss.

> Anything that will cause an issue can be kept Sun Studio for now. It would be 
> good to have a list of things that will b0rk or have potential issues.
>

[1] http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html

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

Re: [oi-dev] Transitioning from Sun Studio to gcc & clang/llvm

[Albert Lee]

On Mon, May 23, 2011 at 10:27 AM, Alasdair Lumsden  wrote:
> Hi All,
>
> As per discussions on IRC, I'd like to formalise plans for the transition 
> from Sun Studio to open source compiler suites. This is a medium-term 
> transition plan, rather than a sweeping change.
>
> So far the general working plan I've put together based on feedback is:
>
> 1. Add gcc 4.5.3 support (or gcc 4.6) with LinkTimeOptimization disabled

Should we be linking libgcc statically (apparently adds on the order
of 10k to every binary) or will every application depend on a package
with the gcc libraries?

> 2. Follow the library layout guidelines set down by SFE
> 3. Compile gcc to use Sun ld, but GNU as
> 4. Use libstdc++ only where localisation is not affected

libstdc++'s ABI is quite volatile, which can lead to a sad trail of
objects with incompatible ABI versions, and all software depending on
it will have to be rebuilt.

> 5. Compile and supply llvm/clang

And libc++?

> 6. Ensure software we transition from Sun Studio compiles with both gcc and 
> llvm/clang
> 7. Use gcc as the shipping default with a view to switching to llvm/clang at 
> a future date, but allow either to be picked easily when it achieves 
> performance and feature parity
>
> We can begin this process by applying the policy on new software we add to 
> OI. How we transition our core consolidations can be discussed later on.
>
> If anyone has any serious objections to the above, let me know, otherwise 
> I'll get this written up on the wiki as a policy.
>

This will cause problems with tools, possibility impacting debugging.
This also affects illumos builds as g++ and libgcc-linked objects will be
involved. Will SPARC support require the gccfss patches?

-Albert

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

Re: [oi-dev] 148b Audio Issues

[Albert Lee]

On Sun, May 22, 2011 at 1:18 PM, Ken Gunderson  wrote:
> Howdy:
>
> No audio here on 148b.  I note a couple bugs filed in Redmine, but not
> listed as show stoppers for 151.  Shouldn't this be on the radar for 151
> based release or am I missing something?
>
> Sporting two different audio devices on this Tyan K8E based test rig:
>
> 1) AC97 nVidia onboard
>
> a) previously worked w/o problem on Open/Solaris.
> b) wants to use audio810 driver
> c) plays test sound via Multimedia Systems Selector
> d) played a cd via Sound Juicer once, but otherwise have been unable to
> repeat.
> e) scanpci output:
>
> pci bus 0x cardnum 0x04 function 0x00: vendor 0x10de device 0x0059
>  nVidia Corporation CK804 AC'97 Audio Controller
>  CardVendor 0x10f1 card 0x2865 (Tyan Computer, Tomcat K8E (S2865))
>  STATUS    0x00b0  COMMAND 0x0007
>  CLASS     0x04 0x01 0x00  REVISION 0xa2
>  BIST      0x00  HEADER 0x00  LATENCY 0x00  CACHE 0x00
>  BASE0     0xf000 SIZE 256  I/O
>  BASE1     0xec00 SIZE 256  I/O
>  BASE2     0xfebfd000 SIZE 4096  MEM
>  BASEROM   0x  addr 0x
>  MAX_LAT   0x05  MIN_GNT 0x02  INT_PIN 0x01  INT_LINE 0x0b
>
>
>
> 2) Audiotrak Prodigy HD.  Envy24 based PCI add in card.
>
> a) Never worked on any previous Open/Solaris
> b) wants to use audiohd driver
> c) does not play test sound via Multimedia Systems Selector
> d) but apparently might should work per hcl wiki note pertaining to
> generic Envy24.
> e) scanpci output:
>
> pci bus 0x0001 cardnum 0x09 function 0x00: vendor 0x1412 device 0x1724
>  VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio
> Controller
>  CardVendor 0x3137 card 0x4154 (Card unknown)
>  STATUS    0x0210  COMMAND 0x0005
>  CLASS     0x04 0x01 0x00  REVISION 0x01
>  BIST      0x00  HEADER 0x00  LATENCY 0x20  CACHE 0x00
>  BASE0     0xa400 SIZE 32  I/O
>  BASE1     0xa000 SIZE 128  I/O
>  BASEROM   0x  addr 0x
>  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x01  INT_LINE 0x07
>
>
> That the onboard succeeds in playing test sound but I cannot get audio
> playback from neither Rhythmbox, Totem, or Juicer seems odd.
>
> The Audiotrak is a relatively high grade two channel card targeting more
> "audiophile" rather than gamer type end user.  I'd be willing put on
> loan to US based driver developer if it would help polish up support for
> Envy24 based cards. I also have another Envy24 based card (Chaintech).
>
> --
> Ken Gunderson 
>

Driver issues should be filed against illumos-gate (not OpenIndiana) here:
http://www.illumos.org/projects/illumos-gate/issues

Use cat /dev/sndstat and audiotest for diagnostics.

There was an incomplete port of OSS4's Envy24 driver (
http://opensolaris.org/jive/thread.jspa?threadID=125584 ) which would
need additional work.

-Albert

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

Re: [oi-dev] Improving the current Wordpress Website

[Albert Lee]

On Wed, Apr 13, 2011 at 11:19 AM, Alasdair Lumsden  wrote:
> Hi All,
>
> Nora (who made the backgrounds+login screen for OI) is looking to work on
> the OpenIndiana website, which is badly in need of some love and attention
> from someone with graphical talents.
>
> Right now the easiest/quickest thing to do would be to continue using
> Wordpress, and replace the current theme with a new one, and customise that
> to fit. She has done some digging on the Internet and found a bunch of paid
> for themes that could be used, and put them on a poll:
>
> http://polldaddy.com/poll/4909414/
>
> (The options are hyperlinks showing the theme)
>
> If you could all click through and have a look at the themes, and vote on
> your favourite, that would be appreciated. She can then put together a dev
> website which people can provide feedback on, which could then be swapped in
> to replace the current site.
>
> Longer term the project may want to consider a re-brand, but in the short
> term improving the current website is critical, as the current one looks
> pretty hobbyist.
>

I'd opt for a "keep the current layout" option in the poll. I happen
to think the minimalism of the current layout is preferable to a
generic corporate-looking site (all of the above themes are centered
around a page-wide banner image or slideshow).

-Albert

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

[oi-dev] 2011 Google Summer of Code for illumos is open!

[Albert Lee]

Hi everyone,

The 2011 Google Summer of Code is an exciting opportunity to do
something neat for your favorite open source projects[1] and become
famous. (You get paid by Google for it, too). Student applications are
open from Monday, March 28 to Friday, April 8.

If you have a great project idea, apply at:
http://www.google-melange.com/gsoc/org/show/google/gsoc2011/illumos

Don't forget to check out the ideas page for suggestions:
http://goo.gl/AEPKN

Summer of Code FAQs: http://goo.gl/Up2Qf
Summer of Code Timeline: http://goo.gl/0lYPz

[1] If illumos and OpenIndiana are your favorites. :)

-Albert

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

[oi-dev] GSoC mentors, please register!

[Albert Lee]

Hi folks,

Google's finally restored mentor management to the updated GSoC site (Melange).

If you've volunteered to mentor for this year's GSoC, please go to
http://www.google-melange.com/gsoc/org/google/gsoc2011/illumos and
click the Register or Apply link. This requires a Google Account.

Thanks!

-Albert

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

Re: [oi-dev] GSOC2011

[Albert Lee]

On Mon, Mar 21, 2011 at 12:55 PM, Andrew Gabriel
 wrote:
> Cyril Plisko wrote:
>>
>> On Mon, Mar 21, 2011 at 1:54 PM, Andrey Sokolov
>>  wrote:
>>>
>>> Hi Deano,
>>>
>>> I would like to write a program that will convert linux binaries to
>>> opensolaris binaries. The program will change dynamic relocation records.
>>> I
>>> did a little experiment: http://forum.os-solaris.ru/index.php?topic=223.0
>>> I
>>> have converted a simple linux binary to opensolaris binary using hex
>>> editor.
>>>
>>
>>
>> Instead of [destructively] change the Linux binary in order to run it
>> under Solaris,
>> wouldn't it be better to do the job on the fly via dynamic linker ?
>> Linux binaries conveniently use /lib/ld-linux.so.1 (as opposed to
>> /lib/ld.so.1 for
>> Solaris). So one would imaging that if you will provide a
>> /lib/ld-linux.so.1 that
>> knows how to fix the relocations that would get you what you need, w/o
>> touch
>> the binaries. Does it make sense ?
>
> Might want to look back at any info which still exists on "lxrun" which
> worked in a not dissimilar way, and also see if there's any info about Sun's
> Solaris 10 Janus project still knocking around (which may be useful even
> though you are not proposing the same route).
>

lxrun still works for older Linux binaries, but it used the rather
ugly method of userspace syscall emulation by trapping SIGSEGV.
Applications receive this signal when they cause a general protection
fault by making an invalid system call using the traditional i386 INT
0x80 (the syscall vectors used by Linux happen to be unused on
Solaris). I'm not sure what happens when applications try to use
SYSENTER instead.

BrandZ just implemented the Linux system calls instead, which works
well, but obviously requires extensive kernel support. While we can
bring it back into illumos fairly easily, it is still incomplete and
also suffers from the fact that Linux has had some changes in the time
it's gone unmaintained.

Modern Linux applications as they do not embed system calls in their
executables [1], so we do not have to perform syscall translation if
we don't want to. They expect a code segment containing functions with
stable interfaces to be mapped when they are run, and use those
functions to perform syscalls. On Linux this segment is actually
provided by the kernel (as a sort of "virtual library" named
"linux-gate.so.1") and this allows the syscall implementations to be
replaced easily [2]. illumos can provide this functionality as a real
library or in the dynamic loader.

If we want Linux executables to load native shared libraries (which
would be really really cool), the dynamic loader would also need to
support redirecting Linux application libc calls to GNU libc or
wrappers around the native libc to handle interface and structure
differences.

Your suggestion to modify Linux executables on disk is an interesting
one (reminds me of a similar but far too ambitious project for Win32
executables) and I'd like to hear more.

I have investigated the options here (actually started some work on a
modified dynamic loader that lives at ld-linux.so.2) and would be
happy assist you. BTW, develo...@lists.illumos.org is better for
future discussion, and I have CC'ed it.

[1] Some exceptions exist in closed software, often intended to
discourage reverse engineering.
[2] See the description of __kernel_vsyscall here:
http://articles.manugarg.com/systemcallinlinux2_6.html

-Albert

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

[oi-dev] Fwd: [illumos-Developer] Google Summer of Code?

[Albert Lee]

The illumos proposal to this year's Google Summer of Code will include
projects for OpenIndiana. If you are a developer who's willing to
mentor a project, please suggest new projects on the wiki page or add
yourself to the mentor list for an existing project.

Thanks!
-Albert

-- Forwarded message --
From: Gordon Ross 
Date: Sun, Mar 6, 2011 at 9:28 AM
Subject: [illumos-Developer] Google Summer of Code?
To: illumos-dev 


Applications for this year's Google Summer of Code http://code.google.com/soc/
are due in a few days (March 11), so if the illumos project is going
to get involved,
we need to quickly collect a list of possible projects (and mentors)
and get that
into an application.

I've taken the liberty of creating a page on our wiki to collect ideas:
http://www.illumos.org/projects/illumos-gate/wiki/Google_Summer_of_Code

Please feel free to suggest possible projects that would be good for this
program.  Note that projects you suggest need "mentors".  See the GSoC
web side FAQ for details about what kinds of projects fit this program.

Thanks,
Gordon

___
Developer mailing list
develo...@lists.illumos.org
http://lists.illumos.org/m/listinfo/developer

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

Re: [oi-dev] Proposed plan for the next releases of OpenIndiana

[Albert Lee]

On Tue, Mar 1, 2011 at 5:06 PM, James O'Gorman  wrote:
> On 1 Mar 2011, at 22:01, Albert Lee wrote:
>> Our next development build will be based on illumos and Oracle's 151a
>> consolidations, and will be published to /dev, at which point /dev-il
>> will no longer exist as a separate repository.
> [...]
>> [1]  Our preliminary illumos-based build is at
>> http://pkg.openindiana.org/dev-il . The media was well-received at the
>> illumos exhibit at SCALE 9x. We're working on some additional changes
>> to complete illumos integration and will keep the versions of all
>> consolidations at Oracle's 148.
>
> Are mirrors expected to be hosting /dev-il? I've seen no pre-announcement for 
> it...
>

This is more or less for "internal consumption only" but might be
useful for illumos developers. Everyone else can ignore it - it'll be
replaced by a internal repo after /dev is updated.

-Albert

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

[oi-dev] Proposed plan for the next releases of OpenIndiana

[Albert Lee]

Hi all,

At today's developer meeting, we've gone over our release plans and
this is a summary of what we will do going forward:

Our experimental build[1] based on illumos and Oracle 148 will
continue receiving updates in preparation for our next development
build.

Our next development build will be based on illumos and Oracle's 151a
consolidations, and will be published to /dev, at which point /dev-il
will no longer exist as a separate repository.

Our stable release will be based directly on the aforementioned
development build, addressing any major issues after the initial
development release. This release will be published to /stable (and/or
/release?).

I'd like to know if this sounds sane to everyone (anyone?), and if
there are additional concerns that we may have missed.

Thanks!

[1]  Our preliminary illumos-based build is at
http://pkg.openindiana.org/dev-il . The media was well-received at the
illumos exhibit at SCALE 9x. We're working on some additional changes
to complete illumos integration and will keep the versions of all
consolidations at Oracle's 148.

-Albert

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

Re: [oi-dev] SPARC Text Installer

[Albert Lee]

On Wed, Feb 23, 2011 at 2:07 PM, Matthew Wilby  wrote:
>
> When I looked at Sun Rays several years back, there seemed to be more of a
> push to install SRSS on x86, I forget the exact reason, probably cost and at
> the time T2000s weren't great. Are there really that many people using Sun
> Rays on SPARC?
>

I only have anecdotal evidence to go by, so I can't really say.

>>
>> > I'm not suggesting this should be a stable release. I'm not sure what
>> > consolidation versions should be used.
>> >
>>
>> I have confidence we can reproduce builds for 148.
>>
>
> Is this based upon using Illumos (as per oi_148a) or Oracle ON?

Either, if Andrzej's changes outside of ON for oi_148a are documented.
There are fixes for SPARC in the illumos tree that would need
backporting to oi_148's onnv-gate.

> It would be interesting to know what the Illumos guys think about SPARC, and
> if they see it as supportable long term.

As one of the "illumos guys", I can state that continuing SPARC support is one
of our long-term goals, and the availability of a proper self-hosting
SPARC distribution would greatly benefit development.

-Albert

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

Re: [oi-dev] SPARC Text Installer

[Albert Lee]

On Wed, Feb 23, 2011 at 4:06 AM, MATTHEW WILBY
 wrote:
> Good Morning,
>
> I've seen various people enquire about when we are going to release a SPARC
> iso.
>
> What I'd like to propose is that we work towards preparing a dev text
> installer, using Illumos and incorporating the the hard work done on g11n,
> and a recent build of SFW etc. I think most people are using SPARC based
> servers as opposed to workstations, so I suspect XNV/JDS can follow at a
> later date if there is interest.

Additionally, SPARC graphics support is extremely limited so the
desktop target will primarily be Sun Ray and other remote sessions. It
is probably possible to omit all of XNV, but JDS provides core
software including Python.

>
> I believe it's important to get a *development* release out the door to
> allow people to test on the SPARC platform to provide feedback, generate
> additional interest and give people an alternative to Oracle tax.
>

Yes, this can be considered fairly important.

> I'm not suggesting this should be a stable release. I'm not sure what
> consolidation versions should be used.
>

I have confidence we can reproduce builds for 148.

-Albert

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

Re: [oi-dev] illumos based OpenIndiana DVD

[Albert Lee]

On Mon, Feb 21, 2011 at 2:14 PM, Garrett D'Amore  wrote:
>
> As ugly as I think 148.0.1 is, this may be the best compromise for now.
>
> Long term we have to disassociate ourselves from Oracle's "build
> numbers".
>
>        - Garrett


Alternatively, rolling back the change for now could make it easier
for use to implement a different scheme should we discover something
better. Currently this means "generic" builds can't be onu'ed... is it
necessary to differentiate the packages (other than by timestamp) for
now?

-Albert

>
> On Mon, 2011-02-21 at 18:58 +, Andrzej Szeszo wrote:
>> I have messed up with the url and the filename. Human error ;)
>>
>> Actually I have an updated ISO with fixed keyboard layout selection
>> ready. I am uploading it to the OpenIndiana servers now. Will post the
>> url later tonight.

I notice it was caused by my changes to prevent the layout service
failure. :( Let's try to figure out how the that interacts with
selection...

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

Re: [oi-dev] Contrib repo

[Albert Lee]

Hi Matt,

Please see:
http://openindiana.org/pipermail/oiac-discuss/2010-November/00.html

On Sat, Jan 8, 2011 at 1:02 PM, Matt Wilby  wrote:
> What's the general consensus about having a contrib repository for OI?
>
> - Would give community members the chance to submit additional software
> not found in the standard repo.
> - I can see the need for a contrib-pending and contrib-approved.
> - Would require vetting the contribution before moving from pending to
> approved, so perhaps more demand on staff.
> - Would need to come with a health warning, "use at your own risk etc."
> - More choice without the need for setting up lots of third party
> repositories. Everything from one source.
> - We had this in Opensolaris after the idea was posted on the forums
> back in 2008 I believe
>
\
>

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

[oi-dev] OpenIndiana build 148 release candidate images

[Albert Lee]

Hi everyone,

OpenIndiana build 148 should be ready for wider testing now. Please
give it the images a spin and file bugs for any issues you encounter,
I'm hoping we can formal release announcement by the weekend.

Text installer images:
http://dlc.openindiana.org/isos/148/oi-dev-148-text-x86-20101205.iso
http://dlc.openindiana.org/isos/148/oi-dev-148-text-x86-20101205.usb
Live DVD/USB installer images:
http://dlc.openindiana.org/isos/148/oi-dev-148-x86-20101216.iso
http://dlc.openindiana.org/isos/148/oi-dev-148-x86-20101216.usb
Automated Installer (bootable AI) images:
http://dlc.openindiana.org/isos/148/oi-dev-148-ai-x86-20101205.iso
http://dlc.openindiana.org/isos/148/oi-dev-148-ai-x86-20101205.usb

There is also a testing pkg(5) publisher for image-update available on
request (for bandwidth reasons).

Here is a list of issues resolved in this release:
200 Bug ResolvedUrgent  up-to-date l10n packages for 
Firefox and
Thunderbird needed
203 Bug ResolvedHighKeyboard configuration is not 
preserved across upgrades
209 Bug ResolvedHighdistro-import leaves an 
unnaturally curtailed entire
211 Bug ResolvedHighdistro-import doesn't create a 
slim_cluster
218 Bug ResolvedHighpackages to add/remove
255 Bug ResolvedHighJava SSL crypto problems
305 Bug ResolvedHighevolution 2.30 (+exchange) 
mostly broken
213 Bug ResolvedNormal  bookmark in Firefox still 
points to old
Launchpad bug tracker
222 Feature ResolvedNormal  Missing Postgresql from pkg 
repos
233 Bug ResolvedNormal  About OpenIndiana Dialog 
Displays Opensolaris
235 Bug ResolvedNormal  SMF Service reports 
zfssnap-roleadd in
maintenance state
237 Bug ResolvedNormal  Evolution Crashes
254 Bug ResolvedNormal  auditset SMF not able to start 
in non-global zones
261 Bug ResolvedNormal  groff has localization issues 
when calling man
263 Bug ResolvedNormal  useradd is unable to create 
home directory
288 Feature ResolvedNormal  New homedirs should have 
auto_home entries
337 Bug ResolvedNormal  liblcl needs to be compatible 
with system
strcasestr(3)
340 Bug ResolvedNormal  Some g11n downloads are stale
495 Bug ResolvedNormal  oi_148 and illumos-gate
192 Bug ResolvedLow Need to package mogrify the IPS 
vendor strings
234 Bug ResolvedLow Installer reports incorrect 
Gnome version (2.28)
238 Bug ResolvedLow powertop still OpenSolaris 
branded
246 Bug ResolvedLow latencytop still OpenSolaris 
branded
293 Bug ResolvedLow useradd/del/mod should be 
ZFS-aware
316 Bug ResolvedLow dtruss still uses 
syscall::utime:return
339 Bug ResolvedLow g11n build path for xkbcomp 
needs to be adjusted

-Albert

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

Re: [oi-dev] Developer meeting

[Albert Lee]

On Wed, Dec 1, 2010 at 5:28 PM, Alasdair Lumsden  wrote:
>
> On 1 Dec 2010, at 13:45, Guido Berhoerster wrote:
>
> 
>
>> Right, how about every other Wednesday at 21:00 UTC starting next
>> week (Dec, 8th)? While this is pretty arbitrary, it's after lunch
>> in PST and before bedtime in Central Europe, from my limited
>> observations there tends to be afair amount of activity in
>> #oi-dev.
>
> Sounds good - my only observation would be that LOSUG runs on a Wednesday 
> which I can't avoid, but we can probably just time things so the "every 
> other" one means it skips the LOSUG Wednesdays. The next one is on Dec 15th.
>

If there's no potential for conflict with LOSUG, that's fine.
Otherwise we could just try for say, Tuesday or Thursday instead.

-Albert

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

Re: [oi-dev] oi_148 is pending

[Albert Lee]

On Sun, Nov 21, 2010 at 4:17 PM, Hernan Saltiel  wrote:
>
>
> On Sat, Nov 20, 2010 at 2:49 AM, Albert Lee  wrote:
>>
>> Hi folks,
>
> Hi, Albert!
>
>>
>> I've spent a large part of the past two days reworking and documenting
>> our release packaging environment and fixing issues with our metadata
>> and external packages that are being imported into this release, and I
>> feel we have a sustainable environment for release management now.
>> I've gotten a tentatively complete set of oi_148 packages created
>> with an entire redistributable cluster this time and imported the
>> SVR4-based consolidations we don't yet have replacements for, instead
>> of including opensolaris.org packages in our incorporations. If this
>> went as planned, our users should no longer need an opensolaris.org
>> publisher configured.
>>
>> I've built a full redistributable cluster (as well as a slim_install
>> metapackage) instead of the weird mini cluster we had for 147. The
>> packages are sitting in /net/infra01/releng/oi/oi_148/repo which still
>> needs to be imported into a clone of the 147 repository. Hopefully we
>> can get some testing done over the weekend.
>
> I'm very interested in the process you followed in order to get this as a
> result. Is there any chance to have access to the documentation you
> followed?
> I'm working in having a server only release, I have several packages
> compiled, but I'm having hard times creating the distro.
> Any help will be very appreciated!
>

http://wiki.openindiana.org/display/oi/Release+Engineering is my
summary of the release process.

-Albert

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

Re: [oi-dev] oi_148 is pending

[Albert Lee]

On Sat, Nov 20, 2010 at 12:02 PM, Alan Coopersmith
 wrote:
> Alasdair Lumsden wrote:
>> On 20 Nov 2010, at 05:49, Albert Lee wrote:
>>> - Create a text_install cluster for the Text Installer (its current
>>> use of an explicit package list is quite embarrassing).
>>
>> I always wondered why they did it that way.
>
> That's what the server_install cluster is that was introduced in b150:
> https://defect.opensolaris.org/bz/show_bug.cgi?id=12737
> http://hg.openindiana.org/pkg-gate/file/tip/src/util/distro-import/150/common/ServerInstall
>

Oh, perfect.

> (Be careful though, that's around the build that non-freely-redistributable
>  packages started getting included in the main Solaris Express repo & clusters
>  even the now-misnamed "redistributable", so you'll probably need to drop some
>  packages that are in the clusters but not in your repos.)

Thanks for the warning, Alan. We're still using our mirror of /dev as a
reference repo (as /legacy hasn't been updated to 134b) and there
should be no references to it by the packages in this build (and
certainly no references to
the solaris publisher).

-Albert

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

[oi-dev] oi_148 is pending

[Albert Lee]

Hi folks,

I've spent a large part of the past two days reworking and documenting
our release packaging environment and fixing issues with our metadata
and external packages that are being imported into this release, and I
feel we have a sustainable environment for release management now.
I've gotten a tentatively complete set of oi_148 packages created
with an entire redistributable cluster this time and imported the
SVR4-based consolidations we don't yet have replacements for, instead
of including opensolaris.org packages in our incorporations. If this
went as planned, our users should no longer need an opensolaris.org
publisher configured.

I've built a full redistributable cluster (as well as a slim_install
metapackage) instead of the weird mini cluster we had for 147. The
packages are sitting in /net/infra01/releng/oi/oi_148/repo which still
needs to be imported into a clone of the 147 repository. Hopefully we
can get some testing done over the weekend.

Some additional things I want to do before the release:
- Make sure I haven't made any typos in the metadata, like last time :)
- Create a text_install cluster for the Text Installer (its current
use of an explicit package list is quite embarrassing).
- Get QA done against the bugs we have on file
- Build and test both live media and AI images
- Start looking at the logistics for the illumos repository. One
option is to ship an older build of illumos we have around, but we
need to integrate the supporting changes for snmpdx and Perl 5.8.4
removal as soon as possible.

-Albert

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

Re: [oi-dev] OpenIndiana and illumos, part 2

[Albert Lee]

On Thu, Nov 18, 2010 at 3:21 PM, Albert Lee  wrote:
> OK, Garrett's attempt forced people to respond really defensively...
> so let's try again.
>
> For the record, here are goals (and anti-goals) of illumos that are
> relevant to OpenIndiana:
>
> - The ability to run software built for Solaris 10 using interfaces
> that weren't already subject to change between releases (obsolete
> interfaces need not apply)
> - The ability to run software built for Solaris 11 on a best-effort
> basis, since it is both an unknown and a moving target
> - No consideration for the converse ability to run software built for
> illumos on Solaris 11 (that is not to say it won't happen to work, but
> it won't be a concern for development)
> - Freedom to introduce new features in a way that is incompatible with
> Solaris 11
> - Freedom to remove features with known and limited affect (obviously
> not subverting compatibility, but compromises are inevitable)
>
> This is the big picture, and the goals are near what OpenIndiana can
> realistically hope to achieve. Sometimes there seems to be the
> appearance of a false dichotomy. What illumos (not just Garrett) needs
> is not all that complicated, and it's mostly for the OpenIndiana
> developers to work closely with the illumos developers on changes that
> have an impact outside of ON, so illumos can have a proper
> self-hosting platform. There has been unfortunately little high-level
> communication between developers of illumos and OpenIndiana and not
> enough overlap in membership, and that needs to change.
>
> In any case, users choosing to use what was explicitly stated to be
> the first development release of OpenIndiana in production certainly
> made a mistake (although possibly the real issue for many was choosing
> to deploy the OpenSolaris development build in the first place), and
> we *should* not feel responsible for the effects of that decision.
> However, as a conscientious person I believe that we *can* move
> forward with illumos without completely abandoning them.
>
> oi_148 is nearly done, and I apologise for the delay, I have approval
> to finish performing the RE tasks today with our current bits and get
> it out the door. I believe our originally stated plan of providing an
> illumos build for this release in an additional repository is feasible
> (and I've been doing regular builds) and provides the illumos
> developers what they need, and Garrett has agreed that it is
> reasonable.
>
> So let's make sure we're all on the same page. Given illumos'
> self-imposed constraints, what are the primary concerns of
> OpenIndiana?
>
> -Albert
>

I should also mention that the real targets for oi_148 aren't the
specific versions of the consolidations we're delivering but
addressing specific concerns with the first release and making sure we
have the processes in place for future builds.

-Albert

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

[oi-dev] OpenIndiana and illumos, part 2

[Albert Lee]

OK, Garrett's attempt forced people to respond really defensively...
so let's try again.

For the record, here are goals (and anti-goals) of illumos that are
relevant to OpenIndiana:

- The ability to run software built for Solaris 10 using interfaces
that weren't already subject to change between releases (obsolete
interfaces need not apply)
- The ability to run software built for Solaris 11 on a best-effort
basis, since it is both an unknown and a moving target
- No consideration for the converse ability to run software built for
illumos on Solaris 11 (that is not to say it won't happen to work, but
it won't be a concern for development)
- Freedom to introduce new features in a way that is incompatible with
Solaris 11
- Freedom to remove features with known and limited affect (obviously
not subverting compatibility, but compromises are inevitable)

This is the big picture, and the goals are near what OpenIndiana can
realistically hope to achieve. Sometimes there seems to be the
appearance of a false dichotomy. What illumos (not just Garrett) needs
is not all that complicated, and it's mostly for the OpenIndiana
developers to work closely with the illumos developers on changes that
have an impact outside of ON, so illumos can have a proper
self-hosting platform. There has been unfortunately little high-level
communication between developers of illumos and OpenIndiana and not
enough overlap in membership, and that needs to change.

In any case, users choosing to use what was explicitly stated to be
the first development release of OpenIndiana in production certainly
made a mistake (although possibly the real issue for many was choosing
to deploy the OpenSolaris development build in the first place), and
we *should* not feel responsible for the effects of that decision.
However, as a conscientious person I believe that we *can* move
forward with illumos without completely abandoning them.

oi_148 is nearly done, and I apologise for the delay, I have approval
to finish performing the RE tasks today with our current bits and get
it out the door. I believe our originally stated plan of providing an
illumos build for this release in an additional repository is feasible
(and I've been doing regular builds) and provides the illumos
developers what they need, and Garrett has agreed that it is
reasonable.

So let's make sure we're all on the same page. Given illumos'
self-imposed constraints, what are the primary concerns of
OpenIndiana?

-Albert

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

Re: [oi-dev] [OpenIndiana-discuss] Installing VBox

[Albert Lee]

On Fri, Oct 22, 2010 at 4:46 PM, Alasdair Lumsden  wrote:

> Really, the answer is for someone to compile the open source version of 
> VirtualBox for OpenIndiana with this check fixed. We'd be more than happy to 
> provide it in our repos assuming the licensing permits.
>

Unfortunately, the USB passthrough isn't available in the "Open Source
Edition" or OSE.

-Albert

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

Re: [oi-dev] SFW b148 Progress Update

[Albert Lee]

Sevan, that's great news! Would you mind creating a giant Mq patch
(remember to have "[diff]
git=True" in your ~/.hgrc or pass -g to both hg qnew and qrefresh) for
the changes? If you're not comfortable with Mq, just send me a regular
diff or tarball. You can copy the built packages to fastdev01 or
infra01 (specifically /net/infra01/export/integrate_dock/oi/oi_148).

Thanks!

-Albert

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

Re: [oi-dev] Governing + Developer Councils + Teams

[Albert Lee]

On Tue, Sep 28, 2010 at 7:25 PM, Alasdair Lumsden  wrote:
> Hi All,
>
> One of the outstanding things we need to do as a project is set up the 
> governing structure so the project is more democratic and inclusive.
>
> Having discussed this with a few people, I'd like to propose the following 
> structure:
>
> 1. OpenIndiana Governing Council (OIGC)
>
> 2. OpenIndiana Developer Council (OIDC)
>

A tried-and-true model. ;)

>
> For the above two councils, we should obtain nominations and hold votes at 
> some point in the near future (once oi_148 is complete seems a reasonable 
> time schedule).
>

Yeah, that's probably the earliest time frame we want to start
spending time on this.

> Then to manage the project, we will need a set of teams with well defined 
> remits/responsibilities, providing accountability etc, so when schedules 
> slip, we know who to go to to get the situation resolved and things back on 
> track. Each team will consist of a team leader, and depending on the size of 
> the team 1 or more assistant-team-leads (Who can fill in in the 
> absence/unavailability of the team leader)
>
> Here is the list of teams I came up with:
>
> 1. Infrastructure Team
>

Any case where Alasdair may remain the only person with authority to
make changes for technical reasons (example: the CDN) should be
considered bugs and filed as such, even if they are unavoidable in the
near term.

>
> 3. Consolidation Builders Team
>

Once we have more repeatable builds and automation, the balance of
work here should tip towards maintaining our own changes and working
with upstream where applicable. The "Builders" part of the name would
be de-emphasized.

>
> 4. Website, Wiki & Marketing Team
>


Artwork and logos would fall within this team's responsibility as
well. (I'll also repeat that I don't endorse the obvious conflict of
interest in having a stake in our own Wikipedia article).

> I think this just about covers it.

A documentation team will be very important going forward, with no
rights to reproduce most of the official Solaris docs and the man
pages already falling behind.

-Albert

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