Re: [oi-dev] New guy

[Andrzej Szeszo]

Hi Ken

The project is definitely open for new contributors. We normally hang 
out on #oi-dev IRC channel on Freenode and you are welcome to join us.


We plan on using illumos as the core of the next OpenIndiana release. 
Globalisation (g11n) consolidation needs some work before we will be 
able to do that for example. It involves renaming/obsoleting Sun/Oracle 
provided packages. Some Makefile work. Not very complicated but there 
are lots of files to touch.


Please join #oi-dev and we will help you to get started.

Andrzej


On 01/31/11 00:30, Kenneth O'Brien wrote:

Hi,

I'm looking for an OSS project to contribute to. I'm a coder/sysadmin 
type. I'm not adverse to testing/QA either.


I've read the docs and am looking for a place to start. Any particular 
team need a new member?


Regards,

Ken


___
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] illumos based OpenIndiana DVD

[Andrzej Szeszo]

Hi All

We've been working on getting the development branch of OpenIndiana 
switched over to the illumos core.


The way we are doing it initially is to take OpenIndiana 148 ips 
repository and add few updated consolidations to it. The consolidations 
that needed updating after switching to illumos osnet are: l10n, 
install, solaris_re.


The resulting repository was used to create live/install DVD. Resulting 
iso image can be found here: 
http://dlc.openindiana.org/isos/oi-dev-148a-x86-20100218-1.iso


This is not the final iso as few things need to be resolved first.

1. Package version numbers

We have used 148.0.1 as a pkg version number of the updated 
consolidations, including osnet, to differentiate them from the original 
OpenIndiana 148 ones.


One problem with the version number bump is that the default 
illumos-gate builds, which generate version 148 packages, won't install 
anymore, as they are going to be considered as "old" by the packaging 
system. The solution is to add "ONNV_BUILDNUM=148.0.1; export 
ONNV_BUILDNUM" to the nightly file when building illumos-gate or we 
could simply revert the version number change.


It would be good to get some feedback on this.

2. Branding

When building illumos-onnv we have used similar branding patch set as 
when buiding the original OpenIndiana 148 onnv and at the moment there 
is almost no indication that the system is running illumos core apart 
from the "Powered by illumos" label on the boot splash screens.


http://img405.imageshack.us/i/screenshot20110221at121.png/

It would be good to get some feedback on what we should put in 
/etc/motd, /etc/release and kernel banner. We definitely want illumos 
name to be listed in all places but at the same time we don't want to 
confuse users about what they run.


Please let me know what you think.

3. Keyboard layout selection bug

There seems to be a problem with keyboard layout selection when using 
live dvd. US keyboard layout is always used even after selecting non-US 
layout at boot. I'll be looking at this issue now.



Also, Garrett, how much time have we got left to prepare an updated iso, 
so you have enough time to get some media manufactured for SCALE? Please 
let us know.


Cheers,

Andrzej


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

Re: [oi-dev] illumos based OpenIndiana DVD

[Andrzej Szeszo]

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.


Also, can someone comment on the 148.0.1 version number and branding please?

Andrzej

On 02/21/11 05:35 PM, Volker A. Brandt wrote:

It seems to have been moved to the /148/ sub-directory:
http://dlc.openindiana.org/isos/148/oi-dev-148a-x86-20100218-1.iso

Btw, the date on the ISO is wrong, we are in 2011 ;)

Ah, so that was the trick... I looked in 148 but only for things
that said "2011"... :-)


Thanks -- Volker


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

Re: [oi-dev] illumos based OpenIndiana DVD

[Andrzej Szeszo]

Updated ISO can be found here:

http://dlc.openindiana.org/isos/148/oi-dev-148a-x86-20110221-1.iso

Keyboard layout selection works OK now.

Please report any live cd issues if you have a moment to test.

Andrzej

On 02/21/11 06:58 PM, 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.


Also, can someone comment on the 148.0.1 version number and branding 
please?


Andrzej

On 02/21/11 05:35 PM, Volker A. Brandt wrote:

It seems to have been moved to the /148/ sub-directory:
http://dlc.openindiana.org/isos/148/oi-dev-148a-x86-20100218-1.iso

Btw, the date on the ISO is wrong, we are in 2011 ;)

Ah, so that was the trick... I looked in 148 but only for things
that said "2011"... :-)


Thanks -- Volker


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

Re: [oi-dev] illumos based OpenIndiana DVD

[Andrzej Szeszo]

Hi Hernan

First I built illumos-gate, slim_source, g11n and solaris_re with 
OpenIndiana patches, bumping version numbers to 148.0.1. Then manually 
created updated entire package - bumped version numbers of incorporated 
consolidations built earlier to 148.0.1 by hand. Merged the resulting 
packages with official OpenIndiana repository. The repository located 
here is the end result:


http://pkg.openindiana.org/dev-il/

Then, I have installed pkg:/install/distribution-constructor, made a 
copy of /usr/share/distro_const/slim_cd/slim_cd_x86.xml, changed the 
repository url from http://pkg.openindiana.org/dev to 
http://pkg.openindiana.org/dev-il and ran:


distro_const build slim_cd_x86.xml

The end result:

$ ls /rpool/dc/media
OpenIndiana_Live_X86.iso  OpenIndiana_Live_X86.usb

Andrzej


On 02/21/11 21:57, Hernan Saltiel wrote:



On Mon, Feb 21, 2011 at 6:32 PM, Andrzej Szeszo <mailto:asze...@gmail.com>> wrote:


Updated ISO can be found here:

http://dlc.openindiana.org/isos/148/oi-dev-148a-x86-20110221-1.iso

Keyboard layout selection works OK now.

Please report any live cd issues if you have a moment to test.


Again, do you have any notes about how did you build the ISO's?
Is there any link where to share this knowledge with the community?
Thanks, and best regards,

HeCSa.


Andrzej


On 02/21/11 06:58 PM, 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.

Also, can someone comment on the 148.0.1 version number and
branding please?

Andrzej

On 02/21/11 05:35 PM, Volker A. Brandt wrote:

It seems to have been moved to the /148/ sub-directory:

http://dlc.openindiana.org/isos/148/oi-dev-148a-x86-20100218-1.iso

Btw, the date on the ISO is wrong, we are in 2011 ;)

Ah, so that was the trick... I looked in 148 but only for
things
that said "2011"... :-)


Thanks -- Volker


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




--
HeCSa


___
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] illumos based OpenIndiana DVD

[Andrzej Szeszo]

I am preparing packages with 148 as the version number now to have an 
alternative ready just in case.


I would be good to get even more feedback on this.

To make sure user is running illumos based OpenIndiana we could ask him 
to do image-update to the latest packages from the dev repo. Sticking 
with the current version numbers is not going to be a big deal.


Andrzej


On 02/21/11 19:21, Albert Lee wrote:

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



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

Re: [oi-dev] illumos based OpenIndiana DVD

[Andrzej Szeszo]

On 02/21/11 20:25, Guido Berhoerster wrote:

* Alasdair Lumsden  [2011-02-21 20:51]:

On 21 Feb 2011, at 19:48, Guido Berhoerster wrote:

Great stuff. What are we going to do about perl-584, are you
going to use packages from an older build?
Also how do we want to handle this in general, just ship perl-584
from an older ONNV for maintaining backwards compatibility and
switch all consolidations to perl-510?  I have a JDS build
against perl-510 ready but AFAIK XNV and SFW are still being
worked on.

I think we'll need to do 1 final perl-584 package at a higher build number, 
which no longer delivers the /usr/bin/perl symlink (plus potentially others if 
there are any), so that the perl 510 package can provide that instead.

That way when people upgrade, /usr/bin/perl gets removed then re-added.

Does that sound feasible?

Sure, that's what we had planned. But do we make that move now
for the demo CD? Also, should we only provide perl-584 by itself
or variants of the perl modules in JDS and SFW as well?
I think it is a bit too late for the change to appear on the demo CD. 
Not even 100% sure if we will get the CD out on time in its current state.


The system installed by the CD will be using 
http://pkg.openindiana.org/dev repository by default anyway. We 
obviously can update it at a later time with all the perl584 changes.


Andrzej

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

Re: [oi-dev] illumos based OpenIndiana DVD

[Andrzej Szeszo]

I have actually new iso and repo on the way. With better illumos 
branding and version number reverted from 148.0.1 back to 148 as 
suggested by Albert.


There is no illumos logo anywhere on the desktop at the moment.

I have put "powered by illumos" label in /etc/release, /etc/motd. Also 
kernel bootmsg contains illumos changeset id.


It will be clear that the system is powered by illumos code.

Andrzej


On 02/22/11 15:38, Garrett D'Amore wrote:

Thanks everyone for putting in this effort.

I need to locate someone who can produce media.  I'm thinking I need to
produce a few hundred copies at least -- maybe even a thousand.
Opinions?

Also, do we have any artwork to put on the media and/or the sleeves?
(Ideally with the new illumos logo?)

I've not booted the new media *yet* but will do so today.  Is the new
illumos logo ("powered by") used on the OI desktop as well?

- Garrett

On Tue, 2011-02-22 at 06:27 -0800, ken mays wrote:

Andrzej,


As mentioned, your OI_148a Live DVD seems fine and better than the original 
OI_148 DVD in concept.

Having it available for SCALE online (check net load handling) and on spare
DVDs (mass copy on location!) seems to be on mark as I have thoroughly reviewed 
the OI_148a Live DVD for basic workstation use. Also, with an installation and 
Nvidia 270.26 driver, most users can use the 3D desktop capabilities very well. 
I already listed basic bugs I've observed elsewhere.

As for performance scalability under load testing with the Illumos kernel, I 
did comment on the recent Phoronix review with the older OI_148 distro.

See: http://www.phoronix.com/scan.php?page=article&item=multi_os_scaling&num=1

So, I consider this just things to review in the future. Right now the Live DVD 
is 'working fine' and the Perl 5.10.1 migration should come next.

There are still a few days to get some more tweaks done. No major showstoppers 
at the moment!

~ Ken Mays



--- On Tue, 2/22/11, Andrzej Szeszo  wrote:


From: Andrzej Szeszo
Subject: Re: [oi-dev] illumos based OpenIndiana DVD
To: oi-dev@openindiana.org
Date: Tuesday, February 22, 2011, 5:42 AM
On 02/21/11 20:25, Guido Berhoerster
wrote:

* Alasdair Lumsden

[2011-02-21 20:51]:

On 21 Feb 2011, at 19:48, Guido Berhoerster

wrote:

Great stuff. What are we going to do about

perl-584, are you

going to use packages from an older build?
Also how do we want to handle this in general,

just ship perl-584

from an older ONNV for maintaining backwards

compatibility and

switch all consolidations to perl-510?  I

have a JDS build

against perl-510 ready but AFAIK XNV and SFW

are still being

worked on.

I think we'll need to do 1 final perl-584 package

at a higher build number, which no longer delivers the
/usr/bin/perl symlink (plus potentially others if there are
any), so that the perl 510 package can provide that
instead.

That way when people upgrade, /usr/bin/perl gets

removed then re-added.

Does that sound feasible?

Sure, that's what we had planned. But do we make that

move now

for the demo CD? Also, should we only provide perl-584

by itself

or variants of the perl modules in JDS and SFW as

well?
I think it is a bit too late for the change to appear on
the demo CD. Not even 100% sure if we will get the CD out on
time in its current state.

The system installed by the CD will be using http://pkg.openindiana.org/dev 
repository by default
anyway. We obviously can update it at a later time with all
the perl584 changes.

Andrzej

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





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



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


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

Re: [oi-dev] illumos based OpenIndiana DVD

[Andrzej Szeszo]

On 02/22/11 15:34, Joerg Schilling wrote:

Keyboard layout selection works OK now.

How did you implement this? Did you use the solution from Schillix-ON?
The problem with kbd layout selection was introduced by one of our 
OpenIndiana illumos-gate patches. I have backed out the patch and the 
problem went away.


http://hg.openindiana.org/mq_onnv-gate/rev/5ac79648e27e

Andrzej


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

Re: [oi-dev] illumos based OpenIndiana DVD

[Andrzej Szeszo]

On 02/22/11 15:14, Joerg Schilling wrote:

It seems we should talk about how to deal with with naming

Schillix-ON did already publish build 00 and build 01. Build 02 will be ready
soon.


Our updated iso will remain at version 148 (I have reverted the version 
bump) so versioning scheme is still up for discussion.


Andrzej



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

Re: [oi-dev] illumos based OpenIndiana DVD

[Andrzej Szeszo]

On 02/22/11 15:32, Joerg Schilling wrote:

We need to agree on a system that allows users to distinguish between the two
ONNV continuation projects Indiana and Schillix-ON.

As far as OpenIndiana distribution goes, we will probably be updating 
kernel bootmsg with the name/version of the upstream osnet codebase.


illumos based OI will display a message like below at boot:

OpenIndiana Build oi_148a 64-bit (illumos fe7962c08d1d)

Andrzej

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

Re: [oi-dev] illumos based OpenIndiana DVD

[Andrzej Szeszo]

The new image, which includes updated desktop wallpaper can be found here:

http://dlc.openindiana.org/isos/148/oi-dev-148a-x86-20110223-1.iso

It installs ok, etc.

Andrzej

On 02/22/11 04:28 PM, Andrzej Szeszo wrote:
I have actually new iso and repo on the way. With better illumos 
branding and version number reverted from 148.0.1 back to 148 as 
suggested by Albert.


There is no illumos logo anywhere on the desktop at the moment.

I have put "powered by illumos" label in /etc/release, /etc/motd. Also 
kernel bootmsg contains illumos changeset id.


It will be clear that the system is powered by illumos code.

Andrzej


On 02/22/11 15:38, Garrett D'Amore wrote:

Thanks everyone for putting in this effort.

I need to locate someone who can produce media.  I'm thinking I need to
produce a few hundred copies at least -- maybe even a thousand.
Opinions?

Also, do we have any artwork to put on the media and/or the sleeves?
(Ideally with the new illumos logo?)

I've not booted the new media *yet* but will do so today.  Is the new
illumos logo ("powered by") used on the OI desktop as well?

- Garrett

On Tue, 2011-02-22 at 06:27 -0800, ken mays wrote:

Andrzej,


As mentioned, your OI_148a Live DVD seems fine and better than the 
original OI_148 DVD in concept.


Having it available for SCALE online (check net load handling) and 
on spare
DVDs (mass copy on location!) seems to be on mark as I have 
thoroughly reviewed the OI_148a Live DVD for basic workstation use. 
Also, with an installation and Nvidia 270.26 driver, most users can 
use the 3D desktop capabilities very well. I already listed basic 
bugs I've observed elsewhere.


As for performance scalability under load testing with the Illumos 
kernel, I did comment on the recent Phoronix review with the older 
OI_148 distro.


See: 
http://www.phoronix.com/scan.php?page=article&item=multi_os_scaling&num=1


So, I consider this just things to review in the future. Right now 
the Live DVD is 'working fine' and the Perl 5.10.1 migration should 
come next.


There are still a few days to get some more tweaks done. No major 
showstoppers at the moment!


~ Ken Mays



--- On Tue, 2/22/11, Andrzej Szeszo  wrote:


From: Andrzej Szeszo
Subject: Re: [oi-dev] illumos based OpenIndiana DVD
To: oi-dev@openindiana.org
Date: Tuesday, February 22, 2011, 5:42 AM
On 02/21/11 20:25, Guido Berhoerster
wrote:

* Alasdair Lumsden

[2011-02-21 20:51]:

On 21 Feb 2011, at 19:48, Guido Berhoerster

wrote:

Great stuff. What are we going to do about

perl-584, are you

going to use packages from an older build?
Also how do we want to handle this in general,

just ship perl-584

from an older ONNV for maintaining backwards

compatibility and

switch all consolidations to perl-510?  I

have a JDS build

against perl-510 ready but AFAIK XNV and SFW

are still being

worked on.

I think we'll need to do 1 final perl-584 package

at a higher build number, which no longer delivers the
/usr/bin/perl symlink (plus potentially others if there are
any), so that the perl 510 package can provide that
instead.

That way when people upgrade, /usr/bin/perl gets

removed then re-added.

Does that sound feasible?

Sure, that's what we had planned. But do we make that

move now

for the demo CD? Also, should we only provide perl-584

by itself

or variants of the perl modules in JDS and SFW as

well?
I think it is a bit too late for the change to appear on
the demo CD. Not even 100% sure if we will get the CD out on
time in its current state.

The system installed by the CD will be using 
http://pkg.openindiana.org/dev repository by default

anyway. We obviously can update it at a later time with all
the perl584 changes.

Andrzej

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





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



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


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

[oi-dev] Distribution build system

[Andrzej Szeszo]

Hi All

The project is moving forward very slowly. I my opinion one of the main 
reasons behind it is lack of unified distribution build system.


Previous releases were put together manually. Probably one or two core 
contributors would be be able to repeat the whole process at this point 
without investing significant amount of time into learning how things 
fit together. We need distribution release and publishing process to be 
automated and repeatable.


There is a significant amount of bug reports in OpenIndiana bug tracker. 
Many of bugs require very simple changes to get fixed. URL updates or 
branding updates for example. Many contributors are more than capable of 
fixing such bugs. Because it is not clear what goes where, and also how 
to build and then test things many contributors simply don't bother 
looking at bugs at all.


I am proposing creating a unified distribution build system. A system 
that would build the whole distribution after issuing a single "make 
publish" or similar command.


Having such system will let us to release early, release often. It 
should improve the development progress in general. Bugfixes and 
security updates would get integrated in no time. New users would have 
an easy start. We could point new contributors at the build system and 
simply ask them to start hacking. Having all consolidations referenced 
from a single build system would make it clear to them where things go. 
Base system changes, etc. - core consolidations, new software - add-on 
consolidation directory, and so on.


Continuous build system could be implemented using the same tools on the 
OpenIndiana build machines, including the SPARC ones.


Many people will say that this is not possible and that even Oracle is 
not doing it. I say such system is possible but will require significant 
amount of work and significant amount of time to prepare. It will be 
worth the effort if done right. All major open source OS distributions 
have the release process automated in one way or another. I think this 
is the key to our success. Splitting the build and release engineering 
process between consolidation maintainers/owners based on Oracle model 
proved to not to work well for us.


I would like to start a dialog between the core contributors about such 
build system. Discuss whether it is needed or not. And if the decision 
is made that it is needed - discuss requirements, technical details and 
then actually implement it!


Andrzej

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

Re: [oi-dev] Distribution build system

[Andrzej Szeszo]

On 03/16/11 13:34, Chris Ridd wrote:

On 16 Mar 2011, at 12:12, Deano wrote:


>  A laudable aim but do we have the man power to do it, without negatively 
affecting our existing schedules for illumos and stable releases?

Can we afford*not*  to do it? Anything to make it easier and more practical for 
contributions the better...


We could start from the top, automate distro-importer and 
distro-constructor first while using pre-compiled components. Then 
gradually add consolidation build systems to the tree. This is just one 
of the possible approaches.


We definitely need automation/repeatability if we are thinking about 
maintaining stable release.


I would rather have the new release assembled using a new automated 
system even if it means getting the release out later.


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

Re: [oi-dev] oi-dev Digest, Vol 7, Issue 6

[Andrzej Szeszo]

Hi Butch

Individual consolidations that form OpenIndiana distribution are using 
different build systems. Some consolidations are available in binary 
form only.


I propose creating a unified infrastructure on top of all build systems 
so that full or incremental builds of the whole OS could be done with a 
single command.


I don't have much experience with continuous build systems but I suspect 
such infrastructure could be used with something like Hudson/Jenkins. I 
am sure Jenkins can start make command after noticing a change in the 
version control system.


Andrzej

On 03/16/11 15:34, Butch Whitby wrote:

I've been following the list for a while now, and have kept quiet
partially due to time constraints, but mostly because I think I'm
going to be most helpful in the documentation arena but I have a
couple of questions about this.

Please overlook my ignorance on this topic I'm an admin not a
programmer and have zero experience with continuous build systems.   I
have limited understanding of how they actually work,  and haven't had
the time to really dig into the topic.  It seems there are a lot of
"auto builders" available already.  At a cursory glance I can see it's
a far cry from a simple setup but would definitely be worth doing
right.  Am I misunderstanding or are you proposing to use a continuous
integration system for this? Would something like Hudson be viable?

Or are you talking about developing a framework that could be provided
in a packaged form for download to a developers system?  Or even a
combination of both?

I'll help in any way I can.


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

Re: [oi-dev] Distribution build system

[Andrzej Szeszo]

Thanks for the link Alan. We will definitely evaluate it.

Andrzej

On Wednesday, 16 March 2011, Alan Coopersmith
 wrote:
> On 03/16/11 09:12 AM, Chris Ridd wrote:
>> FWIW at work we have an XML file describing each release as (essentially) a 
>> number of git repos + tags to checkout, and then what script to run to build 
>> each given repo. Our overall build script goes through that XML in order, 
>> and is able to do "the right thing". This gives us pretty reproducible 
>> releases.
>
> Sounds very much like jhbuild, which is often used to build projects
> like GNOME & X.Org with dozens or hundreds of individual modules to
> checkout and build.
>
> http://www.freedesktop.org/wiki/Software/jhbuild
>
> --
>         -Alan Coopersmith-        alan.coopersm...@oracle.com
>          Oracle Solaris Platform Engineering: X Window System
>
>
> ___
> 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] Distribution build system

[Andrzej Szeszo]

On 17/03/2011 13:26, Deano wrote:

If we are going to this effort than we should IMHO do it probably and break
the direct link between OI and consolidations. I can hear the sharp intakes
of breath from here, from OI point of view consolidations are just groupings
of certain packages and files put together by an upstream provider, they
don't necessarily make any sense in term of useable packages down at the
users end. Example abound of odd inclusions that made sense to the original
consolidation author but not to the user (gruff is an known example).

 From a users, developers and installers point of view, I want to
get/update/remove X without knowing or caring about consolidations,
therefore they should become hidden behind our one stop build system.

If we whilst doing this work, we add a new OI thing (deliberately not giving
it a name) that provides OI useful chunks and mapping internally through
upstream consolidations and builds and grabs the bits of the version it
wants, we achieve this independence at the same time.

Effectively treating consolidation packages now as just another form of
source tree, to mine and use as we see fit.

Why go to this effect?

Because at the moment we can't control where things go, what versions we use
and even what our users can install/remove. By having a single build system
work in chunks of OI decided work, we can easily begin to control
where/what/how.

You press the build button and it knows about upstream consolidation and OI
chunks, out pops a distro with exactly in the state we set up, rather than
constant fighting upstream changes when and if they change.  We take pieces
as and when we require them and they meet our demands.

In some ways I'm not suggesting dropping consolidations but instead have a
system that mine's other consolidations. Adding a 'use file X in
consolidation Y' rather than 'depend on consolidation Y' operator.


Breaking the link with upstream consolidations may be the thing we will 
ultimately have to do. For now, while the development of the 
consolidations like sfw, jds, xnv, ips, caiman happens in the open we 
probably want to continue using them in their current form for as long 
as possible. We don't have manpower to re-create all build recipes and 
packages at the moment.


Creating a wrapper on top of existing consolidations and their build 
systems would be the simplest thing to do right now.

>>  Many people will say that this is not possible and that even Oracle is
>>  not doing it. I say such system is possible but will require significant
>>  amount of work and significant amount of time to prepare. It will be
>>  worth the effort if done right. All major open source OS distributions
>>  have the release process automated in one way or another. I think this
>>  is the key to our success. Splitting the build and release engineering
>>  process between consolidation maintainers/owners based on Oracle model
>>  proved to not to work well for us.

>
>Anything is possible when it comes to code, and this is no exception.
>Anyone who says it can't or shouldn't be done is wrong.
>
>If Oracle aren't doing it, its because they are behind the times. We
>should work "smarter, not harder". Working smarter is definitely the key
>to our success.
>
>We are "stuck in the mud" until we do this.

Yep I agree, I think however instead of digging ourselves out of the mud
piece by piece, we should look at the tires themselves.


>>  I would like to start a dialog between the core contributors about such
>>  build system. Discuss whether it is needed or not. And if the decision
>>  is made that it is needed - discuss requirements, technical details and
>>  then actually implement it!

>
>It is needed. The decision is a no brainer, so it gets my vote. The
>question is how we implement it.
>
>Would anyone be interested in a Hackathon to get this work completed
>over a weekend in the near future?

If the hackathon is about a month away I'd happily get involved (too busy
right now).

As a one stop build system is pretty big thing, I do think we should produce
a discussion document, with both short and long term goals. I'd rather us
spend longer and do it right, then quickly add another complicated layer
that makes sense now but will just become another burden down the line.
I reckon we quickly figure out short list of requirements and start 
implementing the system. From top to bottom. Starting with the 
distro-importer and distro-constructor, just like Guido is suggesting in 
another message. Then move on to adding support for the actual build 
systems.

I wasn't involved during the OSol era so I can't comment on whether the
current overall distribution design was useful then, but at this moment, I'm
not sure I see its strengths. Its seems instead of taking the amazing source
and tech we have and pushing it forward we are largely fighting to keep our
head above water and I largely see that as a fault of the development and
distribution model which doesn't 

Re: [oi-dev] Distribution build system

[Andrzej Szeszo]

Hi TJ,

This is great that you are trying TWW tools.

I was actually thinking about using a GNU make based system, possibly 
with few helper scripts.


The advantage of using Makefiles is that everyone is familiar with them, 
incremental builds are possible and also parallel builds are possible.


Can you point me to some docs about TWW tools describing what they can 
do? I have never heard about them :)


Thanks,

Andrzej


On 04/06/11 16:44, TJ Yang wrote:

On Wed, Apr 6, 2011 at 10:43 AM, TJ Yang  wrote:

Hi, Deano

I am converting all the consolidations building instruction into xml files.
and this xml file can be playbacked but /opt/TWWfsw/bin/sb
(sb=software build) tool.

s/but/by/


Very similar following command to create  O.I. CD/USB image.  except
the abstraction is one level higher.

  pfexec distro_const build ./new_slim_cd_x86.xml

So for this digitization effort is to generate O.I. sparc image to
provide alternative OS that our Sparc hardware can run freely.

I don't expect it got adopted by this group since TWW Inc.'s GNU
tool-sets is not well-known.  But I am documenting this approach at
R1.

tj

R1: http://wiki.openindiana.org/oi/CPAMTWW

On Wed, Apr 6, 2011 at 7:13 AM, Deano  wrote:

Hello,

The conversation on the Distributed build system stalled on finer points but
the large idea seemed to have everyone support. A continuous build system,
that automatically went through all consolidations would be a major step
forward for the OI development process.
So lets get things moved on a least for the most basic system we all agree
would be useful. I looked into some more advanced build systems (Scons, WAF,
etc.) but tbh all were slightly overkill for what the basic simple system
needs which is simply a makefile or script that grabs each consolidation,
sets up the environment, builds and moves onto the next (with appropriate
error handling etc.)

Aszezo has some idea and how to get this party started I believe, so
probably best for him to make more concrete suggestions?

If we could get a empty framework in place and running, we could then pop in
each consolidation in turn when ready, and therefore gradually get our
continuous build system working, the particularly troublesome ones don't
have to stop the easier ones.

A hack-a-thon might make an ideal time for people to get together and push
this all together?

Thoughts please,
Deano



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




--
T.J. Yang






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

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

[Andrzej Szeszo]

I quite like the inFocus theme. Very simple and good looking. The 
default colour scheme is too dark though.


Andrzej

On 04/13/11 04:19 PM, 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.


Cheers,

Alasdair

___
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] Refreshed /dev-il repo and oi_148b iso images

[Andrzej Szeszo]

Hi Devs

On Tuesday I have refreshed illumos based /dev-il repo with mainly g11n 
fixes and also pkg-gate fixes necessary to get distro-constructor 
working. I am using the packages from /dev-il at home and at work and 
things seem to work good enough.


I have also spent some time recently and generated iso images based on 
/dev-il repo. They can be found here: 
http://dlc-int.openindiana.org/respins/isos/148b/ .


Feel free to use http://pkg.openindiana.org/dev-il repo and isos on your 
OpenIndiana development systems.


Cheers,

Andrzej

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

[oi-dev] Build 151 status update

[Andrzej Szeszo]

Hi All

After running build 151 packages for about three weeks I have finally 
found some time to polish things up and re-compile/re-publish 
consolidations.


My packages from three weeks ago required some modifications to get them 
to install. The ones I am assembling at the moment using 
distro-importer/distro-publisher will install out of the box.


Expect updates to /dev-il repo and new ISOs later today :)

Andrzej

___
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

[Andrzej Szeszo]

On 05/23/11 04:22 PM, 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.
I think I would be after linking libgcc in statically by default. I 
would help binaries produced by ISVs to be more portable especially 
after we switch to a newer compiler in the future.

2. Follow the library layout guidelines set down by SFE
I would look at the guidelines again. If we are deciding that gcc will 
be the default/official compiler maybe we could use the standard paths 
for its libraries, etc.

3. Compile gcc to use Sun ld, but GNU as

+1

As Sun ld and GNU as are recommended by the upstream. 
http://gcc.gnu.org/install/specific.html


Andrzej

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

Re: [oi-dev] Build 151 status update

[Andrzej Szeszo]

Hi All

Due to last minute packaging fixes I wasn't able to update the /dev-il 
repo last night. I have pushed new packages to /dev-il repo this morning 
and image-updated my 148b machine from it. It appears to be working ok 
so far.


If you plan to build illumos-gate on oi_151 please note that bug 
https://www.illumos.org/issues/495 has been re-introduced (original 
patch has not landed in our repository it seems). Also, all 
consolidations have version number set to 151. Make sure you add:


ONNV_BUILDNUM=151; export ONNV_BUILDNUM

to your illumos.sh nightly env file to make the resulting packages 
installable on your system.


I have generated initial live dvd image but installer is not working for 
some reason (installer window disappears after selecting time zone). 
I'll be investigating it later today.


Please let us know if you encounter any issues with the updated-repo.

Cheers,

Andrzej


On 05/23/11 02:41 PM, Andrzej Szeszo wrote:

Hi All

After running build 151 packages for about three weeks I have finally 
found some time to polish things up and re-compile/re-publish 
consolidations.


My packages from three weeks ago required some modifications to get 
them to install. The ones I am assembling at the moment using 
distro-importer/distro-publisher will install out of the box.


Expect updates to /dev-il repo and new ISOs later today :)

Andrzej


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

Re: [oi-dev] Build 151 status update

[Andrzej Szeszo]

Hi Ken

I can confirm I am getting the same problem with the GUI tool on b148. 
The same system can be upgraded using pkg(5) command just fine.


Andrzej

On 05/24/11 02:11 PM, Ken Gunderson wrote:

On Tue, 2011-05-24 at 12:24 +0100, Andrzej Szeszo wrote:

Hi All

Due to last minute packaging fixes I wasn't able to update the /dev-il
repo last night. I have pushed new packages to /dev-il repo this morning
and image-updated my 148b machine from it. It appears to be working ok
so far.

If you plan to build illumos-gate on oi_151 please note that bug
https://www.illumos.org/issues/495 has been re-introduced (original
patch has not landed in our repository it seems). Also, all
consolidations have version number set to 151. Make sure you add:

ONNV_BUILDNUM=151; export ONNV_BUILDNUM

to your illumos.sh nightly env file to make the resulting packages
installable on your system.

I have generated initial live dvd image but installer is not working for
some reason (installer window disappears after selecting time zone).
I'll be investigating it later today.

Please let us know if you encounter any issues with the updated-repo.

I just tried to update 148b and via Update Manager gui tool. The update
failed due to complaints that "This is a live image.  The install
operation can't be performed."

Also, the "Read the release notes advisory points to Oracle:

<http://download.oracle.com/docs/cd/E19963-01/>

Shouldn't we have it pointing to OI specific notes at openindiana.org??




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

Re: [oi-dev] Build 151 status update

[Andrzej Szeszo]

Hi All

I have uploaded initial text-installer ISO and USB images to:

http://dlc-int.openindiana.org/151/

You can use text-installer images to install OpenIndiana on new 
machines. To get all GUI bits in one go you can install 
pkg:/slim_install meta-package (and then uninstall it once all the 
packages it depends on are sucked in).


Fixing gui-installer is still in progress.

Cheers,

Andrzej


On 05/24/11 12:24, Andrzej Szeszo wrote:
I have generated initial live dvd image but installer is not working 
for some reason (installer window disappears after selecting time 
zone). I'll be investigating it later today. 


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

Re: [oi-dev] pkg5 Linked Images

[Andrzej Szeszo]

Hi All

fattach_all_zones() function in zoneproxyd.c is using a new call not 
present in the library delivered by illumos.


The initial implementation of fattach_all_zones() in the webrev 
mentioned here is not using this new call:


http://mail.opensolaris.org/pipermail/pkg-discuss/2011-May/026359.html

I took fattach_all_zones() implementation from the webrev and the latest 
pkg5 code compiled OK for me on OI 151 based system.


I have not tested the resulting binaries yet though.

Regards,

Andrzej

On 05/30/11 06:37 PM, Alasdair Lumsden wrote:

Hi All,

Now that 151 is almost out the door, we need to start looking beyond this to 
the next release. I'd like to kick this off looking at pkg5, since Userland 
would benefit from a newer pkg version.

The pkg team integrated "Linked Images" in build 165:

http://mail.opensolaris.org/pipermail/pkg-discuss/2011-May/026479.html

I haven't yet had a chance to read the pkg5 linked images design document, but 
from what I understand it's a larger change that may give us a headache without 
access to the Oracle onnv-gate.

Has anyone had a chance to read over the design doc? It's over at (this is from 
2010 so it might be out of date):

http://mail.opensolaris.org/pipermail/pkg-discuss/2010-March/021573.html

If anyone has read it, is this something that we should avoid for now, and go 
with an earlier build, such as 164? Does anyone know of any commits to pkg5 
that might bite us between build 151 and 164?

We can also look at getting pkg5 building within the Userland framework itself, 
but I'll cover this off in a separate mail/thread to keep this one specifically 
about linked images and the pkg5 version we pick for the next dev build.

Cheers,

Alasdair
___
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] Git as a version control system for new OI projects

[Andrzej Szeszo]

Hi All

I would like to ask about your opinions on using Git for new OI 
projects. We've been using Mercurial exclusively so far mainly because 
most of the upstream repositories were using it. There is no reason for 
us to stick with it for new projects though in my opinion.


Using Git for new projects will enable Git and Mercurial users to work 
on the same repository without too much effort. Mercurial users, after 
enabling hg-git extension [1], will be able to use Git repository in the 
same way as normal Mercurial repo, for example:


$ hg clone git://github.com/joyent/illumos-live.git
destination directory: illumos-live
Counting objects: 115, done.
Compressing objects: 100% (85/85), done.
Total 115 (delta 13), reused 115 (delta 13)
importing git objects into hg
updating to branch default
92 files updated, 0 files merged, 0 files removed, 0 files unresolved
$

Letting developers to choose their vcs frontend is one nice thing. Git's 
lightweight branches and the way they work are also very appealing. 
Also, more people are familiar with Git than with Mercurial so new 
developers may find it easier to get started with the project if its 
source is managed using Git.


Let us know what you think.

Cheers,

Andrzej

1. http://hg-git.github.com/


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

Re: [oi-dev] Git as a version control system for new OI projects

[Andrzej Szeszo]

Hi All

Latest upstream ips/pkg5 tools need more and more changes to make them 
work with OI and illumos. I have asked the version control system 
question because I wanted to create a repository for pkg5 with the changes.


I wanted to avoid mercurial + mq patch queue solution and started 
experimenting with git as I've heard good things about its rebase feature.


With some help from hg-git I was able to prepare git repository with 
untouched branch which is tracking upstream pkg-gate + branches with 
local modifications. I was then able to pull in upstream changes and 
rebase customized branches without too much effort.


Nice rebase functionality, cheap non-permanent branches, ability to use 
hg frontend with hg-git extension and also availability of very good 
'Successful Git branching model' document [1] makes Git worth 
considering on the backend in my opinion.


Also, I think model descibed at [1] is worth adopting in terms on how to 
organize the repository/branches. It would save us time on re-inveting 
repository layout and documenting it for starters. Also, apparently it 
proved to be successful for many people. People at Joyent use this model 
- they can't be wrong ;) [2]


By the way - I quite like mercurial. If someone can demonstrate how to 
do rebase but using mercurial I'd be willing to try it out. Thanks in 
advance!


In the mean time I would like go ahead and create test pkg5 git 
repository on one of OI infrastructure machines if there are not (too 
m)any objections? I'll configure it so only members of specific group 
can push changes to it.


Cheers,

Andrzej

1. http://nvie.com/posts/a-successful-git-branching-model/
2. https://github.com/joyent/illumos-joyent/blob/master/README.joyent

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

Re: [oi-dev] OpenSSL 1.0.0 replacing 0.9.8 in userland-gate = massive headache

[Andrzej Szeszo]

I personally don't have a preference. We may as well go with 3 as 
Garrett is suggesting.


We could provide 0.9.8 compatibility libs inside 1.0.0 package during 
the transition period.


Andrzej

On 04/09/2011 00:30, Garrett D'Amore wrote:

So, I believe that 3 might not be such a bad option, because I think technically the 
openssl package and APIs have historically been considered "Private" (i.e. 
unstable and not for use by ISVs.)  This is the Solaris view of it at any rate.

- Garrett

On Sep 3, 2011, at 1:56 PM, Alasdair Lumsden wrote:


Hi All,

In Oracle's official userland-gate, they have replaced OpenSSL 0.9.8 with 
1.0.0. This has massive ramifications, because everything linked against 
OpenSSL 0.9.8 breaks as soon as library/security/openssl gets upgraded, 
including pkg, which is all kinds of fun.

There are two realistic options, and one unrealistic idealistic option:

1. Don't bother upgrading to OpenSSL 0.9.8, worry about it another day

2. Do the upgrade, but also ship an openssl 0.9.8 compatibility package and 
make the new one depend on it - this lets old software continue to run whilst 
recompiles pick up the new OpenSSL. Slowly transition to OpenSSL 1.0.0.

I've made such a package by pkgrecv'ing openssl 0.9.8, hacking out everything 
except the libraries and republishing it locally as 
library/security/openssl/compatibility/0.9.8 - works fine.

3. Do the upgrade. Rebuild everything against OpenSSL 1.0.0, and release 
rebuilt software with the openssl 1.0.0 upgrade, in one simultaneous release.

Obviously 3 has ramifications beyond the base system, because any third party 
software that depends on OpenSSL 0.9.8 will break. This is why having a 
compatibility package is probably necessary regardless.

I've provided a list of software below that depends on OpenSSL, which affects 
these consolidations:

gnome
ips
l10n
oi-build
osnet
sfw
vpanels

Thankfully those are all ones we can easily rebuild, (indeed, sfw is gone), 
with the exception of gnome (JDS) which, without a replacement for Distro 
Importer in the new continuous integration world, is quite tricky.

My personal preference is 2, although ideally we need to convert OpenSSL 0.9.8 
to oi-build format to make the compatibility package, for sustaining/security 
patches. Hacking the package together was good for a proof of concept but we 
need to be able to rebuild it/update it.

Comments welcome!

Cheers,

Alasdair


consolidation/sfw/sfw-incorporation - sfw sfw
crypto/gnupg - oi-build sfw
database/postgres-82 - sfw sfw
database/postgres-82/contrib - sfw
database/postgres-82/developer - sfw
database/postgres-82/library - sfw
database/postgres-83 - sfw sfw
database/postgres-83/contrib - sfw
database/postgres-83/developer - sfw
database/postgres-83/library - sfw
database/postgres-84 - sfw sfw
database/postgres-84/contrib - sfw
database/postgres-84/developer - sfw
database/postgres-common - sfw
database/postgres/pg_upgrade - sfw
database/postgres/pgadmin - sfw
desktop/gftp - gnome
desktop/irc/xchat - gnome
desktop/remote-desktop/rdesktop - oi-build gnome
desktop/system-monitor/gkrellm - gnome
desktop/torrent/transmission - gnome
diagnostic/httping - oi-build sfw
diagnostic/nmap - oi-build sfw
library/gnome/gnome-vfs - gnome
library/libtorrent - oi-build sfw
library/neon - oi-build sfw
library/openldap - sfw
library/perl-5/net-ssleay - sfw
library/perl-5/postgres-dbi - sfw
library/print/cups-libs - oi-build sfw
library/python-2/m2crypto - oi-build ips ips
library/python-2/m2crypto-26 - oi-build
library/python-2/pycurl - oi-build ips ips
library/python-2/pycurl-26 - oi-build
library/python-2/pyopenssl-24 - sfw
library/python-2/pyopenssl-26 - oi-build sfw
library/raptor - gnome
library/security/pam/module/pam-pkcs11 - oi-build sfw
library/security/trousers - oi-build sfw
library/xmlrpc-c - sfw
mail/fetchmail - oi-build sfw
mail/mutt - oi-build sfw
network/chat/irssi - gnome
network/dns/bind - oi-build oi-build sfw sfw
network/nntp/slrn - oi-build sfw
network/ssh - osnet osnet
network/ssh/ssh-key - osnet
network/tor - sfw
package/svr4 - osnet
print/cups - oi-build sfw
print/filter/hplip - oi-build sfw
redistributable -
runtime/erlang - oi-build sfw
runtime/python-24 - gnome
runtime/python-25 - gnome
runtime/python-26 - gnome
runtime/ruby-18 - oi-build sfw
runtime/tcl-8/tcl-openssl - oi-build sfw
service/database/postgres-82 - sfw
service/database/postgres-83 - sfw
service/database/postgres-84 - sfw
service/network/dns/bind - oi-build sfw
service/network/load-balancer/pen - sfw
service/network/ntp - oi-build sfw
service/network/smtp/sendmail - osnet
service/network/ssh - osnet
service/network/wpa - osnet
service/security/kerberos-5 - osnet
service/security/stunnel - sfw
system/boot/wanboot - osnet
system/input-method/iiim - l10n
system/library - osnet
system/library/security/crypto/pkcs11_kms - osnet
system/management/cim/pegasus - sfw
system/management/ipmitool - oi-build sfw
system/management/rad - vpanels
system/management/visua

Re: [oi-dev] 1465 oi-build openssl has too much quoting around LINT_FLAGS

[Andrzej Szeszo]

Looks good.

Andrzej

On 04/09/2011 23:18, Alasdair Lumsden wrote:

Hi All,

Requesting review for another trivial change:

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

https://bitbucket.org/alasdairlumsden/oi-build/changeset/73e660e38dd5

Cheers,

Alasdair

___
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] 1479 Qemu delivered by pkg:/system/qemu/kvm is broken

[Andrzej Szeszo]

I propose the change below to workaround https://www.illumos.org/issues/1479

diff --git a/components/qemu-kvm/Makefile b/components/qemu-kvm/Makefile
--- a/components/qemu-kvm/Makefile
+++ b/components/qemu-kvm/Makefile
@@ -46,6 +46,7 @@
 CONFIGURE_OPTIONS += --disable-kvm-device-assignment
 CONFIGURE_OPTIONS += --enable-trace-backend=dtrace
 CONFIGURE_OPTIONS += --target-list="i386-softmmu x86_64-softmmu"
+CONFIGURE_OPTIONS += --enable-debug

 COMPONENT_BUILD_ENV += PATH=$(PATH):/usr/sbin

Andrzej


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

Re: [oi-dev] 1479 Qemu delivered by pkg:/system/qemu/kvm is broken

[Andrzej Szeszo]

Hi Garrett

I propose the change to workaround the problem for now to make qemu-kvm 
more usable. It is not a proper fix I agree.


Without --enable-debug, CentOS 6 ISO fails to uncompress initial ramdisk 
and kernel is unable to find root device because of that . Illumos 
guests get stuck at boot and are not usable at all. Ubuntu guests seem 
to be fine.


With --enable-debug CentOS and Illumos guests run fine.

--enable-debug seems to be set by default by Joyent's build.sh sript 
used to build Qemu.


We can wait for a proper fix I guess. Robert Mustacchi from Joyent is 
looking at the problem already.


In the mean time though qemu-kvm from the repo will have limited use.

Andrzej

On 08/09/2011 16:15, Garrett D'Amore wrote:

This feels like a hack rather than a fix.  And a poor one at that.  The 
upstream bug indicates that the upstream have no such problems, and the failure 
seen is indicative of a failure to find the boot device in the guest.  I 
recommend further investigation.

- Garrett

On Sep 8, 2011, at 7:28 AM, Andrzej Szeszo wrote:


I propose the change below to workaround https://www.illumos.org/issues/1479

diff --git a/components/qemu-kvm/Makefile b/components/qemu-kvm/Makefile
--- a/components/qemu-kvm/Makefile
+++ b/components/qemu-kvm/Makefile
@@ -46,6 +46,7 @@
CONFIGURE_OPTIONS += --disable-kvm-device-assignment
CONFIGURE_OPTIONS += --enable-trace-backend=dtrace
CONFIGURE_OPTIONS += --target-list="i386-softmmu x86_64-softmmu"
+CONFIGURE_OPTIONS += --enable-debug

COMPONENT_BUILD_ENV += PATH=$(PATH):/usr/sbin

Andrzej


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


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


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

[oi-dev] New OI 151a test ISO available

[Andrzej Szeszo]

Hi All

I have uploaded new live iso for testing. It is available here:

http://dlc-int.openindiana.org/151a/oi-dev-151a-x86-20110908-1.iso

Please test if you can install system from it on your test boxes.

Please note that installed system will be configured to use 
http://pkg.openindiana.org/dev publisher URL which at the moment 
contains b148 packages only. The ISO was built using packages from a 
repository put together by Richard Lowe which is not currently available 
externally. Installing packages will not work correctly because of that.


Text-install test ISO will be available in couple hours.

Andrzej


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

Re: [oi-dev] New OI 151a test ISO available

[Andrzej Szeszo]

Hi All

Text-install test ISO is available here:

http://dlc-int.openindiana.org/151a/oi-dev-151a-text-x86-20110908-1.iso

Andrzej

On 08/09/2011 18:00, Andrzej Szeszo wrote:
Text-install test ISO will be available in couple hours. 


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

Re: [oi-dev] New OI 151a test ISO available

[Andrzej Szeszo]

The change below to slim_source fixes the problem with the grub menu. 
/dev-il repo and old 151 ISOs were built with the change below applied.


Andrzej

diff -r 733997758353 usr/src/lib/libict_pymod/ict.py
--- a/usr/src/lib/libict_pymod/ict.py   Thu Apr 28 11:46:57 2011 +0100
+++ b/usr/src/lib/libict_pymod/ict.py   Sun Sep 11 19:44:45 2011 +
@@ -1181,7 +1181,7 @@
 # Note there are TABs in the blow expression.
 # sedcmd = 'sed \'/\-B[ ]*\\$ZFS-BOOTFS/ i\\\nbootfs ' +\
 sedcmd = 'sed \'/\-B[  ]*\\$ZFS-BOOTFS/ i\\\nbootfs ' +\
-rootdataset + '\' ' + self.grubmenu + ' > ' + newgrubmenu
+rootdataset + '\\\n\' ' + self.grubmenu + ' > ' + newgrubmenu
 status = _cmd_status(sedcmd)
 if status != 0:
 prerror('Adding bootfs command to grub menu fails. ' +



On 10/09/2011 04:29, Alasdair Lumsden wrote:

Hi TJ,

Was your grub issue with the Text Installer or the Live ISO?

It looks like the splashimage bits are missing so your bootfs line 
runs on to the kernel line. I can't reproduce it with the Live ISO 
(gui installer) so am wondering if you installed from the Text installer.


Cheers,

Alasdair

___
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] New OI 151a test ISO available

[Andrzej Szeszo]

Hi All

*20110912-1* images which contain a number of fixes are available here 
for testing: http://dlc-int.openindiana.org/151a/


Matching repository is available at http://pkg.openindiana.org/dev-il. 
Please change the URL of the openindiana.org publisher after installing 
the system to it if you want to install packages, etc. For example:


sudo pkg set-publisher -O http://pkg.openindiana.org/dev-il openindiana.org

Ultimately /dev-il packages will be published to /dev repo and such 
change will not be required in the future.


Regards,

Andrzej

On 08/09/2011 18:00, Andrzej Szeszo wrote:

Hi All

I have uploaded new live iso for testing. It is available here:

http://dlc-int.openindiana.org/151a/oi-dev-151a-x86-20110908-1.iso

Please test if you can install system from it on your test boxes.

Please note that installed system will be configured to use 
http://pkg.openindiana.org/dev publisher URL which at the moment 
contains b148 packages only. The ISO was built using packages from a 
repository put together by Richard Lowe which is not currently 
available externally. Installing packages will not work correctly 
because of that.


Text-install test ISO will be available in couple hours.

Andrzej



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

Re: [oi-dev] DTrace probes in Python 2.7 (and next 3.3)

[Andrzej Szeszo]

Hi Jesus

Just noticed that there is a python 2.7 package in Oracle's userland 
repo here:




It includes DTrace patch. Did you see/use that?

Andrzej

On 24/11/2011 16:46, Jesus Cea wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all.

I have spend some time trying to integrate DTrace probes in official
Python: Currently I have a patch to python 2.7, and my plan in to
integrate officially in 3.3.

The initial probes were based on previous work from OpenSolaris, and
similar, but currently I have quite a few more probes. Current details
in


The probes are tested under Solaris 10 x86 and x86-64. I would need
somebody to try on Solaris 10 Sparc (32 and 64 bits), Solaris 11,
OpenIndiana, FreeBSD (seems to need a kernel recompilation to enable
user mode tracing, check Google), Mac (I doubt it works as is), etc.,
any other platform running DTrace. What about SystemTap compatibility?

Details:

How to check:.

The easier way to get the patch is to clone my repository at
  (with mercurial) and move to the
branch "dtrace-issue13405_2.7". Keep the clone around if you plan to
try future versions of this patch, including the future 3.3 version.

You can manually apply the patch in
  to python 2.7.2+
sourcecode. The patch is developed against version 3c3009f63700
(2011-11-14). It might not apply cleanly to 2.7.2 sourcecode (not
checked). I will provide a direct patch to 2.7.3 when available. Maybe
to 2.7.2 if there is demand.

This is still work in progress. I will improve support with your
feedback. I am considering probes to monitor GIL and thinking how to
monitor C function calls from Python in an easy and fast way. Feedback
very welcomed.

Please, if you care about this, test it and provide some feedback :).

PS: Better post feedback in the bug tracker that by personal email :-).

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/

j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTs50+Jlgi5GaxT1NAQKWUwQAnl99nFd6nM5yiPGl8yw4/YR81BTIS563
3wyPz74o5wAE3k9quexr+UPCndPogiH6nhnJ9DNXfUpVyaouGG/tGEbZn/x+h7Dv
jc5616IRnHxGAxxuoTscCRRN88zsPVY6i71QMxK2BOS+zXMdcrsBajLrmx1UIzHY
Elr7fq8L988=
=uQM5
-END PGP SIGNATURE-

___
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] pkg5 question

[Andrzej Szeszo]

Hi John

It is possible that the current version of pkg5 is relying on the 
strndup now (yes S11 and illumos both have this function now). For 
s10-userland we are using a bit older version of pkg5 from March 2011 
and have not attempted to update it to the current one yet.


We don't see strndup problem on Solaris 10 probably because we use an 
older codebase. Additionally we apply some patches which you can find 
here: 
. 
Some of the patches are environment specific. Some of the were required 
to get things working on Solaris 10 in general.


Here are the details the pkg5 from s10-userland is at:

changeset:   2251:00ccbd44fcbc
tag: tip
user:Padraig O'Briain 
date:Fri Mar 11 13:38:36 2011 +
summary: 17213 Typos in man page for packagemanager and pm-updatemanager

You can run 'hg update 00ccbd44fcbc' to switch to this version.

Andrzej


On 01/12/12 02:06 PM, John Center wrote:

On 01/11/2012 04:05 PM, John Center wrote:

_actions.so calls strndup(), which doesn't exist on S10.  (Does S11 have
it now?)  I can add a strndup.c to fix this, but I'm not sure how to do
it.  The pkg gate source doesn't use makefiles for the modules
directory, it looks like setup.py does the compiling&  linking itself,
so I'm not sure what gets added where.  If anyone has a clue how to add
this in&  have it built, I'd greatly appreciate the help.  Otherwise,
I'll have to paste the function into _actions.c.

I made an assumption here that this would be the preferred way to fix 
this.  Am I wrong?  I do plan to submit my changes upstream, once I 
get something working.


Thanks.

-John




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

[oi-dev] pkg5 improvements

[Andrzej Szeszo]

Hi All

I have re-started getting current pkg5 codebase in shape few days ago.

I wanted to get zone support working better on top of 
illumos/OpenIndiana. It is still work in progress but linked images and 
system repository stuff seems to work OK.


I need to prevent scripts from creating zone boot environments still as 
illumos doesn't support that (rpool/zones/zone1/ROOT/zbe-1, zbe-2, 
etc.). Alternative would be to add such support. I have not looked at it 
yet.


The code lives here: https://github.com/aszeszo/pkg5

You can check it out using git or mercurial (with hg-git extension enabled):

git clone git://github.com/aszeszo/pkg5.git
hg clone git://github.com/aszeszo/pkg5.git

And then build it and generate packages by running:

cd src && make install && cd pkg && make install

Oh, one file needs to be edited manually to get linked images working 
(it is part of illumos-gate):


--- /usr/lib/brand/ipkg/config.xml.origMon Jan 16 18:08:42 2012
+++ /usr/lib/brand/ipkg/config.xmlMon Jan 16 18:08:09 2012
@@ -39,9 +39,9 @@

/usr/lib/brand/ipkg/pkgcreatezone -z %z -R %R
a:c:d:e:hk:P:p:suv
- 
+ /usr/lib/brand/ipkg/boot %z %R
/usr/lib/brand/ipkg/prestate %z %R 2 0
- 
+ /usr/lib/brand/ipkg/halt %z %R




Cheers,

Andrzej


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

Re: [oi-dev] Addition of zabbix agent to oi-build

[Andrzej Szeszo]

Hi Adam

Things look OK in general. Nice work!

You define additional users and groups in the p5m manifest which you 
have not created yet. See 
 
for an example. Same with the directories. You define any new ones in 
the p5m file.


In general, the kind of software like zabbix agent should be delivered 
as 32-bit only. I doubt there will be any benefit of the 64-bit version.


Also, I think I would remove lines which define CFLAGS, 
CONFIGURE_PREFIX  and CONFIGURE_SCRIPT and use the defaults. And change 
the BUILD/INSTALL_64 to BUILD/INSTALL_32.


Thanks for working on the package.

Cheers,

Andrzej


On 01/ 9/12 12:00 AM, Adam Števko wrote:

Hello,

I have created my first package for oi-build - zabbix-agent. Zabbix is 
monitoring software used for server and service monitoring by companies all 
over the world.

I had some problems building the zabbix-agent (the problem is known to me, but 
no idea how to fix it). I found workaround, but I do not find it a proper 
solution. I would like to have the Makefile and other stuff reviewed. The 
commit can be found here: 
https://bitbucket.org/xenol/oi-build/changeset/93c7d6f187db

There are some things I would like to ask about:
- if the service needs to have some directories and user/group added to the 
system, where should I define that?
- what is the proper way to select with version to build, e.g. 64bit on 64bit 
CPU and 32bit on 32bit. I would like to take advantage of having 64bit software 
on 64bit capable CPUs.

If there are any problems regarding the Makefile, please let me know. I would 
like to fix them and have zabbix-agent added to the oi-build. When agent is 
done and committed to the oi-build, I will follow with zabbix-server and 
zabbix-proxy.

xenol
___
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] pkg5 improvements

[Andrzej Szeszo]

It could be chicken and egg problem. pkg5 packages might be depended on 
modules delivered by new pkg5. Add  pkg.depend.bypass-generate=.* to the 
'file' lines in p5m files for files which fail to resolve. Publish and 
install built packages. Then try repeating the process after removing 
the pkg.depend.bypass-generate lines you have added earlier.


Andrzej

On 01/21/12 10:18 PM, Bart Coddens wrote:

cd pkg
make install

At the end of this step I get dependency errors

Do I miss something ? 


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

[oi-dev] ISOs and packages with current Oracle's userland and jds

[Andrzej Szeszo]

Hi All

Please check a message titled "New illumos distro bootstrap kit
available" I sent to develo...@lists.illumos.org out.



There are some links to ISOs and packages in the message ;)

Andrzej

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

Re: [oi-dev] Resignation as OI Lead

[Andrzej Szeszo]

Hi Alasdair,

I remember exactly the moment when you said on IRC that EveryCity is
sponsoring OpenSolaris-like distro effort. I was very excited that you were
doing it. I am glad it was you who has started it! Thank you very much for
starting OpenIndiana, Alasdair!

I am sure the project will carry on. Its userbase is vast and it's got
great recognition - there will always be people willing to help out and
contribute.

Myself, I have learned a lot, met a lot of interesting people and found a
fantastic job thanks to the project. I also built more packages from source
that I have ever dreamt of!

I wish I could spend more time on the project after work... I blame kids
for not being able to :)

Thanks again Al,

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

Re: [oi-dev] Building OpenIndiana

[Andrzej Szeszo]

G B: There are some build instructions on the wiki. I also put some notes
together here https://gist.github.com/aszeszo/2855864 when building and
rebuilding upstream repositories as an experiment. Note that the repos
referenced in the gist were not synced with upstream in almost a year.
Build commands should apply to OI repos on hg.openindiana.org though.

Andrzej








On 8 May 2013 01:11, Alasdair Lumsden  wrote:

> Hi,
>
> Basically there is nobody left working on the project that I know of apart
> from Jon Tibble (Meths on irc), who doesn't seem to respond on the mailing
> lists much, and Milan Jurik who was working on a JDS update. Neither Jon
> nor Milan have opted to take on leadership status from what I know, so this
> whole project is a "ghost project" - there's a website, a wiki, a download
> page, and a package server, but there isn't really anyone here except a few
> caretakers who occasionally trim the hedges and mow the lawn but mostly
> keeps to themselves.
>
> There isn't really any single document describing how to "build" OI - it's
> not an easy task. Under Sun, OpenSolaris was built from a collection of
> consolidations, a consolidation being a logical grouping of software, and
> OI inherited this. For example there was:
>
> onnv-gate: Kernel + Core Userland. This is what illumos is today - they
> forked the last open release of onnv-gate, onnv_147.
>
> sfw-gate: Sun Freeware - collection of open source utilities. Uses GNU
> Makefiles for building. Like a poor implementation of FreeBSD ports/pkgsrc.
>
> userland-gate: A replacement for SFW, with a tidier better IPS-ized build
> system. Also uses GNU Makefiles. Similar to FreeBSD ports tree or pkgsrc.
> oi-build is a clone of userland-gate, and we wanted oi-build to take over
> from all the other consolidations.
>
> xnv-gate: The X.Org consolidation, maintained at Oracle by Alan
> Coopersmith.
>
> pkg-gate: The IPS software consolidation.
>
> vpanels: The visual panels thing.
>
> Caiman: The installer.
>
> JDS: The Java Desktop system, based on spec-files technology. Also known
> as the "gnome" consolidation as it's where gnome lives. Also contains
> Firefox/Thunderbird/Evolution/etc.
>
> g11n: The internationalisation consolidation with localisation
> text/strings for apps
>
> admin/sic_team/solaris_re/etc - Misc other stuff.
>
> You can see the various consolidation source repos here:
>
> https://hg.openindiana.org/
>
> Under Sun, each consolidation was managed by a whole team, many of which
> were in different geographical locations. As far as I know, JDS was done by
> Sun India, pkg-gate by staff in Ireland. Each consolidation uses different
> build systems, each with their own pros and cons, but all requiring quite a
> lot of domain specific knowledge, with very little documentation provided
> to get started.
>
> Every 2 weeks these consolidations would be delivered to the Solaris
> Release Engineering team, who would assemble things together to put out a
> release. Some of the consolidations produce IPS package repos, some of them
> produce bundles of SVR4 packages which have to be converted to IPS packages
> using the distro_import utility. Then everything has to be merged together,
> then distro-constructor would be run to spit out the installable ISO image.
>
> So you can see, we're talking about a major engineering effort for each
> release. Sun had loads of staff, so it wasn't an issue. OI however had a
> small number of volunteers, such as myself, Andrzej Szeszo, Albert Lee, Jon
> Tibble, etc. We put in an extraordinarily large amount of hours to figure
> out how it all worked, it took months and months of scratching our heads
> and hacking away to get stuff to build, and a big push to get the first OI
> release done, oi_147, and then the subsequent releases oi_148 and oi_151.
>
> I had a grand plan to try to unify all the separate consolidations into
> what I considered the "best" one, userland-gate, under the name oi-build. I
> didn't get very far. Nexenta wanted to ditch using the Debian userland in
> favour of something native, so asked to collaborate with us on oi-build, so
> it got renamed -illumos-userland. However politics, infighting and a
> general lack of communication/direction/sanity within Nexenta led to it
> being stillborn. People got frustrated, bored, and lost interest, including
> myself. Then I quit, and almost everyone else seems to be working on other
> things now.
>
> So we're left with a dead project, apart from the work Jon Tibble is doing
> to periodically update oi_151 with a new illumos-gate release, along with
> some package updates and fixes as he finds ti

[oi-dev] OI project reboot required

[Andrzej Szeszo]

Hi All

(Instead of replying to a message in one of the other threads I thought I
will create a new one.)

Just wanted to say that I don't see a future for the project in its current
form. There is simply too many packages and too much baggage for a handful
of people to look after.

I think the project needs a new vision and a reboot. If you have any ideas
for the project and can write scripts/makefiles to generate a distro/live
CDs/etc. - speak up! You don't have to be a leader if you don't want to :)

Regards,

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

Re: [oi-dev] OI project reboot required

[Andrzej Szeszo]

Hi Sašo

Thanks for your support!

Andrzej


On 9 May 2013 10:36, Sašo Kiselkov  wrote:

> On 05/09/2013 10:01 AM, Andrzej Szeszo wrote:
> > Hi All
> >
> > (Instead of replying to a message in one of the other threads I thought I
> > will create a new one.)
> >
> > Just wanted to say that I don't see a future for the project in its
> current
> > form. There is simply too many packages and too much baggage for a
> handful
> > of people to look after.
> >
> > I think the project needs a new vision and a reboot. If you have any
> ideas
> > for the project and can write scripts/makefiles to generate a distro/live
> > CDs/etc. - speak up! You don't have to be a leader if you don't want to
> :)
>
> I volunteer to maintain packages around the GNUstep project
> (http://gnustep.org/), mainly the GNUstep frameworks and associated
> libraries.
>
> Cheers,
> --
> Saso
>
> ___
> 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] OI project reboot required

[Andrzej Szeszo]

The process you have described sounds a lot like OI's original plan. It
didn't work out. There was too much baggage. No one was willing to spend
time learning it. It was just too ... ugly.

Individual gates provide some semi-automated ways of building things. I
don't know anyone who managed to automate them all though. No one was able
to provide equivalent of "make world" to build complete OI to date.

There is no doubt Martin Bochnig has a lot of expertise in putting
operating systems together. I got impression that he was heavily invested
in SVR4 based systems though. OI may not be an interesting project for him
as it will probably remain IPS based for the time being.

Andrzej


On 9 May 2013 11:53, Jim Klimov  wrote:

> On 2013-05-09 10:01, Andrzej Szeszo wrote:
>
>> Hi All
>>
>> (Instead of replying to a message in one of the other threads
>> I thought I will create a new one.)
>>
>> Just wanted to say that I don't see a future for the project in its
>> current form. There is simply too many packages and too much baggage for
>> a handful of people to look after.
>>
>> I think the project needs a new vision and a reboot. If you have any
>> ideas for the project and can write scripts/makefiles to generate a
>> distro/live CDs/etc. - speak up! You don't have to be a leader if you
>> don't want to :)
>>
>
>
> You're probably right. I would like to help, though have limited time
> lately, and without docs similar to "Building illumos" won't really
> know where to start beside the illumos-gate. I guess many potential
> and active contributors are in the same boat.
>
> I think it would be proper to maintain a page (hosted on OI wiki)
> with copies of notes, caveats and other informational snippets about
> building the OI distro components. We have many talented people who
> can turn that knowledge into more polished narrative text, scripts
> and makefiles, paragraph at a time - but too few people who know
> what should actually be done (the content to polish). After all, you
> know how many man-months were invested into untangling this know-how
> from sources, comments, ARCs and whatnot. Please share the result :)
>
> I might guess that Martin Bochnig, who made the SPARC port last year
> single-handedly (and SVR4 backport at the same time), might also be
> quite in the know of the intricacies for the build. Possibly, he is
> now the only single person that knows it all. His contribution of the
> distro building know-how would be just as invaluable as the resulting
> distribution itself ;)
>
> Recently, it was noted that there is no equivalent for a "make world"
> in OI. I do believe that after years of development, each consolidation
> in the distro has some equivalent command to build it, as well as a
> specified build environment (such as CBE, or just particular GCC/SS12u1,
> perl, Python and other tool-chain tool versions). The consolidations
> would likely be built each with its own "make sub-world", thus a global
> "make world" for OI would run a dozen make's for the sub-worlds...
> Right? :)
>
> The build environments could be made in zones, and provisioning of
> those can be easily scripted (I think I might help in that direction).
> The build could be executed by i.e. logging in from GZ into the zones
> (or somehow harnessing the dmake's distributed properties natively,
> or by automating with CI/Hudson and its ssh-login capabilities onto
> many hosts with pieces of the code puzzle), culminating with a call to
> the distro constructor. This is all a job for a master makefile to be
> called in the GZ, and waiting a few days for it to complete.
>
> Quite possibly, the "master-builder" automations (scripts to provision
> standardized build zones, compilation environments on top of them, and
> local package servers for resulting packages accumulated from those
> zones, etc.) - these scripts and makefiles would deserve a repository
> of their own, even if just a small one for starters. This way people
> would be able to install OI (or real iron or in a VM), fetch a script
> to provision build zones, download/update source codes, clone the
> per-bug workspace, etc. all in the same standardized and well-tested
> manner, and easily start helping the project move on in whatever way
> they can.
>
> //Jim Klimov
>
>
> __**_
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/**mailman/listinfo/oi-dev<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] OI project reboot required

[Andrzej Szeszo]

Hi David

Igor is doing great job with his CIBS stuff. Certainly worth consideration
for a project reboot.

I agree on the contribution front. I had similar experience with Vagrant.
It took probably less than 1h for my change to end up in the official repo.

Andrzej




On 9 May 2013 11:08, David Höppner <0xf...@gmail.com> wrote:

> I think Igor Pashev has done some valueable work with
> https://github.com/Nexenta/cibs
> https://github.com/ip1981/last-hope
>
> When I was core member of the Homebrew project we just used
> github pull requests.  Contributing should be simple and easy.
> If I found problems with a patch, I just fixed it in place.
>
> -- David
>
> On 9 May 2013 10:01, Andrzej Szeszo  wrote:
> > Hi All
> >
> > (Instead of replying to a message in one of the other threads I thought I
> > will create a new one.)
> >
> > Just wanted to say that I don't see a future for the project in its
> current
> > form. There is simply too many packages and too much baggage for a
> handful
> > of people to look after.
> >
> > I think the project needs a new vision and a reboot. If you have any
> ideas
> > for the project and can write scripts/makefiles to generate a distro/live
> > CDs/etc. - speak up! You don't have to be a leader if you don't want to
> :)
> >
> > Regards,
> >
> > Andrzej
> >
> >
> > ___
> > 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] OI project reboot required

[Andrzej Szeszo]

I agree with what Peter and Garrett wrote earlier. OI is lacking a clear
vision. It should be different than other illumos distros' as well to avoid
duplicating work unnecessarily.

I think, OI could be "illumos hacker distro", and:

- carry on providing GUI support, good enough for illumos hackers to use it
on their desktops/laptops
- it could potentially be based on vanilla illumos-gate; few OI specific
changes could be upstreamed or dropped
- existing OI users should be able to do pkg update to get the latest bits

Not radical or innovative at all. Different enough to what other distros
are doing though (no GUI, own illumos-gate forks).

I did a quick survey on IRC and looks like there is enough talented and
capable people who would be willing to help with the model described above.

Existing releng process and contribution process prevent anything from
happening though. I would like to help to change that.

Radical and innovative ideas are welcome as well. They could be worked on
in parallel as sub-projects.

What do you think about OI being "illumos hacker distro"?

Andrzej



On 10 May 2013 03:12, Nick Zivkovic  wrote:

> For what it's worth,  I only need Xorg, xpdf and xterm to take care of my
> graphics needs. Everything that doesn't involve coding happens on linux,
> mac and winxp.
>
> As long as a distro can support Xorg, it is viable for me. So whatever you
> guys do, please don't remove the basic graphics capability!
> On May 9, 2013 7:20 PM, "Garrett D'Amore" 
> wrote:
>
>>
>> On May 9, 2013, at 4:00 PM, Bob Friesenhahn 
>> wrote:
>>
>> > On Thu, 9 May 2013, Garrett D'Amore wrote:
>> >>
>> >> Upshot, *today* anyone who thinks there is a commercial future in
>> illumos on the desktop is probably smoking something.  There are a few
>> people who would be willing to pay for it, but it needs more than a few
>> dozen people willing to pay a couple hundred dollars (more often
>> substantially less) to make this a viable and interesting (economically)
>> venture.
>> >
>> > There is little "commercial future" in the desktop for Linux
>> distributions as well yet almost all of them have a graphical desktop.
>>
>> Admittedly true.  And yet, most of them *started* on the desktop.
>>  Linux's roots are in the desktop.  Most of those distros took off because
>> they had a groundswell of support from developer users who wanted it on the
>> desktop -- they didn't have servers, and options like VMware simply didn't
>> exist at the time.  I'd argue that this is largely an artifact of history.
>> I would be entirely *unsurprised* if distro vendors like RedHat and Oracle
>> simply *ditched* their desktop support at some point in the future -- its
>> clear to me at least that folks aren't running those distros on the desktop.
>>
>> In fact, I can't think of *anyone* who's paying for a desktop OS that
>> doesn't come from either Apple or Microsoft.
>>
>> > Availability of a graphical desktop is seen as a requirement for common
>> acceptance.
>>
>> Historically true, but I seriously doubt it now.  SmartOS is the counter
>> example from this community.  I think there are others.  For example,
>> OpenBSD was highly popular for a long time for its security emphasis, but I
>> don't know *anyone* who ran it on a desktop.
>>
>> The widespread availability of virtualization like VMware, VirtualBox,
>> and Parallels means that there is little need to take over the user's
>> desktop to provide a reasonable environment.  Most people these days
>> develop using SSH, etc.  The folks I know who use Linux would, apart from a
>> few extremists, not care whether the desktop ran Linux, FreeBSD, or
>> Solaris, as long as it Just Worked and provided a familiar UNIX-like
>> backend.  (I contend that these principles have lead strongly to the uptake
>> of MacOS in the developer community…. I use an Apple laptop for my own
>> environment, even though I wouldn't *dream* of using MacOS in a server
>> capacity.)  For me, Terminal.app and ssh is along with VMware gives me
>> everything I need for doing cool things with illumos on my desktop.  I
>> explicitly *disable* the graphical login on illumos. :-)
>>
>> >  Much/most of the graphical desktop development taking place for Linux
>> does not seem to be done by the companies which popularly peddle it (e.g.
>> Canonical has been more of a desktop packager except for its useless Unity).
>>
>> Only partly true (Qt is the counter example).  But yes, a lot of the
>> desktop development in Gnome and company is done by community members who
>> are passionate about this. And guess what -- almost all those guys are
>> Linux "bigots".  There's a huge trend in those spaces to adopt technologies
>> that are Linux-specific, to the point of near active hostility towards
>> other FOSS.  That creates a huge barrier for leveraging their efforts.  Do
>> we have the kind of volunteerism here to take up a duplicate effort?  And
>> why just duplicate?  If we have *that* kind of interest and volunteerism,
>> I'd

Re: [oi-dev] OI project reboot required

[Andrzej Szeszo]

Hi Alasdair

I would like to try setting up a repo on github, give trusted people direct
access and support pull requests from independent developers. And then have
jenkins publish packages incrementally to publicly accessible repository.
In theory, it should only take few minutes from a push to a published
package in a repo.

It is a variation on the process which was tried earlier. I think it might
work this time.

I did some prep work last night. Will try to have something usable by
others later tonight.

Cheers,

Andrzej




On 10 May 2013 14:04, Alasdair Lumsden  wrote:

> Andrzej,
>
> Your vision is pretty much the same one I had. The challenge is this:
>
> "Existing releng process and contribution process prevent anything from
> happening though. I would like to help to change that."
>
> How?
>
>
> On Fri, May 10, 2013 at 12:54 PM, Jim Klimov  wrote:
>
>> On 2013-05-10 02:19, Garrett D'Amore wrote:
>>
>>> There is little "commercial future" in the desktop for Linux
 distributions as well yet almost all of them have a graphical desktop.

>>>
>>> I would be entirely *unsurprised* if distro vendors like RedHat and
>>> Oracle simply *ditched* their desktop support at some point in the future
>>> -- its clear to me at least that folks aren't running those distros on the
>>> desktop.
>>>
>>
>> Well, Oracle does provide and promote SunRays, and while admittedly most
>> of their market targeting is about VDI and access to virtual
>> Windows desktops, there are many requests on the SRSS mailing list
>> about adding support for server-side Ubuntu as the SRSS terminal
>> server, because certain apps only exist for Linux and tunneling
>> of connections makes their graphics lag, and RHEL/OEL/Solaris
>> desktops are argued to be not so user-friendly (I have no opinion
>> on this, to me X11 is a means to display more characters on screen
>> than possible in a text mode).
>>
>> Not that Oracle seems to care to address that demand, at least
>> publicly - just recently they began supporting versions 6 of RHEL
>> and OEL as server-side Linuxes. But there is certain demand for
>> non-MS/Apple desktops, and one linked to commercial interest as
>> well. I am not sure if OI/illumos can ride that tide, though.
>> Maybe with some other terminal client technologies (ThinLinc,
>> Wyse, etc)?..
>>
>> //Jim
>>
>>
>>
>> __**_
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> http://openindiana.org/**mailman/listinfo/oi-dev
>>
>
>
>
> --
> Alasdair Lumsden
>
> http://www.everycity.co.uk
>
> EveryCity Managed Hosting
> Studio 18 Bluelion Place
> 237 Long Lane, London, SE1 4PU
>
> general: 020 7183 2800
> support: 020 7183 2801
> email: a...@everycity.co.uk
>
> Every City Limited
> Registered in England and Wales, No. 5689474 Registered Office: Roper
> Yard, Roper Road, Canterbury, CT2 7EX
>
> ___
> 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] OI project reboot required

[Andrzej Szeszo]

Hi All

Apologies for a delay. Some things are set up now.

New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a
clone of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from
Milan Jurik merged in. Run commands below to update your system. You can
ask Jon Tibble where the name of the repo came from :)

pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org
pk install -v pkg://package/pkg
pkg update -v

Latest Oracle userland hg repo was converted to git and uploaded to
https://github.com/OpenIndiana/oi-userland/. Most of the components were
masked and don't build by default. I have only unmasked few meta packages
to test if things build/publish correctly.

Quick Jenkins instance that automatically builds packages and publishes
them directly to http://pkg.openindiana.org/hipster/.

To start hacking, fork a repo on github, make your changes (unmask
packages, add new ones) and submit pull request. If you are an existing
contributor, give me a shout and I will give you direct access to the repo.

Please let me know if you have any questions.

Let's see if the process works out.

Kind regards,

Andrzej



On 11 May 2013 18:28, Andrzej Szeszo  wrote:

> Hi Alasdair
>
> I would like to try setting up a repo on github, give trusted people
> direct access and support pull requests from independent developers. And
> then have jenkins publish packages incrementally to publicly accessible
> repository. In theory, it should only take few minutes from a push to a
> published package in a repo.
>
> It is a variation on the process which was tried earlier. I think it might
> work this time.
>
> I did some prep work last night. Will try to have something usable by
> others later tonight.
>
> Cheers,
>
> Andrzej
>
>
>
>
> On 10 May 2013 14:04, Alasdair Lumsden  wrote:
>
>> Andrzej,
>>
>> Your vision is pretty much the same one I had. The challenge is this:
>>
>> "Existing releng process and contribution process prevent anything from
>> happening though. I would like to help to change that."
>>
>> How?
>>
>>
>> On Fri, May 10, 2013 at 12:54 PM, Jim Klimov  wrote:
>>
>>> On 2013-05-10 02:19, Garrett D'Amore wrote:
>>>
>>>> There is little "commercial future" in the desktop for Linux
>>>>> distributions as well yet almost all of them have a graphical desktop.
>>>>>
>>>>
>>>> I would be entirely *unsurprised* if distro vendors like RedHat and
>>>> Oracle simply *ditched* their desktop support at some point in the future
>>>> -- its clear to me at least that folks aren't running those distros on the
>>>> desktop.
>>>>
>>>
>>> Well, Oracle does provide and promote SunRays, and while admittedly most
>>> of their market targeting is about VDI and access to virtual
>>> Windows desktops, there are many requests on the SRSS mailing list
>>> about adding support for server-side Ubuntu as the SRSS terminal
>>> server, because certain apps only exist for Linux and tunneling
>>> of connections makes their graphics lag, and RHEL/OEL/Solaris
>>> desktops are argued to be not so user-friendly (I have no opinion
>>> on this, to me X11 is a means to display more characters on screen
>>> than possible in a text mode).
>>>
>>> Not that Oracle seems to care to address that demand, at least
>>> publicly - just recently they began supporting versions 6 of RHEL
>>> and OEL as server-side Linuxes. But there is certain demand for
>>> non-MS/Apple desktops, and one linked to commercial interest as
>>> well. I am not sure if OI/illumos can ride that tide, though.
>>> Maybe with some other terminal client technologies (ThinLinc,
>>> Wyse, etc)?..
>>>
>>> //Jim
>>>
>>>
>>>
>>> __**_
>>> oi-dev mailing list
>>> oi-dev@openindiana.org
>>> http://openindiana.org/**mailman/listinfo/oi-dev<http://openindiana.org/mailman/listinfo/oi-dev>
>>>
>>
>>
>>
>> --
>> Alasdair Lumsden
>>
>> http://www.everycity.co.uk
>>
>> EveryCity Managed Hosting
>> Studio 18 Bluelion Place
>> 237 Long Lane, London, SE1 4PU
>>
>> general: 020 7183 2800
>> support: 020 7183 2801
>> email: a...@everycity.co.uk
>>
>> Every City Limited
>> Registered in England and Wales, No. 5689474 Registered Office: Roper
>> Yard, Roper Road, Canterbury, CT2 7EX
>>
>> ___
>> 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] OI project reboot required

[Andrzej Szeszo]

Hi Piotr

I made some choices without consulting anyone but it allowed me to get
something set up in a short period of time.

oi_151a8 is based on sfw-gate, that's correct. Milan built JDS against
oi_151a8.
Because oi_151a8 and JDS bits were already available I thought it would be
a shame to not to include them in the repo I was preparing.

/experimental, oi-build, illumos-userland didn't really took off. I know
they exist but it would take time to figure out in what shape the binary
package repos are. I thought it would be a better idea to start fresh in
terms of binary packages. Build recipes however we should reuse. The github
repo currently does not produce anything else other than few meta-packages.
Build recipes from oi-build or illumos-userland can be added to the tree
and should just work. There is an option of enabling disabled Oracle
provided packages as well.

This time I wanted to keep things really simple. There is single publisher
now - 'openindiana.org' - but pointing at different repo. And single source
repo -  https://github.com/OpenIndiana/oi-userland. Any fixes or additions
should be made in the github repo.

In terms of fixes to the packages that came from SFW , I recommend using
equivalent package from one of the userland-style repos. The idea is to not
to have to compile SFW or run distro-importer ever again :)

Correct me if I am wrong, but illumos-userland is dead. I don't see a point
using it directly. Build recipes should be borrowed from it though :)

I have heard about libffi. Not sure what the problem is. It doesn't look
like it would be difficult to provide userland build recipe for it in case
we need an updated version.

Andrzej




On 12 May 2013 12:09, Piotr Jasiukajtis  wrote:

> Andrzej,
>
> oi_151a8 is still based on sfw-gate, wouldn't be better to resurrect
> /experimental which was based on illumos-userland?
>
> To me it was hard to manage different IPS versions along with the build
> environments/zones because some were based on /experimental while my main
> host was /dev.
> Another source of confusion are 3 different source repositories: sfw,
> oi-build and illumos-userland. Which one to use if I need a new package on
> my production systems? and no, I don't want to touch SFW anymore :)
>
> Maybe create another version based on illumos-userland in the /dev let say
> oi_152a1 or something?
>
>
> Btw, someone mentioned about some libffi issues on oi_151a8.
> I barely checked that and it seems pkg and python do work but I don't know
> what the issue was. Is that fixed?
>
> Thanks for doing that :)
>
> --
> Piotr Jasiukajtis
>
> On May 12, 2013, at 10:30 AM, Andrzej Szeszo  wrote:
>
> > Hi All
> >
> > Apologies for a delay. Some things are set up now.
> >
> > New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a
> clone of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from
> Milan Jurik merged in. Run commands below to update your system. You can
> ask Jon Tibble where the name of the repo came from :)
> >
> > pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org
> > pk install -v pkg://package/pkg
> > pkg update -v
> >
> > Latest Oracle userland hg repo was converted to git and uploaded to
> https://github.com/OpenIndiana/oi-userland/. Most of the components were
> masked and don't build by default. I have only unmasked few meta packages
> to test if things build/publish correctly.
> >
> > Quick Jenkins instance that automatically builds packages and publishes
> them directly to http://pkg.openindiana.org/hipster/.
> >
> > To start hacking, fork a repo on github, make your changes (unmask
> packages, add new ones) and submit pull request. If you are an existing
> contributor, give me a shout and I will give you direct access to the repo.
> >
> > Please let me know if you have any questions.
> >
> > Let's see if the process works out.
> >
> > Kind regards,
> >
> > Andrzej
> >
> >
> >
> > On 11 May 2013 18:28, Andrzej Szeszo  wrote:
> > Hi Alasdair
> >
> > I would like to try setting up a repo on github, give trusted people
> direct access and support pull requests from independent developers. And
> then have jenkins publish packages incrementally to publicly accessible
> repository. In theory, it should only take few minutes from a push to a
> published package in a repo.
> >
> > It is a variation on the process which was tried earlier. I think it
> might work this time.
> >
> > I did some prep work last night. Will try to have something usable by
> others later tonight.
> >
> > Cheers,
> >
> > Andrzej
> >
&

Re: [oi-dev] OI project reboot required

[Andrzej Szeszo]

pkg.depotd is misbehaving when you publish packages directly to it. I am
looking at it now.

Andrzej


On 12 May 2013 14:19, David Höppner <0xf...@gmail.com> wrote:

> I actually get a permissions error.
>
> $ sudo pkg set-publisher -O http://pkg.openindiana.org/hipster/
> openindiana.org
> pkg set-publisher: Could not refresh the catalog for openindiana.org
>
> http protocol error: code: 403 reason: Forbidden
> URL: '
> http://pkg.openindiana.org/hipster/openindiana.org/catalog/1/catalog.attrs
> '.
>
>
> I noticed Oracle upstream moves aggressively to amd64 only;
> installing amd64 just in bin not in bin/$(MACH64).
>
> -- David
>
> On 12 May 2013 10:30, Andrzej Szeszo  wrote:
> > Hi All
> >
> > Apologies for a delay. Some things are set up now.
> >
> > New IPS repository is up: http://pkg.openindiana.org/hipster/. It is a
> clone
> > of the /dev repo + oi_151a8 bits from Jon Tibble and JDS bits from Milan
> > Jurik merged in. Run commands below to update your system. You can ask
> Jon
> > Tibble where the name of the repo came from :)
> >
> > pkg set-publisher -O http://pkg.openindiana.org/hipster/ openindiana.org
> > pk install -v pkg://package/pkg
> > pkg update -v
> >
> > Latest Oracle userland hg repo was converted to git and uploaded to
> > https://github.com/OpenIndiana/oi-userland/. Most of the components were
> > masked and don't build by default. I have only unmasked few meta
> packages to
> > test if things build/publish correctly.
> >
> > Quick Jenkins instance that automatically builds packages and publishes
> them
> > directly to http://pkg.openindiana.org/hipster/.
> >
> > To start hacking, fork a repo on github, make your changes (unmask
> packages,
> > add new ones) and submit pull request. If you are an existing
> contributor,
> > give me a shout and I will give you direct access to the repo.
> >
> > Please let me know if you have any questions.
> >
> > Let's see if the process works out.
> >
> > Kind regards,
> >
> > Andrzej
> >
> >
> >
> > On 11 May 2013 18:28, Andrzej Szeszo  wrote:
> >>
> >> Hi Alasdair
> >>
> >> I would like to try setting up a repo on github, give trusted people
> >> direct access and support pull requests from independent developers. And
> >> then have jenkins publish packages incrementally to publicly accessible
> >> repository. In theory, it should only take few minutes from a push to a
> >> published package in a repo.
> >>
> >> It is a variation on the process which was tried earlier. I think it
> might
> >> work this time.
> >>
> >> I did some prep work last night. Will try to have something usable by
> >> others later tonight.
> >>
> >> Cheers,
> >>
> >> Andrzej
> >>
> >>
> >>
> >>
> >> On 10 May 2013 14:04, Alasdair Lumsden  wrote:
> >>>
> >>> Andrzej,
> >>>
> >>> Your vision is pretty much the same one I had. The challenge is this:
> >>>
> >>> "Existing releng process and contribution process prevent anything from
> >>> happening though. I would like to help to change that."
> >>>
> >>> How?
> >>>
> >>>
> >>> On Fri, May 10, 2013 at 12:54 PM, Jim Klimov  wrote:
> >>>>
> >>>> On 2013-05-10 02:19, Garrett D'Amore wrote:
> >>>>>>
> >>>>>> There is little "commercial future" in the desktop for Linux
> >>>>>> distributions as well yet almost all of them have a graphical
> desktop.
> >>>>>
> >>>>>
> >>>>> I would be entirely *unsurprised* if distro vendors like RedHat and
> >>>>> Oracle simply *ditched* their desktop support at some point in the
> future --
> >>>>> its clear to me at least that folks aren't running those distros on
> the
> >>>>> desktop.
> >>>>
> >>>>
> >>>> Well, Oracle does provide and promote SunRays, and while admittedly
> most
> >>>> of their market targeting is about VDI and access to virtual
> >>>> Windows desktops, there are many requests on the SRSS mailing list
> >>>> about adding support for server-side Ubuntu as the SRSS terminal
> >>>> server, because certain apps only exist for Linux and tunneling
> >>>> of con

[oi-dev] OI 'hipster' reboot effort

[Andrzej Szeszo]

Hi All

Seeing that the project is slowing down a bit, I have decided that I
will try to help it get some momentum back.

Firstly, if you rely on stable OI releases, Jon Tibble will carry on
producing traditional releases and they will be made available in the
/dev repo and as installable ISO/USB images. OI 151a8 should be out
real soon now.

/dev releases follow traditional Sun/Oracle releng process, which is
very time consuming. Mainly for that reason it may take a very long
time before any build system update will be reflected in the package
repository.

OI 'hipster' is trying to change the process by switching to a rolling
release model.

There is single top-level build repo on Github:
https://github.com/OpenIndiana/oi-userland. If you want to change
something or add new packages - simply send a pull request.

Changes to the build repo are automatically picked up by Jenkins
instance, packages are built and then published to the
http://pkg.openindiana.org/hipster repo. It is all set up and working
now.

http://pkg.openindiana.org/hipster repo currently consists of /dev
contents + JT's /dev-test OI 151a8 bits + Milan Jurik's JDS work +
Jenkins built packages.

The plan is to improve what's out there incrementally. Eventually it
should be possible to build complete OS from the Github repo.

To use /hipster repo, install OI 151a7 and run (as root):

pkg set-publisher -O http://pkg.openindiana.org/hipster openindiana.org
pkg update -v

Few people started submitting changes already. Thanks for that! If you
have something to be added or changed in the repo, simply send us pull
request.

Couple useful links:
Jenkins dashboard: http://hipster.openindiana.org:8080/
Component build logs: http://hipster.openindiana.org/i386/logs/

Andrzej

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

Re: [oi-dev] OI 'hipster' reboot effort

[Andrzej Szeszo]

Hi Alexander

system/prerequisite/gnu package needs re-doing. It is mostly empty
package. I am going to do it later tonight.

Andrzej


On 20 May 2013 19:29, Alexander Pyhalov  wrote:
> Good evening.
>
> I've just tried to update fresh install of oi-151a7 using hipster
> repository.
> #  pkg publisher
> PUBLISHER TYPE STATUS   URI
> openindiana.org   origin   online
> http://pkg.openindiana.org/hipster/
>
> #  pkg update --be-name hipster-2013-05-20
> Creating Plan /
> pkg update: The following packages deliver conflicting action types to
> usr/share/info/dir:
>
> link:
> pkg://openindiana.org/text/texinfo@4.7,5.11-0.151.1.8.1:20130518T221401Z
> file:
> pkg://openindiana.org/system/prerequisite/gnu@0.5.11,5.11-0.151.1.8:20130305T141739Z
>
>
> After uninstalling text/texinfo I could update the system. But what is a
> correct way to resolve this conflict?
>
> ---
> System Administrator of Southern Federal University Computer Center
>
>
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

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

Re: [oi-dev] OI 'hipster' reboot effort

[Andrzej Szeszo]

pkg update should work now.

Andrzej

On 20 May 2013 20:26, Andrzej Szeszo  wrote:
> Hi Alexander
>
> system/prerequisite/gnu package needs re-doing. It is mostly empty
> package. I am going to do it later tonight.
>
> Andrzej
>
>
> On 20 May 2013 19:29, Alexander Pyhalov  wrote:
>> Good evening.
>>
>> I've just tried to update fresh install of oi-151a7 using hipster
>> repository.
>> #  pkg publisher
>> PUBLISHER TYPE STATUS   URI
>> openindiana.org   origin   online
>> http://pkg.openindiana.org/hipster/
>>
>> #  pkg update --be-name hipster-2013-05-20
>> Creating Plan /
>> pkg update: The following packages deliver conflicting action types to
>> usr/share/info/dir:
>>
>> link:
>> pkg://openindiana.org/text/texinfo@4.7,5.11-0.151.1.8.1:20130518T221401Z
>> file:
>> pkg://openindiana.org/system/prerequisite/gnu@0.5.11,5.11-0.151.1.8:20130305T141739Z
>>
>>
>> After uninstalling text/texinfo I could update the system. But what is a
>> correct way to resolve this conflict?
>>
>> ---
>> System Administrator of Southern Federal University Computer Center
>>
>>
>>
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> http://openindiana.org/mailman/listinfo/oi-dev

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

Re: [oi-dev] OI 'hipster' reboot effort

[Andrzej Szeszo]

Hi Gary

Yes, there are more */locale/* packages conflicting with newer JDS.
For now the workaround is to uninstall conflicting */locale/*
packages. Same with the
pkg://opensolaris.org/developer/gcc/gcc-libgcc@4.3.3,5.11-0.133:20100306T002102Z
package.

Ideally someone should publish obsoleting/renaming packages. I didn't
have time to do it myself yet.

We are accepting pull requests on Github in case someone would like to
have a look at fixing conflicting packages ;)

There are sample manifests available here:

https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/meta-packages/history

Ideally pkg install 'pkg:/*' should work but we are not there yet.

Andrzej


On 21 May 2013 20:00, Gary Gendel  wrote:
> I tried to update to the hipster repository but I'm faced with a number of
> conflicts.  The all seem pretty much innocuous as they are ".mo" files like:
>
> pkg update: The following packages all deliver file actions to
> usr/share/locale/el/LC_MESSAGES/avahi.mo:
>
> pkg://openindiana.org/system/network/avahi@0.6.30,5.11-0.151.1.8:20130407T025203Z
> pkg://openindiana.org/gnome/locale/extra@0.5.11,5.11-0.151.1.8:20130305T135615Z
>
> But there are some ".kbd" files too:
>
> The following packages all deliver file actions to
> usr/share/gok/sr@latin/text-operations.kbd:
>
> pkg://openindiana.org/gnome/locale/extra@0.5.11,5.11-0.151.1.8:20130305T135615Z
> pkg://openindiana.org/gnome/accessibility/gok@2.30.0,5.11-0.151.1.8:20130407T081835Z
>
> Last is the 32 and 64 bit gcc library:
>
> The following packages all deliver file actions to
> usr/lib/amd64/libgcc_s.so.1:
>
> pkg://openindiana.org/system/library/gcc-4-runtime@4.7.3,5.11-0.151.1.8.1:20130518T182046Z
> pkg://opensolaris.org/developer/gcc/gcc-libgcc@4.3.3,5.11-0.133:20100306T002102Z
>
> This sounds like it should be an easy thing to fix, but I'm not sure how.
> Advice?
>
> Regards,
> Gary
>
>
>
> ___
> 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] OI 'hipster' reboot effort

[Andrzej Szeszo]

Hi Gary

Sometimes stuff in /hipster repo will be broken. NVIDIA driver should
be fixed in the repo now (it installs, I have not tested the driver
itself just yet).

Andrzej

On 22 May 2013 17:43, Gary Gendel  wrote:
> Thanks for all the suggestions.  I'm left with one more conflict, the group
> id of the /usr/share tree.
>
> pkg update: The requested change to the system attempts to install multiple
> actions
> for dir 'usr/share' with conflicting attributes:
>
> 1 package delivers 'dir group=bin mode=0755 owner=root path=usr/share':
> pkg://openindiana.org/driver/graphics/nvidia@0.319.17,5.11-0.151.1.8.1:20130522T142429Z
> 490 packages deliver 'dir group=sys mode=0755 owner=root
> path=usr/share', including:
> pkg://extra/system/font/truetype/ttf-fonts-core@1.1,5.11-0.111:20100126T163849Z
> pkg://openindiana.org/SUNWcs@0.5.11,5.11-0.151.1.8:20130305T145134Z
> pkg://openindiana.org/archiver/unrar@4.2.4,5.11-0.151.1.8:20130305T134533Z
> pkg://openindiana.org/benchmark/x11perf@1.5.1,5.11-0.151.1.8:20130305T143729Z
> pkg://openindiana.org/codec/flac@1.2.1,5.11-0.151.1.8:20130407T012121Z
>
>
> These packages may not be installed together.  Any non-conflicting set may
> be, or the packages must be corrected before they can be installed.
>
> I can't remove the nvidia driver on a live image.  I don't use it anyway
> because this has a Trident card.  Should I bring up a liveCD and remove it
> that way or is there some way to fix this when upgrading?
>
>
> Regards,
> Gary
>
>
> ___
> 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] OI 'hipster' reboot effort

[Andrzej Szeszo]

319.17 NVIDIA driver appears to be working now.

http://linux01.everycity.co.uk/~aszeszo/skitched-20130523-000758.png

Andrzej


On 22 May 2013 23:08, Andrzej Szeszo  wrote:
> Hi Gary
>
> Sometimes stuff in /hipster repo will be broken. NVIDIA driver should
> be fixed in the repo now (it installs, I have not tested the driver
> itself just yet).
>
> Andrzej
>
> On 22 May 2013 17:43, Gary Gendel  wrote:
>> Thanks for all the suggestions.  I'm left with one more conflict, the group
>> id of the /usr/share tree.
>>
>> pkg update: The requested change to the system attempts to install multiple
>> actions
>> for dir 'usr/share' with conflicting attributes:
>>
>> 1 package delivers 'dir group=bin mode=0755 owner=root path=usr/share':
>> pkg://openindiana.org/driver/graphics/nvidia@0.319.17,5.11-0.151.1.8.1:20130522T142429Z
>> 490 packages deliver 'dir group=sys mode=0755 owner=root
>> path=usr/share', including:
>> pkg://extra/system/font/truetype/ttf-fonts-core@1.1,5.11-0.111:20100126T163849Z
>> pkg://openindiana.org/SUNWcs@0.5.11,5.11-0.151.1.8:20130305T145134Z
>> pkg://openindiana.org/archiver/unrar@4.2.4,5.11-0.151.1.8:20130305T134533Z
>> pkg://openindiana.org/benchmark/x11perf@1.5.1,5.11-0.151.1.8:20130305T143729Z
>> pkg://openindiana.org/codec/flac@1.2.1,5.11-0.151.1.8:20130407T012121Z
>>
>>
>> These packages may not be installed together.  Any non-conflicting set may
>> be, or the packages must be corrected before they can be installed.
>>
>> I can't remove the nvidia driver on a live image.  I don't use it anyway
>> because this has a Trident card.  Should I bring up a liveCD and remove it
>> that way or is there some way to fix this when upgrading?
>>
>>
>> Regards,
>> Gary
>>
>>
>> ___
>> 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] strange make error

[Andrzej Szeszo]

Hi Alexander

Packages listed in components/components.ignore are disabled as no one
has tried building them yet. "gmake publish" in top-level components
directory skips them. php-5_3 is one of such packages.

Quick test here shows that at least one of the modules expects Studio
compiler suite to be present on the build system.

I consider it as a bug. We should use GCC whenever possible.

Any volunteers to fix PHP? :)

Andrzej

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

Re: [oi-dev] aspell component

[Andrzej Szeszo]

There are two ways to solve this issue if I am not mistaken.

First and easy one is to deliver fixed system header as part of GCC's
fixed-includes. Initial GCC 4.7 package did not deliver any fixed
headers

Another option is to fix the relevant headers in illumos itself.

Andrzej

On 25 May 2013 22:23, Alexander Pyhalov  wrote:
> Hello, all.
>
> I've made preliminary port of aspell component for oi-hipster repository. It
> is slightly modified version from ec-userland and is
> accessible here:
> https://github.com/pyhalov/oi-userland/tree/aspell/components/aspell .
>
> However, there is a problem: https://www.illumos.org/issues/3787
>
> To build aspell with GCC >= 4.6 you should modify your system headers.
>
> The following lines should be changed (add _GNUG exceptions):
> /usr/include/stdlib.h:43:#if __cplusplus >= 199711L && !defined(_GNUG__)
> /usr/include/iso/stdlib_iso.h:62:#if __cplusplus >= 199711L &&
> !defined(__GNUG__)
> /usr/include/iso/stdlib_iso.h:76:#if !defined(_SIZE_T) || ( __cplusplus >=
> 199711L && !defined(__GNUG__))
> /usr/include/iso/stdlib_iso.h:131:#if __cplusplus >= 199711L &&
> !defined(__GNUG__)
> /usr/include/iso/stdlib_iso.h:151:#if __cplusplus >= 199711L &&
> !defined(__GNUG__)
> /usr/include/iso/stdlib_iso.h:168:#if __cplusplus >= 199711L &&
> !defined(__GNUG__)
> /usr/include/iso/stdlib_iso.h:208:#if __cplusplus >= 199711L &&
> !defined(__GNUG__)
>
> it is related to the fix of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
> introduced in GCC 4.6
> In brief, earlier G++ reported __cplusplus to be 1. Now it is not always
> true. This corrupted logic in
> Solaris libraries headers. So, I don't know if this packet should be merged
> in oi-hipster and what is the best way to resolve this.
>
> --
> System Administrator of Southern Federal University Computer Center
>
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

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

Re: [oi-dev] error trying to compile gcc47-libgmp

[Andrzej Szeszo]

Strange that the build is failing for you. I am pretty sure I built
and re-build gcc4.7 multiple times and it was all fine.

I have borrowed build method from OmniOS. The evil chmod is required
to make gcc use .eh_frame based unwinder which makes C++ exceptions to
actually work without any workarounds. chmod is evil, yes.

https://github.com/omniti-labs/omnios-build/blob/master/build/gcc47/build.sh#L70

Andrzej

On 31 May 2013 20:37, Alexander Pyhalov  wrote:
> On 05/31/2013 23:31, Alexander Pyhalov wrote:
>>
>> You appear to have set $CFLAGS, perhaps you also need to tell GMP the
>> intended ABI, see "ABI and ISA" in the manual.
>> gmake: ***
>>
>> [/export/home/build/srcs/oi-userland/components/gcc47-libgmp/build/i86/.configured]
>> Error 1
>
>
> One more error:
> pfexec chmod 444 /usr/gnu/i386-pc-solaris2.11/bin/ld
> chmod: WARNING: can't change /usr/gnu/i386-pc-solaris2.11/bin/ld
> gmake: ***
> [/export/home/build/srcs/oi-userland/components/gcc47/build/i86/.configured]
> Error 1
>
> It seems that GCC building intentionally affects the build system...
>
>
> --
> 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] fix-includes for g++

[Andrzej Szeszo]

My cheeky plan was to get someone to "fix" the headers in illumos itself.

Alternative is to ignore the issue and include the fixed-includes
contents in the gcc package.

Alexander, feel free to add "fixed-includes" to the gcc package. My
initial gcc package is getting rid of the directory in the Makefile
altogether.

We can look at fixing illumos headers at later time.

Andrzej

On 3 June 2013 15:56, Alexander Pyhalov  wrote:
> On 06/03/2013 17:46, Alexander Pyhalov wrote:
>>
>> Hello, everyone...
>> Maybe I'm wrong, but, for example, OpenCSW gcc 4.8 package contains a
>> big set of fixed includes. Why doesn't our g++ 4.7 package include any?
>
>
> Compare, for example,
> http://pkg.omniti.com/omnios/release/manifest/0/developer%2Fgcc47%404.7.2%2C5.11-0.151006%3A20130429T221114Z
> and
> http://pkg.openindiana.org/hipster/manifest/0/developer%2Fgcc-47%404.7.3%2C5.11-0.151.1.8.1%3A20130518T182047Z
> .
>
>
> --
> 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] OI 'hipster' reboot effort

[Andrzej Szeszo]

You probably have package dependent on SUNWperl584core installed on
your system. Sun Studio perhaps?

setuptools-26 issue is something I have not seen yet...

Andrzej

On 4 June 2013 11:38, Udo Grabowski (IMK)  wrote:
> On 28/05/2013 23:18, Udo Grabowski (IMK) wrote:
>>
>> On 28/05/2013 15:32, Udo Grabowski (IMK) wrote:
>>>
>>> On 24/05/2013 00:57, Andrzej Szeszo wrote:
>>>>
>>>> Hi Udo
>>>>
>>>> I was aware of the conflicts. I have just pushed some obsoleting
>>>> packages to the git repo and they will appear in the package repo in
>>>> ~5 minutes.
>>>>
>>>> They should take number of non-installable packages down to 8:
>>>>
>>> 
>>>
>>> Not quite there yet (but close),
>
>
> Minor nits: After the last update a few days go, perl-584 and
> setuptools-26 (python-2.6) are still shown as updates, but do
> not so (probably because of 'Latest version not available
> from this publisher', and renamed perl-584 package):
>
> packagemanager update via version information panel
> Error:
> No solution was found to satisfy constraints
>
> maintained incorporations:
>
>
> pkg://openindiana.org/consolidation/gfx/gfx-incorporation@0.5.11,5.11-0.151.1.8:20130305T142155Z
>
> pkg://openindiana.org/consolidation/man/man-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> pkg://openindiana.org/consolidation/admin/admin-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> pkg://openindiana.org/consolidation/SunVTS/SunVTS-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> pkg://openindiana.org/consolidation/ub_javavm/ub_javavm-incorporation@0.5.11,5.11-0.151.1.8:20130305T143751Z
>
> pkg://openindiana.org/consolidation/solaris_re/solaris_re-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> pkg://openindiana.org/consolidation/cacao/cacao-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> pkg://openindiana.org/consolidation/jdmk/jdmk-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> pkg://openindiana.org/consolidation/dbtg/dbtg-incorporation@0.5.11,5.11-0.151.1.8:20130305T143739Z
>
> pkg://openindiana.org/consolidation/ips/ips-incorporation@0.5.11,5.11-0.151.1.8:20130305T143741Z
>
> pkg://openindiana.org/text/groff/groff-core@1.21,5.11-0.151.1.8:20130407T134404Z
>
> pkg://openindiana.org/consolidation/cde/cde-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> pkg://openindiana.org/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151.1.8:20130305T143746Z
>
> pkg://openindiana.org/consolidation/vpanels/vpanels-incorporation@0.5.11,5.11-0.151.1.8:20130305T143753Z
>
> pkg://openindiana.org/consolidation/l10n/l10n-incorporation@0.5.11,5.11-0.151.1.8:20130305T143742Z
>
> pkg://openindiana.org/consolidation/X/X-incorporation@0.5.11,5.11-0.151.1.8:20130305T143755Z
>
> pkg://openindiana.org/consolidation/sic_team/sic_team-incorporation@0.5.11,5.11-0.151.1.8:20130305T143750Z
>
> pkg://openindiana.org/consolidation/sunpro/sunpro-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> pkg://openindiana.org/consolidation/cns/cns-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> pkg://openindiana.org/consolidation/nspg/nspg-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> pkg://openindiana.org/consolidation/install/install-incorporation@0.5.11,5.11-0.151.1.8:20130305T143740Z
>
> pkg://openindiana.org/consolidation/hcts/hcts-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> pkg://openindiana.org/consolidation/xvm/xvm-incorporation@0.5.11,5.11-0.151.1.8:20130305T142156Z
>
> Plan Creation: Errors in installed packages due to proposed changes:
>
>   No suitable version of installed package
> pkg://openindiana.org/SUNWperl584core@5.8.4,5.11-0.133:20100914T033713Z
> found
> Reject:
> pkg://openindiana.org/SUNWperl584core@5.8.4,5.11-0.133:20100914T033713Z
> Reason:  All acceptable versions of 'require' dependency on
> pkg:/runtime/perl-584@5.8.4,5.11-0.133 are obsolete
>   No suitable version of installed package
> pkg://opensolaris.org/developer/sunstudio12u1@12.1.1,5.11-0.111:20100306T002245Z
> found
> Reject:
> pkg://opensolaris.org/developer/sunstudio12u1@12.1.1,5.11-0.111:20100306T002245Z
> Reason:  All versions matching 'require' dependency
> pkg:/SUNWperl584core@5.8.4,5.11-0.111 are rejected
>   Reject:
> pkg://openindiana.org/SUNWperl584core@5.8.4,5.11-0.133:20100914T033713Z
>   Reason:  All acceptable versions of 'require' dependency on
> pkg:/runtime/perl-584@5.8.4,5.11-0.133 are obsolete
>   Reject:
> pkg://opensolaris.org/SUNWperl584core@5.8.4,5.11-0.111:20090331T085645Z
>
>

Re: [oi-dev] g++ 4.7 headers issue

[Andrzej Szeszo]

Hi Alexander

Thanks for you persistence on this!

Andrzej

On 4 June 2013 11:41, Alexander Pyhalov  wrote:
>> Now I'm running G++ tests once more time...
>
> So, that's results:
>
> I've successfully built several C++ components with patched header (without
> patches for math headers).
>
> G++ testsuite result:
>
>
> === g++ Summary ===
>
> # of expected passes45424
> # of unexpected failures4
>
> # of expected failures  286
> # of unresolved testcases   2
>
> # of unsupported tests  453
> /usr/gcc/4.7/bin/c++  version 4.7.3 (GCC)
>
>
> 2 of 4 failures and 2 unresolved testcases were related to Sun ld (tests
> expect ld to understand --gc-sections option, about which it doesn't know).
>
> Other two failures are more strange:
> FAIL: c-c++-common/tm/malloc.c -std=gnu++98  scan-tree-dump-times tmmark "
> std::malloc .666" 1
> FAIL: c-c++-common/tm/malloc.c -std=gnu++11  scan-tree-dump-times tmmark "
> std::malloc .666" 1
>
> It seems they are related with namespace definition in stdlib.h header. Need
> to experiment with it some more time.
>
> --
> 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] runtime linker and non-standard libraries location

[Andrzej Szeszo]

I think I would suggest using -L/usr/gnu/lib and -R/usr/gnu/lib for
now. If we update ncurses package we will likely provide compatibility
links so your aspell package will carry on working.

Andrzej

On 6 June 2013 14:22, Alexander Pyhalov  wrote:
> Hello.
> I'm working on aspell port and have the following question about shared
> libraries. In current library/ncurses the library is located in /usr/gnu/lib
> or /usr/gnu/lib/amd64.
> I can path -L /usr/gnu/lib/amd64 or -L /usr/gnu/lib option to ld while
> compiling objects. But what to do with a run-time linker? Should I patch the
> package to use -rpath linker flag or just assume that we have new ncurses?
>
> Current ncurses component from Oracle provides neccessary links in /usr/lib
> and /usr/lib/amd64.
> --
> 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] runtime linker and non-standard libraries location

[Andrzej Szeszo]

Long-term, moving ncurses to /usr/lib{,amd64} is a good idea. The libs
in the current ncurses package live in /usr/gnu/lib though. So to use
it -R wil be required.

Andrzej

On 6 June 2013 20:52, Igor Kozhukhov  wrote:
> you can move nurses libs to /usr/lib|/usr/lib/64 - and use it
>
> i have move it on DilOS a long time ago - works well.
>
> no need to provide additional rules like:
> LDFLAGS += -L -R
>
> also i have moved headers to standard location
>
> --
> Best regards,
> Igor Kozhukhov
>
>
>
>
> On Jun 6, 2013, at 10:41 PM, Andrzej Szeszo wrote:
>
>> I think I would suggest using -L/usr/gnu/lib and -R/usr/gnu/lib for
>> now. If we update ncurses package we will likely provide compatibility
>> links so your aspell package will carry on working.
>>
>> Andrzej
>>
>> On 6 June 2013 14:22, Alexander Pyhalov  wrote:
>>> Hello.
>>> I'm working on aspell port and have the following question about shared
>>> libraries. In current library/ncurses the library is located in /usr/gnu/lib
>>> or /usr/gnu/lib/amd64.
>>> I can path -L /usr/gnu/lib/amd64 or -L /usr/gnu/lib option to ld while
>>> compiling objects. But what to do with a run-time linker? Should I patch the
>>> package to use -rpath linker flag or just assume that we have new ncurses?
>>>
>>> Current ncurses component from Oracle provides neccessary links in /usr/lib
>>> and /usr/lib/amd64.
>>> --
>>> 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
>
>
> ___
> 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] feature.h and __XOPEN_SOURCE_EXTENDED

[Andrzej Szeszo]

Alexander, thanks again for looking at the headers issue.

Since the changes you are proposing are touching files from
illumos-gate, would you be able to ask about the headers on illumos
developer list?

Only some of the illumos developer list regulars look here.

Cheers,

Andrzej

On 6 June 2013 11:15, 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
>
> --
> 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] hipster a8: ILOM remote console broken

[Andrzej Szeszo]

Hi Udo

What kind of ILOM are you connecting to? Perhaps I could try
replicating your problem over here by connecting to our Sun gear.

Cheers,

Andrzej


On 7 June 2013 17:15, Udo Grabowski (IMK)  wrote:
> Found out that launching the 'Remote Console' (javaws application)
> no longer works in hipster (works in a7):
>
> The jnlp file started with javaws is:
> 
> 
>
> https://imksuns-sp42:443/";>
>  
> JavaRConsole
> Sun Microsystems
> JavaRConsole Console Redirection
> Application
> JavaRConsole Console Redirection
> Application
> 
> JavaRConsole enables a user to view the video display of an
> ILOM computer equipped with a service processor. It also enables
> the user to redirect the local keyboard, mouse, CD-ROM and
> floppy drives to
> the remote computer to allow for complete control over the
> remote machine.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 16
> imksuns-sp42
> root-sp-1
> fTXRpdSkEUWAXNK
>
> 
> 
> 
> and produces this exception:
> 
> java.io.IOException: JNLP Jar download failure.
> at
> com.sun.javaws.LaunchDownload.validateResults(LaunchDownload.java:1241)
> at
> com.sun.javaws.LaunchDownload.downloadJarFiles(LaunchDownload.java:1213)
> at
> com.sun.javaws.LaunchDownload.downloadEagerorAll(LaunchDownload.java:920)
> at com.sun.javaws.Launcher.downloadResources(Launcher.java:1617)
> at com.sun.javaws.Launcher.prepareResources(Launcher.java:1013)
> at com.sun.javaws.Launcher.prepareAllResources(Launcher.java:621)
> at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:327)
> at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:199)
> at com.sun.javaws.Launcher.launch(Launcher.java:116)
> at com.sun.javaws.Main.launchApp(Main.java:416)
> at com.sun.javaws.Main.continueInSecureThread(Main.java:248)
> at com.sun.javaws.Main$1.run(Main.java:110)
> at java.lang.Thread.run(Thread.java:722)
> 
> I copied all certs from a7 /etc/cert to a8, as there are some SUN
> certs which maz come into play here. Java itself was not changed,
>
>
> cryptoadm list looks like a7:
>
> User-level providers:
> Provider: /usr/lib/security/$ISA/pkcs11_kernel.so
> Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so
> Provider: /usr/lib/security/$ISA/pkcs11_tpm.so
>
> Kernel software providers:
> des
> aes
> arcfour
> blowfish
> ecc
> sha1
> sha2
> md4
> md5
> rsa
> swrand
> 
>
> certutil -L:
> certutil: function failed: The certificate/key database is in an old,
> unsupported format.
> 
> The wrapper shared libs in solarisx86.jar link to existing libs:
>
> ldd /tmp/libjavacdromwrapper.so
> libstdc++.so.6 =>/usr/sfw/lib/libstdc++.so.6
> libm.so.2 => /lib/libm.so.2
> libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1
> libc.so.1 => /lib/libc.so.1
>
> What changed to break this ? Do I have to reimport the old
> certs into some database to reenable the RConsole ?
> --
> Dr.Udo GrabowskiInst.f.Meteorology a.Climate Research IMK-ASF-SAT
> www.imk-asf.kit.edu/english/sat.php
> KIT - Karlsruhe Institute of Technologyhttp://www.kit.edu
> Postfach 3640,76021 Karlsruhe,Germany  T:(+49)721 608-26026 F:-926026
>
>
> ___
> 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] OI hipster status

[Andrzej Szeszo]

Hi All

Just a quick update.

In the past weeks David Höppner and Alexander Pyhalov committed a
number changes to the oi-userland repo. Their enabled or updated
packages almost immediately became available in the
pkg.openindiana.org/hipster package repository. Thanks for doing it
guys!

Alexander is patiently working on integrating g++ related illumos
header changes to the illumos-gate itself which is awesome.

Last week I spent some time on repackaging latest redistributable Sun
Studio from the legacy OpenSolaris repo and getting it published to
the /hipster repo. lint and dmake from it should be sufficient for
building illumos-gate with patched gcc 4.4.4. Next item on my todo
list is creating illumos-gate component. Idea is to provide nightly or
even continuous updates of the ON bits directly in the /hipster repo.
At least until someone kills IPS manifests upstream :)

https://github.com/OpenIndiana/oi-userland is accepting pull requests
by the way. Don't be shy if you would like to update something or add
new packages.

Cheers,

Andrzej

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

Re: [oi-dev] Strange libgmp effect

[Andrzej Szeszo]

Hi All

I am probably guilty as I have delivered .so symlinks in
/usr/gcc/4.7/lib pointing at the gcc 4.7 private copies of libgmp,
libmpc and libmpfr.

They are only needed when building gcc itself. One potential
workaround would be to stop delivering them and create required
symlinks temporarily somewhere in gcc's build directtory.

Alexander, can you confirm your program compiles and runs ok after
removing /usr/gcc/4.7/lib/libgmp.so symlink?

Cheers,

Andrzej

On 19 June 2013 06:39, Michael Schuster  wrote:
> have you looked at compile-time vs run-time path setting for ld (eg
> LD_LIBRARY_PATH, etc - I'm a little rusty in this respect, so please look in
> the man-page)?
>
> HTH
> Michael
>
>
> On Tue, Jun 18, 2013 at 10:45 PM, Alexander Pyhalov  wrote:
>>
>> Hello.
>> While testing 3801 bug fix I observed one interestin unrelated GCC effect.
>> We have two gmp libraries:
>> one from library/gmp
>>
>> $ ls -l /usr/lib/libgmp.so*
>> lrwxrwxrwx 1 root root 15 Jun 13 23:28 /usr/lib/libgmp.so ->
>> libgmp.so.3.5.0
>> lrwxrwxrwx 1 root root 15 Jun 13 23:28 /usr/lib/libgmp.so.3 ->
>> libgmp.so.3.5.0
>> -rwxr-xr-x 1 root bin  294528 Jun 13 23:28 /usr/lib/libgmp.so.3.5.0
>>
>> and another coming with gcc
>> $ ls -l  /usr/gcc/4.7/lib/libgmp.so*
>> lrwxrwxrwx 1 root root 16 Jun 13 23:39 /usr/gcc/4.7/lib/libgmp.so ->
>> libgmp.so.10.0.5
>> lrwxrwxrwx 1 root root 16 Jun 13 23:39 /usr/gcc/4.7/lib/libgmp.so.10
>> -> libgmp.so.10.0.5
>> -r-xr-xr-x 1 root bin  577620 Jun 13 23:39
>> /usr/gcc/4.7/lib/libgmp.so.10.0.5
>>
>> Now, when autoconf tries to find libgmp it tries to compile the next
>> program:
>> /* confdefs.h */
>> #define PACKAGE_NAME "FULL-PACKAGE-NAME"
>> #define PACKAGE_TARNAME "full-package-name"
>> #define PACKAGE_VERSION "VERSION"
>> #define PACKAGE_STRING "FULL-PACKAGE-NAME VERSION"
>> #define PACKAGE_BUGREPORT "BUG-REPORT-ADDRESS"
>> #define PACKAGE_URL ""
>> #define HAVE_LIBGMP 1
>> #define HAVE_DECL_MPZ_POWM 1
>> #define HAVE_DECL_MPZ_POWM_SEC 1
>> /* end confdefs.h.  */
>> #include 
>> #include 
>> #if ((' ' & 0x0FF) == 0x020)
>> # define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
>> # define TOUPPER(c) (ISLOWER(c) ? 'A' + ((c) - 'a') : (c))
>> #else
>> # define ISLOWER(c)  (('a' <= (c) && (c) <= 'i')
>> || ('j' <= (c) && (c) <= 'r')   || ('s' <= (c) && (c) <=
>> 'z'))
>> # define TOUPPER(c) (ISLOWER(c) ? ((c) | 0x40) : (c))
>> #endif
>>
>> #define XOR(e, f) (((e) && !(f)) || (!(e) && (f)))
>> int
>> main ()
>> {
>> int i;
>> for (i = 0; i < 256; i++)
>> if (XOR (islower (i), ISLOWER (i))
>> || toupper (i) != TOUPPER (i))
>> return 2;
>> return 0;
>> }
>>
>> with: gcc -o gmp gmp.c -O2 -lgmp
>> The command finishes succesfully but links gmp to libgmp.so.10:
>> $ ldd gmp
>> libgmp.so.10 =>  (file not found)
>> libc.so.1 => /lib/libc.so.1
>> libm.so.2 => /lib/libm.so.2
>> So, the resulting binary cannot be run.
>>
>> So, I have an ethernal question: who is guilty and what to do?
>>
>> --
>> System Administrator of Southern Federal University Computer Center
>>
>>
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> http://openindiana.org/mailman/listinfo/oi-dev
>
>
>
>
> --
> Michael Schuster
> http://recursiveramblings.wordpress.com/
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

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

[oi-dev] Vanilla illumos-gate in OI hipster repo

[Andrzej Szeszo]

Hi All

I have configured Jenkins job which is continuously building and
publishing vanilla illumos-gate packages to the /hipster repo.

Jenkins is actually rebuilding this component:

https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/illumos/illumos-gate

The big change is that illumos-gate is being built with patched gcc
4.4.4. Previous packages were built using Studio.

Happy updating!

Andrzej

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

Re: [oi-dev] new (minor) dependency issue in hipster repo

[Andrzej Szeszo]

There was a short period when /hipster repo was broken a little bit.
Are you still having the same problem?

Andrzej

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

Re: [oi-dev] Vanilla illumos-gate in OI hipster repo

[Andrzej Szeszo]

Every two hours and every time someone pushes something to oi-userland
Jenkins runs gmake publish in illumos-gate component directory.

If the latest illumos-gate checkout was already built, gmake publish
is a no op and returns immediately.

Not optimal, but this is how it is set up right now.

Andrzej


On 20 June 2013 09:17, Piotr Jasiukajtis  wrote:
> Andrzej,
>
> What is the interval for the builds? Daily, hourly?
>
> --
> Piotr Jasiukajtis
>
> On Jun 20, 2013, at 1:10 AM, Andrzej Szeszo  wrote:
>
>> Hi All
>>
>> I have configured Jenkins job which is continuously building and
>> publishing vanilla illumos-gate packages to the /hipster repo.
>>
>> Jenkins is actually rebuilding this component:
>>
>> https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/illumos/illumos-gate
>>
>> The big change is that illumos-gate is being built with patched gcc
>> 4.4.4. Previous packages were built using Studio.
>>
>> Happy updating!
>>
>> Andrzej
>>
>> ___
>> 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] new (minor) dependency issue in hipster repo

[Andrzej Szeszo]

Have you got packages from publishers other than openindiana.org installed?

Can you provide output of the command below?

pkg list | grep -v -- i--

Cheers,

Andrzej


On 21 June 2013 00:50, Chad Cantwell  wrote:
> Yes, I noticed a commit about an issue with the hipster repo that was said to 
> be fixed
> before I ran across the issue.  Anyway, I just checked another machine (since 
> I don't
> want to reboot the first machine into the older BE), and it has the same 
> error I run
> 'pkg uninstall netcat' and then 'pkg install netcat'.  Uninstall completes
> uneventfully but then it can't reinstall:
>
> Creating Plan -
> pkg install: The requested change to the system attempts to install multiple 
> actions
> for legacy 'SUNWftpr' with conflicting attributes:
>
> 1 package delivers 'legacy category=system desc="FTP Server Configuration 
> Files" hotline="Please contact your local service provider" na me="FTP 
> Server, (Root)" pkg=SUNWftpr vendor="Project OpenIndiana" 
> version=11.11,REV=2009.11.11':
> 
> pkg://openindiana.org/service/network/ftp@0.5.11,5.11-0.151.1.8:20130305T144949Z
> 1 package delivers 'legacy category=system desc="FTP Server Configuration 
> Files" hotline="Please contact your local service provider" na me="FTP 
> Server, (Root)" pkg=SUNWftpr vendor=Illumos version=11.11,REV=2009.11.11':
> pkg://openindiana.org/SUNWcs@0.5.11,5.11-0.151.1.8.1:20130619T222328Z
>
> These packages may not be installed together.  Any non-conflicting set may
> be, or the packages must be corrected before they can be installed.
>
>
> Chad
>
>
> On Thu, Jun 20, 2013 at 09:44:50AM +0100, Andrzej Szeszo wrote:
>> There was a short period when /hipster repo was broken a little bit.
>> Are you still having the same problem?
>>
>> Andrzej
>>
>> ___
>> 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] new (minor) dependency issue in hipster repo

[Andrzej Szeszo]

Hi Chad

osnet incorporation package would normally prevent what you saw from
happening. I should have bumped build number when publishing vanilla
illumos packages to the /hipster repo. I didn't do I, hence your
problems.

For now, update your systems before installing any new packages
originating from illumos-gate as a workaround.

Sorry for the inconvenience.

Andrzej

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

Re: [oi-dev] library/libffi breaks dependencies

[Andrzej Szeszo]

Let's package old binary .so.5 objects in the updated libffi package
until we don't have any dependent libs/apps in the repo.

We might need to do something similar when updating openssl as well.

Andrzej

On 23 June 2013 19:44, David Höppner <0xf...@gmail.com> wrote:
> On 23 June 2013 19:15, Erol Zavidic  wrote:
>>
>> Hi Andrzej et al,
>>
>> I just noticed that latest update of the hipster repo broke dependencies
>> of libffi library. I noticed it in Firefox as it failed to start due to
>> missing libffi.so.5 dependency.
>>
>>
>> Simple ln -s fixed the issue (ln -s libffi.so.6.0.1 libffi.so.5) but it's
>> an ugly hack.
>>
>>
>> Can you look into it? Or I missed something in past few days/weeks?
>> Alternatively, advise me briefly how to fix the pkg and I'll post a patch
>> (or pull request on github).
>>
> No, i can confirm this. I just imported libffi from the ec repo but that
> version is too new.
> libffi 3.0.1 maybe the right version (but quite old). We can downgrade or
> include a link in the manifest (both ugly).
>
> Andrzej what you think?
>
> Well this is a general problem.
>
> -- David
>
>
> ___
> 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] Vanilla illumos-gate in OI hipster repo

[Andrzej Szeszo]

Hi Nikola

Because OI hipster is using vanilla illumos-gate, illumos related bugs
can be opened directly against upstream illumos project.

I am not sure what to do about OI hipster specific bugs yet. OI
hipster is a fork of the /dev branch. OI project in redmine on
illumos.org refers to the /dev branch itself. Maybe, at least for now,
post your issues to the oi-dev mailing list?

I was not able to reproduce your VirtualBox problem on my machine
here. Latest VirtualBox and zoneaccess service appears to be working
on fully updated system here:
http://linux01.everycity.co.uk/~aszeszo/skitched-20130629-190412.png

At least for now, the idea behind OI hipster is for it to remain a
rolling release. Sometimes things will break. But thanks to BEs and
easy contribution process things can be fixed or rolled back quickly.

illumos-gate updates in OI hipster are fully automatic and there is no
OI specific testing done prior to integrating the packages in the
/hipster repo.

Cheers,

Andrzej




On 29 June 2013 10:37, Nikola M.  wrote:
> On 06/20/13 01:10 AM, Andrzej Szeszo wrote:
>> Hi All
>>
>> I have configured Jenkins job which is continuously building and
>> publishing vanilla illumos-gate packages to the /hipster repo.
>>
>> Jenkins is actually rebuilding this component:
>>
>> https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/illumos/illumos-gate
>>
>> The big change is that illumos-gate is being built with patched gcc
>> 4.4.4. Previous packages were built using Studio.
> Hi :)
> Where do we post bugs about this updated illumos-gate? Or where to post
> bug for Hipster itself?
> Does bug reports for Hipster need to be separate from Openindiana /dev
> (that a8 Hipster will be)
>
> I have virtualbox zoneaccess service fails to load after version
> illumos-861bfc8. That is the last one that works for zoneaccess starting
> in OI-Hipster with Virtualbox 4.2.14r86644 .
> Does this coincide with switching to GCC or is unrelated?
>
> Can we have updated kernel (illumos-gate) and the rest of the system
> updated separately so packages and illumos-gate could be tested
> independently, or it is better to have them mall updated and live as one
> big updating family?
> Is there some testing procedures for illumos-gate before pushing it up
> to Hipster and prior releasing it to /dev ?
> N.M.

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

Re: [oi-dev] bits from JDS to userland: Re: conflicting files, dependencies and moving spec files to oi-userland

[Andrzej Szeszo]

Hi Milan

I knew similar question will be asked sooner or later.

If I had unlimited amount of spare time, I would convert all spec
files to userland style packages. It is not likely going to happen any
time soon, unfortunately.

So, to make better use of everyone's free time, I think we don't have
a choice and will have to integrate JDS packages to oi-userland
somehow. Perhaps in a similar way as illumos-gate component.

Milan, would you be able to share your JDS build script(s) in case
someone would like to have a go at creating JDS component?

Cheers,

Andrzej



On 12 July 2013 20:05, Milan Jurik  wrote:
> Hi,
>
> is there any process in place for moving bits from JDS to userland? I
> was thinking about possibility to update some JDS bits (with specs, of
> course). And I need to know which bits I could remove from JDS. Could
> anybody responsible for hipster release engineering talk to me about it?
>
> As for conflicting bits - gnome/locale/xxx should be obsoleted in
> hipster already so I do not know which conflict you see. But I did not
> try hipster yet so I have no idea what's broken there.
>
> Best regards,
>
> Milan
>
> On pá, 2013-07-12 at 20:23 +0400, Alexander Pyhalov wrote:
>> Hello.
>> I'm trying to import SUNWxscreensaver.spec to oi-userland.
>> The issue is that it is actually three different packages. I've almost
>> finished with xscreensaver itself, but there are also
>> xscreensaver/hacks, xscreensaver/hacks/hacks-gl and
>> xscreensaver/hacks/rss-glx.
>> The process of determining package boundaries is rather boring and
>> error-prone :)
>>
>> So, I came to the following:
>> now we ship xscreensaver.mo files in gnome/locale/XX packages, which (at
>> least gnome/locale/ru) by the way conflict with
>> gnome/accessibility/gnome-a11y-libs (on
>> usr/share/locale/ru/LC_MESSAGES/at-spi.mo), desktop/gtk2 (on
>> usr/share/locale/ru/LC_MESSAGES/gtk20.mo) and so on
>>
>> The question is following: if we build application on by-component
>> basis, how can we create global package like gnome/locale/XX ? Probably,
>> it can be converted to just meta-package with a lot of dependencies on,
>> e.g. xscreeensaver/locale/XX and so on.
>>
>> The other question is what to do with localization in this particular
>> case...
>
>
>
> ___
> 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] python update

[Andrzej Szeszo]

Hi Alexander

Yes, it looks like python 2.7 component relies on functionality
present only in newer pkg-gate bits. Updating pkg-gate is certainly
doable but perhaps you would be able to find some workaround until
it's done? :)

Cheers,

Andrzej


On 15 July 2013 10:02, Alexander Pyhalov  wrote:
> Hello.
> Do I understand correctly that to build python 2.7 from upstream userland
> gate we have to update pkg - it misses depthlimitedmf27.py ?
>
>
> $ /usr/bin/pkgdepend generate -m -d
> /export/home/build/srcs/oi-userland/components/python/python27/build/prototype/i386/mangled
> -d
> /export/home/build/srcs/oi-userland/components/python/python27/build/prototype/i386
> -d /export/home/build/srcs/oi-userland/components/python/python27/build -d
> /export/home/build/srcs/oi-userland/components/python/python27 -d
> Python-2.7.3
> /export/home/build/srcs/oi-userland/components/python/python27/build/manifest-i386-python-27.mangled
>>/export/home/build/srcs/oi-userland/components/python/python27/build/manifest-i386-python-27.depend
> The command python2.7
> /usr/lib/python2.6/vendor-packages/pkg/flavor/depthlimitedmf27.py usr/bin
> /export/home/build/srcs/oi-userland/components/python/python27/build/prototype/i386/usr/bin/2to3
> exited with return code None and this message:
> [Errno 2] No such file or directory
> ...
>
> If I symlink (just for publish time) python2.6 to python 2.7
> I get:
> python2.7: can't open file
> '/usr/lib/python2.6/vendor-packages/pkg/flavor/depthlimitedmf27.py': [Errno
> 2] No such file or directory
>
> We have /usr/lib/python2.6/vendor-packages/pkg/flavor/depthlimitedmf.py,
> which comes from pkg-gate, but not
> /usr/lib/python2.6/vendor-packages/pkg/flavor/depthlimitedmf27.py...
>
>
> --
> 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] Release engineering // planing

[Andrzej Szeszo]

Hi All

At least for now, /hipster contribution process should stay as it is:
pull requests/direct commits to the github repo. The team is too small
to consider any other options at the moment in my opinion.

I reckon /dev can stay as it is now as well. Jon Tibble is working on
getting the repo updated. When he's done, the update should not break
thousands of existing OI installations. There is a risk of making many
users unhappy if we were to use /hipster repo to replace /dev.

People who are interested in stable release are generally using OI on
the servers. I think future formal hipster-based OI releases could
have packages split into two sets. The "core" one and the "all the
rest" one. Let's learn from the mistakes made in the past and
successes of the other distros and make supported "core" package set
small (additional packages supported on best effort basis).

Also, it would make a lot of sense to have per-release repositories,
like pkg.openindiana.org//<"core"> and
pkg.openindiana.org//<"all the rest">. "something" could be
release codename, date tag, some version number, etc. It would make it
easier to manage things that way. Repos would update quicker, mirrors
would be easier to create and be smaller. It would prevent users from
accidentally replacing all of their system files each time new release
is made (in case of publishing each release to /stable, we have BEs,
but still...). It would be easier to get rid of old unsupported
releases going forward. Also, pkg5 solver would have less metadata to
deal with and would work faster!

Again, we are too small and it is too early to consider formal
releases in my opinion. Unless there are any volunteers to take on the
responsibility? :)

I am very happy to see oi-userland/hipster ball rolling by the way.
Big thanks to everyone who contributed to oi-userland github repo so
far!

Andrzej



On 14 July 2013 16:51, Jim Klimov  wrote:
> On 2013-07-14 15:15, G B wrote:
>>
>> I wouldn't see a problem for this aforementioned because as I mentioned,
>> there won't likely be any new technologies added to OI, such as, ZFS
>> encryption that would say "bump me to a 152 release."
>
>
> I wonder if it is practical to complicate things with
> numbering in such manner, by the way? While it is true
> that illumos kernel was forked from Solaris codebase at
> the time that it reached a specific numbered milestone,
> they evolve in separate universes now. For the development
> numbering we might as well retain this, to simplify updates
> into newer builds for one thing, and for the odd chance
> that the owner of Solaris IP at some time in the future
> would go open-source again and merge code - so we'd bump
> the repo name to their milestone number at that time...
>
> But was there a release, "The Release", of OpenIndiana?
>
> Maybe the first one should be numbered "1"? Or "11" to
> match Oracle's marketing scheme and some similarities
> between the products (somewhere in that string of version
> minor numbers they too have the repo level like 175, BTW)?
>
> I believe it won't be a problem for packaged builds - the
> release/stable packages come from a different repository
> and can have their own version history, I think...
>
> What do you think?
>
> //Jim
>
>
>
> ___
> 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] introducing gfortran or make gcc refactoring?

[Andrzej Szeszo]

Hi Alexander

Lack of gfortran-runtime package is an oversight. I don't think I have
ever used Fortran outside of a Uni. Didn't realise gfortran compiled
software relies on a shared libgfortran library.

I have borrowed runtime library layout from OmniOS and I think it
makes sense. *-runtime packages will carry libraries from GCC 4.7 and
newer. The libs from newer GCC 4.x will have different so names or
will be backwards compatible. Here is an example of g++ runtime lib
which includes libstdc++ libs from GCC 4.8, 4.7, 4.6 and 4.4 (i
think):

http://pkg.omniti.com/omnios/bloody/manifest/0/system%2Flibrary%2Fg%2B%2B-4-runtime%404.8.1%2C5.11-0.151007%3A20130603T175910Z

Advantages are:

runtime lib packages are shared between all GCCs 4.x
libs in the default linker search paths /usr/lib/{,amd64} == no need
to mess with gcc specs or linker flags
software compiled with older GCC will not pull in old gcc runtime
package (if one existed)
more predictability which libs are going to be used at runtime -
Imagine software linked with multiple libs built with different GCCs,
and libs are linked with libgcc_s.so.1. You may end up with a number
of different libgcc_s.so.1 copies loaded in memory at the same time -
not good.

Following what Oracle did with the build recipes, etc. is generally
not a bad idea. We should not be afraid of doing things differently
when it makes sense though.

Oracle GCC layout is not bad, but I personally like OmniOS's one better.

Andrzej

On 28 July 2013 22:00, Alexander Pyhalov  wrote:
> Hello.
>
> Currently we have some mess with our gcc4.7 package. The main problem is
> that it ships two versions of libraries:
> a) runtime so files (gcc/g++) in /usr/lib and /usr/lib/amd64
> b) gcc files (including libs) (in /usr/gcc/4.7/...)
> Not all libraries from gcc/4.7/lib are exposed to /usr/lib.
>
> I've prepared a patch to introduce one more runtime package - for fortran:
> https://github.com/pyhalov/oi-userland/compare/gfortran-runtime
>
> But I don't like the idea of providing the same files twice (in /usr/lib and
> in /usr/gcc/4.7).
> I'd prefer to refactor our package and make it more similar to upstream gcc
> packages (e.g. 4.4/4.5).
>
> In Oracle userland gcc provides just two packages - gcc4x-runtime and gcc4x.
> The first one includes
> all runtime libraries (for gcc/g++/fortran/etc), ships them to
> /usr/gcc/4.x/lib and creates links
> in /usr/lib. And gcc package itself depends on gcc-runtime package.
> It seems more natural then providing independent files in /usr/lib and
> /usr/gcc/4.7.
> What was a reason for such organization?
>
> I don't know if we need to provide just one gcc-4-runtime package or a lot
> of them:
> gcc-4-runtime, g++-4-runtime, gfortran-4-runtime...
>
> Of course, we can leave things as they are and just provide one more
> gfortran-4-runtime package which delivers
> necessary files to /usr/lib.
>
> What do you think?
>
> --
> System Administrator of Southern Federal University Computer Center
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

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

[oi-dev] ISOs

[Andrzej Szeszo]

Hi All

Alexander Pyhalov re-created GUI installer meta-package (thanks Alex!)
so I thought it would be a good moment to create some OI hipster ISOs.

The ISOs are available here: http://dlc-origin.openindiana.org/isos/hipster/

There is a popup with an error message after you start GUI installer.
It needs fixing but does not prevent installer from doing its job, so
ignore it for now.

Cheers,

Andrzej

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

Re: [oi-dev] Wiki

[Andrzej Szeszo]

Hi Guys

Dave, Bryan, I have granted comment moderation rights to your accounts.

Sorry about the delay. Alasdair is very busy man these days. And I am
quite bad at following mailing list activity...

Cheers,

Andrzej


On 15 October 2013 15:05, Dave Koelmeyer
 wrote:
> On 16/10/13 01:42 AM, Bryan N Iotti wrote:
>
> I had also requested to help with the wiki. I know my request was forwarded
> to Alasdair but never heard any more after that.
>
>
> if this doesn't change for the next few weeks, sounds like it may be
> necessary to explore alternate hosting options from the community.
>
> --
> Dave Koelmeyer
> http://blog.davekoelmeyer.co.nz
>
>
>
> ___
> 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] Wiki

[Andrzej Szeszo]

Hi Bryan

I have checked your permissions and they seem to be in order. You
should be able to delete comments just fine. Where is the comment you
were trying to delete?

Cheers,

Andrzej


On 19 October 2013 19:46, Bryan N Iotti  wrote:
> Andrzej,
>   I looked through the wiki and most comments have already been deleted by 
> others.
>
> I found one that has been posted today by "Anonymous", but can't delete it.
>
> Could you please double-check my permissions? My username is fedoracoreuser 
> and I registered using ironsides.med...@gmail.com as my email.
>
> Thanks again,
>Bryan
>
>
> On Wed, 16 Oct 2013 10:02:25 +0200
> Andrzej Szeszo  wrote:
>
>> Hi Guys
>>
>> Dave, Bryan, I have granted comment moderation rights to your accounts.
>>
>> Sorry about the delay. Alasdair is very busy man these days. And I am
>> quite bad at following mailing list activity...
>>
>> Cheers,
>>
>> Andrzej
>>
>>
>> On 15 October 2013 15:05, Dave Koelmeyer
>>  wrote:
>> > On 16/10/13 01:42 AM, Bryan N Iotti wrote:
>> >
>> > I had also requested to help with the wiki. I know my request was forwarded
>> > to Alasdair but never heard any more after that.
>> >
>> >
>> > if this doesn't change for the next few weeks, sounds like it may be
>> > necessary to explore alternate hosting options from the community.
>> >
>> > --
>> > Dave Koelmeyer
>> > http://blog.davekoelmeyer.co.nz
>> >
>> >
>> >
>> > ___
>> > 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
>>
>
>
> --
> Bryan N Iotti
>
> +39 366 3708436
> ironsides.med...@runbox.com
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

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

[oi-dev] New OI hipster ISOs

[Andrzej Szeszo]

Hi All

We are going to start making OI hipster ISOs more frequently now.
There are ISOs from 23 Oct available here now:

http://dlc-origin.openindiana.org/isos/hipster/

You may find them useful when setting up new machines, etc. as there
will be less updates to install.

Cheers,

Andrzej

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

[oi-dev] New pkg5 in the repo

[Andrzej Szeszo]

Hi All

I took Adam's pkg5 work (thanks Adam!), synced the source up with
Oracle's tree as of tonight and committed the changes to the repo.

OI hipster is using pkg5 bits from https://github.com/OpenIndiana/pkg5
now which can be synced with upstream quite easily.

I did try basic operations and installing a zone using updated pkg5
and things seemed to work fine. If you notice that something is not
working please let me know.

Please note that GUI tools were decommissioned by Oracle and will
automatically get uninstalled after running 'pkg update'.

Andrzej

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

Re: [oi-dev] New pkg5 in the repo

[Andrzej Szeszo]

Hi All

Sorry I have screwed up version numbers a bit.

It is all good in the repo now. To fix your upgraded systems run the
following command:

pfexec pkg update -v $(pkg list|awk '$2 == "0.151.1.8.1" && $3 ==
"i--" { print $1 "@0.5.11,5.11-0.151.1.8.1" }')

Cheers,

Andrzej

On 10 December 2013 06:16, Alexander Pyhalov  wrote:
> Hello.
> And several more question on new IPS.
> I see that
>
> on my hipster installations:
> $ pkg info -r package/pkg
>   Name: package/pkg
>Summary: Image Packaging System
>Description: The Image Packaging System (IPS), or pkg(5), is the software
> delivery system used on OpenSolaris systems.  This package
> contains the core command-line components and depot server.
>   Category: System/Packaging
>  State: Installed
>  Publisher: openindiana.org
>Version: 0.5.11
>  Build Release: 5.11
> Branch: 0.151.1.8
> Packaging Date: March  5, 2013 02:48:14 PM
>   Size: 7.44 MB
>   FMRI:
> pkg://openindiana.org/package/pkg@0.5.11,5.11-0.151.1.8:20130305T144814Z
>
> and on the build server
> $ pkg info -r package/pkg
>   Name: package/pkg
>Summary: Image Packaging System
>Description: The Image Packaging System (IPS), or pkg(5), is the software
> delivery system used on Oracle Solaris.  This package
> contains
> the core command-line components and pkg.depotd server.
>   Category: System/Packaging
>  State: Installed
>  Publisher: openindiana.org
>Version: 0.151.1.8.1
> Branch: None
> Packaging Date: December 10, 2013 12:09:42 AM
>   Size: 12.72 MB
>   FMRI:
> pkg://openindiana.org/package/pkg@0.151.1.8.1:20131210T000942Z
>
> Firstly, note, 0.5.11,5.11-0.151.1.8 vs 0.151.1.8.1 versions. Is it
> intentional?
>
> Secondly, I think 0.151.1.8.1 should suppress   0.5.11,5.11-0.151.8 version.
> But I don't see it in the repository.
>
> And finally, I've seen
> "NOTE: Please review release notes posted at:
>
> http://www.oracle.com/pls/topic/lookup?ctx=E23824&id=SERNS";
>
> on build server. There should be a link for OI release notes.
>
>
> ---
> System Administrator of Southern Federal University Computer Center
>
> Alexander Pyhalov писал 10.12.2013 09:12:
>
>> Guys, thank you for this work.
>> It's really great. At least it should allow us to continue work on python
>> 2.7.
>> However, what about testing?
>>
>> Adam Števko писал 10.12.2013 05:08:
>>>
>>> Hi,
>>>
>>> thanks for finishing my work (busy till end of this week with my
>>> master’s).
>>>
>>> Alp and I didn’t want to push this yet into the main hipster repo,
>>> because we were afraid of breakage.
>>> I tried to update to the new IPS (not this version, but version I
>>> worked with) and I failed to boot. As I recall correctly there was a
>>> problem with inconsistent system repository (I don’t have any screen
>>> saved, so I am entirely sure, but it was something with system
>>> repository inconsistency).
>>
>>
>> Was it fixed? Or did it just disappear?
>>
>> ---
>> System Administrator of Southern Federal University Computer Center
>>
>>
>>
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> http://openindiana.org/mailman/listinfo/oi-dev
>
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

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

Re: [oi-dev] OpenIndiana /hipster build number

[Andrzej Szeszo]

I propose a new scheme similar to the following:

Current version strings:

pkg://openindiana.org/SUNWcs@0.5.11,5.11-0.151.1.8.1
pkg://openindiana.org/shell/bash@4.2.45,5.11-0.151.1.8.1
pkg://openindiana.org/package/pkg@0.5.11,5.11-0.151.1.8.1

Proposed new version strings:

pkg://openindiana.org/SUNWcs@0.5.11,5.11-0.2014.0.0.14302.2476
pkg://openindiana.org/shell/bash@4.2.45,5.11-0.2014.0.0.0.2476
pkg://openindiana.org/package/pkg@0.5.11,5.11-0.2014.0.0.5055.2476

The numbers would have the following meaning:

PKGVERS_BRANCH =
0.$(IPSREPO_YEAR).$(IPSREPO_NUM).$(IPSREPO_SUBNUM).$(PKGREV_COMPONENT).$(USERLAND_ID)
PKGVERS = $(PKGVERS_COMPONENT),$(PKGVERS_BUILTON)-$(PKGVERS_BRANCH)

Currently, /hipster IPS repository is only growing, there is no way to
obsolete packages in it, updates and all operations are becoming
slower and slower. I propose importing latest installable packages
from /hispter into /hipster-2014.0 and continuing work in a new
smaller repo. If it becomes too big, we could switch over to
/hipster-2014.1, etc.

I don't think "$(PKGVERS_COMPONENT),$(PKGVERS_BUILTON)-" part of the
proposer version string needs much explanation. For illumos-gate or
pkg5 packages it will always be 0.5.11,5.11-, for other packages it
will be package-version,5.11- (4.2.45,5.11- in case of bash).

The -0.2014.0 part would say which pkg.openindiana.org/hipster-20xx.x
IPS repo package is coming from, for example:

-0.2014.0 = http://pkg.openindiana.org/hipster-2014.0
-0.2014.1 = http://pkg.openindiana.org/hipster-2014.1

IPSREPO_SUBNUM we could bump when there is a "flag day", or when
multiple packages have to be rebuilt for some reason and updated as
the same time.

PKGREV_COMPONENT could be used to specify revision on the component in
the oi-userland, or in case of illumos-gate or pkg5 could be set to
git commit number of illumos-gate or pkg-gate.

USERLAND_ID could be set to oi-userland git commit number that was
used at the time of building the package.

Wondering what others think about the versioning scheme.

Cheers,

Andrzej



On 4 January 2014 05:46, Gordon Ross  wrote:
> Yes, that might be useful, but you'll probably need to get discussion
> going among the various illumos players about what sort of version
> labeling scheme would work for them.
>
> On Thu, Nov 21, 2013 at 1:10 AM, Alexander Pyhalov  wrote:
>> Hello, people.
>> Let's do something about package versions. It's  really awesome to have the
>> newest illumos-gate version. But it breaks existing installations. In
>> current scheme packages are always compiled against latest illumos and we
>> have no way to distinguish between package versions.
>>
>> I see several ways to deal with this problem.
>> 1) Building  illumos-gate only once a week/two weeks/etc, bump ONNV_BUILDNUM
>> (and perhaps BRANCHID at the same time) in  jenkins or in cron job
>> (151.1.8.1.N).
>>
>> 2) We can generate incremental series of ONNV_BUILDNUM automatically and in
>> consistent way. For example,
>> changing
>>
>> echo export ONNV_BUILDNUM=$(ONNV_BUILDNUM)
>>
>> to
>>
>> echo export ONNV_BUILDNUM=$(ONNV_BUILDNUM).$$(git log --format=%H |wc -l|tr
>> -d ' '))
>>
>> in components/illumos/illumos-gate/Makefile
>>
>> will generate consistent (but perhaps, not human-friendly) series of
>> numbers.
>>
>> Any other suggestions?
>> --
>> 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
>
>
>
> --
> Gordon Ross 
> Nexenta Systems, Inc.  www.nexenta.com
> Enterprise class storage for everyone
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

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

Re: [oi-dev] OpenIndiana /hipster build number

[Andrzej Szeszo]

On 9 January 2014 23:06, Alexander Pyhalov  wrote:

> 1) When new repository is created? Once a quarter? When old one is too big?

At least once a year I think. It will be up to us/devs when to create
new repo based on the old repo's size or any other condition.

> 2) What packages are migrated to the new repository?  The latest versions of
> every package in the last active repository?

Yes,  The latest versions of packages in the last active repository,
but only installable ones. If some packages were obsoleted, we skip
them. Same with the renamed packages.

> 3) How do we migrate user systems to new repository, let's say from
> pkg.openindiana.org/hipster to pkg.openindiana.org/hipster-2014.0 and
> further to pkg.openindiana.org/hipster-2014.1 ?
> Some self-destructing SMF? We clearly have to force new BE creation on such
> shift.

After creating new repo, we would upload modded pkg5 to the old repo.
It could emit a message with instructions on what to do to switch the
repos on "pkg update". Users would be expected to have their systems
fully upgraded before switching the repos. I don't think messing with
people's publisher configuration would be a good thing to do.

> As for spped of operations on current repository, is it possible to change
> "pkgrepo rebuild" to "pkgrepo refresh" in Jenkins build jobs? Is it safe? Is
> speedup significant?

We are currently using old-school pkg.depotd --add-content whcih is
fairy quick (it takes minutes). pkg.depotd --rebuild takes 1-2h on the
current repo. Package server is running quite old version of pkg5. I
am not sure pkgrepo refresh is supported by it at all. Long term I
would like to server OI hipster package with newer pkg5 bits but
didn't have a chance to look at it yet.

> Now, about versioning scheme.
> 1) I still don't see a clean way to downgrade package with proposed
> versioning scheme.

I don't think it is possible to perform automatic downgrades with pkg5
in general. Not sure if anything has changed in this regard in the
updated pkg5 code.

> 2) What is a policy for changing PKGREV_COMPONENT? I propose to set it to 0
> by default and force people to increment it with every change in a component
> which affects its functionality (i.e., not just code cleanup). I would reset
> it to 0 with every package version bump (e.g. php 5.21=> php 5.22), this
> will allow us to keep it sane. And I'm not sure that it is a good idea to
> use it just to force package rebuild.

I 100% agree with what you described.

> 3) What will we do with illumos-gate updates? I mean, proposed scheme allows
> us to do it in a safe way. However, when build machine is updated, this will
> force illumos-gate packages update (and BE creation) on a user system even
> if the user just wants to update, let's say, vim. And when you want just
> install security update for php on a server it's a problem if doing so
> requires reboot (for BE activation).
> I see several oppotunities.

> a) We say, that /hipster is a developer's OI version and it's enough if it
> just will not allow user to update package to non-functioning state (i.e.
> updating php 5.21 to 5.22 is not possible in the same BE if build server
> updated illumos-gate-produced packages between times when php 5.21 and 5.22
> versions were built). It's not a perfect scenario, but I'm OK with it. It's
> much better than allowing user to install php 5.22 in the same BE and to
> find out that  it is not functioning because of libc version bump.

> b) We update illumos-gate on the server once a (month/week/ ??? ) to allow
> some period of stability. Let's say, each Saturday, so for more important
> servers I can schedule update if necessary for Sunday.

> c) We update it by hand on "as strictly necessary" basis (perhaps, combining
> with once a month/quarter).
> Related question...

> If I have system/library version A installed on build machine and version
> A+N available in server's default repository, will dependent packages depend
> on version A or on A+N? Can we publish new illumos-gate versions, but hold
> build server's version?

I like option c), it will only work after using some new versioning
scheme though. Currently, incorporation versions are the same between
different illumos-gate builds and we would want to "pkg freeze"
specific version of illumos-gate incorporation on the build server.


> 4) The same question about IPS. As I understand, on each IPS update pkg will
> require new BE (and IIRC it refuses to install any new package until pkg is
> updated).
> I expect that pkg5 repository will not change as often as illumos-gate (at
> least after some time of initial bug-fixing). However, we should have some
> consistent update policy for it.

Perhaps we could tinker with pkg5 logic. I don't think new BEs are
really required when updating pkg5. It creates backup BEs anyway.

> 5) Just a question of taste. Don't you think that
> "4.2.45,5.11-0.2014.0.0.0.2476" is too long? I know, 5.11 is a sacred number
> in Solaris world, 

Re: [oi-dev] OpenIndiana /hipster build number

[Andrzej Szeszo]

Hi All

I was wondering if other people had any concerns or questions about
the proposed versioning scheme?

Cheers,

Andrzej


On 13 January 2014 09:34, Andrzej Szeszo  wrote:
> On 9 January 2014 23:06, Alexander Pyhalov  wrote:
>
>> 1) When new repository is created? Once a quarter? When old one is too big?
>
> At least once a year I think. It will be up to us/devs when to create
> new repo based on the old repo's size or any other condition.
>
>> 2) What packages are migrated to the new repository?  The latest versions of
>> every package in the last active repository?
>
> Yes,  The latest versions of packages in the last active repository,
> but only installable ones. If some packages were obsoleted, we skip
> them. Same with the renamed packages.
>
>> 3) How do we migrate user systems to new repository, let's say from
>> pkg.openindiana.org/hipster to pkg.openindiana.org/hipster-2014.0 and
>> further to pkg.openindiana.org/hipster-2014.1 ?
>> Some self-destructing SMF? We clearly have to force new BE creation on such
>> shift.
>
> After creating new repo, we would upload modded pkg5 to the old repo.
> It could emit a message with instructions on what to do to switch the
> repos on "pkg update". Users would be expected to have their systems
> fully upgraded before switching the repos. I don't think messing with
> people's publisher configuration would be a good thing to do.
>
>> As for spped of operations on current repository, is it possible to change
>> "pkgrepo rebuild" to "pkgrepo refresh" in Jenkins build jobs? Is it safe? Is
>> speedup significant?
>
> We are currently using old-school pkg.depotd --add-content whcih is
> fairy quick (it takes minutes). pkg.depotd --rebuild takes 1-2h on the
> current repo. Package server is running quite old version of pkg5. I
> am not sure pkgrepo refresh is supported by it at all. Long term I
> would like to server OI hipster package with newer pkg5 bits but
> didn't have a chance to look at it yet.
>
>> Now, about versioning scheme.
>> 1) I still don't see a clean way to downgrade package with proposed
>> versioning scheme.
>
> I don't think it is possible to perform automatic downgrades with pkg5
> in general. Not sure if anything has changed in this regard in the
> updated pkg5 code.
>
>> 2) What is a policy for changing PKGREV_COMPONENT? I propose to set it to 0
>> by default and force people to increment it with every change in a component
>> which affects its functionality (i.e., not just code cleanup). I would reset
>> it to 0 with every package version bump (e.g. php 5.21=> php 5.22), this
>> will allow us to keep it sane. And I'm not sure that it is a good idea to
>> use it just to force package rebuild.
>
> I 100% agree with what you described.
>
>> 3) What will we do with illumos-gate updates? I mean, proposed scheme allows
>> us to do it in a safe way. However, when build machine is updated, this will
>> force illumos-gate packages update (and BE creation) on a user system even
>> if the user just wants to update, let's say, vim. And when you want just
>> install security update for php on a server it's a problem if doing so
>> requires reboot (for BE activation).
>> I see several oppotunities.
>
>> a) We say, that /hipster is a developer's OI version and it's enough if it
>> just will not allow user to update package to non-functioning state (i.e.
>> updating php 5.21 to 5.22 is not possible in the same BE if build server
>> updated illumos-gate-produced packages between times when php 5.21 and 5.22
>> versions were built). It's not a perfect scenario, but I'm OK with it. It's
>> much better than allowing user to install php 5.22 in the same BE and to
>> find out that  it is not functioning because of libc version bump.
>
>> b) We update illumos-gate on the server once a (month/week/ ??? ) to allow
>> some period of stability. Let's say, each Saturday, so for more important
>> servers I can schedule update if necessary for Sunday.
>
>> c) We update it by hand on "as strictly necessary" basis (perhaps, combining
>> with once a month/quarter).
>> Related question...
>
>> If I have system/library version A installed on build machine and version
>> A+N available in server's default repository, will dependent packages depend
>> on version A or on A+N? Can we publish new illumos-gate versions, but hold
>> build server's version?
>
> I like option c), it will only work after using some new versioning
> scheme though. Currently, incorporatio

Re: [oi-dev] SPARC-port: THIEF of my work, not this time again!

[Andrzej Szeszo]

Hi Martin

I am impressed by the amount of work you are putting into OpenSXCE. I
am even more impressed by the fact that you got KMS and new Intel
drivers working.

May I selfishly ask if you have any plans to integrate your KMS
changes with upstream illumos-gate?

If not, do you have any plans to release OpenSXCE/KMS sources? Perhaps
someone else could integrate them with upstream illumos-gate with your
permission (and giving you credit, etc.)?

Cheers,

Andrzej


On 23 January 2014 22:51, Martin Bochnig  wrote:
> WOW: Mr. Ben Taylor aka @SunTzuTech silently joins me, tells me
> nothing and asks lots of odd questions.
>
> He didn't say a single good word about OpenSXCE. Instead I now see on
> the OI lists that he wants to steal/clone my work under his name 4 OI
>
> he did the same in 2006 with my sparc post of QEMU, he understood
> nothing of the code. But then took my patches and submitted them
> upstream
>
>
> UNDER HIS NAME!!!
>
>
>
>
> [OpenIndiana-discuss] sparc support   Ben Taylor
>
>   
> http://openindiana.org/pipermail/openindiana-discuss/2014-January/thread.html#14853
>
>   [OpenIndiana-discuss] sparc support   Saso Kiselkov
> [OpenIndiana-discuss] sparc support   Stefan Müller-Wilken
> [OpenIndiana-discuss] sparc support   Saso Kiselkov
> [OpenIndiana-discuss] sparc support   Stefan Müller-Wilken
> [OpenIndiana-discuss] sparc support   Saso Kiselkov
> [OpenIndiana-discuss] sparc support   Stefan Müller-Wilken
> [OpenIndiana-discuss] sparc support   Saso Kiselkov
> [OpenIndiana-discuss] sparc support   Stefan Müller-Wilken
> [OpenIndiana-discuss] sparc support   Adam Glasgall
> [OpenIndiana-discuss] sparc support   Stefan Müller-Wilken
>
>
>
> I would like to thank my friends, sponsors, mentors and supporters.
> Last but nor least for having informed me what's going on here.
> This permitted me to resubscribe for this message.
>
> Note: Forking, branching off all that is absolutely fine and ok.
> But not from behind!
> Mr. Ben Taylor subscribed on twitter.com/martinbochnig a few days ago,
> without saying a single word concerning his grand plans.
> The only thing I wondererd about: He asked all sorts of questions,
> even quite silly ones.
> While not having a single good word about OpenSXCE, nor any personal
> "hello" or apology for qemu, timetravel back to 2006/2007   ...
>
>
> I wish everyone Good Luck with this effort, but not this way.
>
>
> --
> regards
>
> %martin bochnig
>   http://svr4.opensxce.org/sparc/5.11/
> http://opensxce.org/
>
> http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD
> http://www.youtube.com/user/MartUXopensolaris
> https://twitter.com/MartinBochnig
>
> ___
> 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] SPARC-port: THIEF of my work, not this time again!

[Andrzej Szeszo]

Hi Ken

>From what I understand KMS support requires significant kernel development
effort. Few people tried to do the work but only Martin succeeded so far
(well done Martin!).

Compiling updated X.org components would be a less of an effort and would
not require so much expertise.

The driver from https://www.illumos.org/issues/4044 is useless on illumos
without KMS support in the kernel if I understand correctly?

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

Re: [oi-dev] threaded perl and possible troubles

[Andrzej Szeszo]

Sounds good to me.

Cheers,

Andrzej

On 27 February 2014 08:37, Alexander Pyhalov  wrote:
> On 02/27/2014 12:31, Igor Kozhukhov wrote:
>>
>> On Feb 26, 2014, at 11:23 PM, Alexander Pyhalov wrote:
>>
>>> Hello.
>>> It looks like mod_perl 2.0.8 for Apache 2.4 requires threaded perl. Do I
>>> understand correctly that after rebuilding perl with -Duseithreads we have
>>> to rebuild all perl 5.16-dependent binary modules (luckily, they   are in
>>> the gate)? What about other software? How does it depend on this?
>>
>>
>> As i know Perl-5.16 have threads as default and no need rebuild it again.
>> threads have been updated for perl-512 in oracle userland-gate.
>>
>> i'm using for dilos perl-512 as 32bit, perl-516 as 64bit and have no found
>> issues with apache and modules, but i have less list of it.
>>
>
> Hi.
> It seems that perl 5.16 doesn't know about useithreads -
> /usr/perl5/5.16/bin/perl  -V:useithreads
> useithreads='undef';
>
> (and mod_perl for apache 2.4 requires them). I think I'll do the following:
> a) wait for integration of https://www.illumos.org/issues/3900 fix,
> b) obsolete perl 5.10 and replace it with perl 5.16
> c) add perl 5.18 compiled with -Duseithreads
>
> --
> 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] Hipster and custom illumos-gate

[Andrzej Szeszo]

Try doing:

pkg set-publisher --non-sticky openindiana.org

to allow packages that originally came from openindiana.org repo to be
upgraded with packages from a different repo.

Cheers,

Andrzej



On 24 April 2014 16:53, Jim Klimov  wrote:

> So... based on this suggestion, the hipster illumos-gate makefile, and
> some earlier list posts, I came up with this change to my illumos.sh script:
>
> # To enable upgrades over `pkg info osnet-incorporation | grep Branch:`
> #   Branch: 0.151.1
> #export ONNV_BUILDNUM=152
> #export ONNV_BUILDNUM=151.1.100
> # http://openindiana.org/pipermail/userland-team/2013-August/000261.html
> # http://comments.gmane.org/gmane.os.openindiana.devel/2906
> export PKGVERS_BRANCH=3014.0.4.24
> export BRANCHID=3014.0.4.24
> Some 47 minutes later I've got an incrementally-rebuilt repository which
> cheerfully includes packages like
>
>   
> SUNWcs
> 0.5.11-3014.0.4.24:20140424T130517Z
>
> However, a "pkg -R /a update" still insists on downloading new hipster
> patches with the 0.5.11-2014.0.1.14459:20140423T191935Z versions from the
> internet, rather than quickly installing the newer and higher-versioned
> local equivalents. This happens also if I use "-g" to specify a repo
> explicitly, and when I use a file-based repo instead of its http service.
>
> I guess nowadays IPS tries to update same-named packages using the same
> repo they were installed from specifically to avoid conflicts like these?
> How should I go about overriding that reasonable failsafe mechanism? ;)
>
> Thanks,
> //Jim
>
> - Исходное сообщение -
> От: Alexander Pyhalov 
> Дата: Thursday, April 24, 2014 13:39
> Тема: Re: [oi-dev] Hipster and custom illumos-gate
> Кому (To): OpenIndiana Developer mailing list 
> Копия (Cc): Jim Klimov , Discussion list for OpenIndiana <
> openindiana-disc...@openindiana.org>
>
> >
> > Hi, Jim.
>
> >
> > On 04/24/2014 02:45, Jim Klimov wrote:
> > >After completing a build I am suddenly stuck
> > trying to install
> > > the newer illumos-gate packages into a new BE: their versioning
> > > (0.151.1.100 per my arbitrarily big choice) is less than Hipster's
> > > (2014.*, without even a leading zero which is auto-prepended
> > to the
> > > values I provide in illumos.sh)... Should I have to somehow enforce
> > > larger 2014.* version numbers, or is there a way (onu?) to override
> > > existing packages and force installation of their "namesakes" from
> > > the on-nightly repository regardless of the version numbers?
> > I think you should set PKGVERS_BRANCH to something greater than
> > 2014.0.N.N (e.g. 2014.1.0.0).
>
> >
> > >
> > >Also, leaping a bit ahead: would/should KVM
> > work in Hipster out
> > > of the box, including the case when Hipster itself is virtualized
> > > by a hypervisor, or would I need to compile some other patches
> > > into my illumos-gate? Specifically, I am interested in software
> > > emulation for the VM anyway (ARM Linux via QEMU)?.. And also, did
> > > anyone try (and succeed) to set up cross-compilation of Linux ARM
> > > programs running the process under illumos/OI/Hipster, whether in
> > > native illumos zones or in lx-branded ones, or should I look forward
> > > to necessarily running a Linux VM as well for that task?
> > >
> >
> > I tested the following patch from David:
> > http://www.ulx.cc/assets/source/104_interdiff.diff
> > It worked for me, but if I understand correctly it's just a
> > restoration
> > of Sun lx/lx26 work.  I think you could easily use
> > components/illumos/illumos-gate component from oi-userland, but
> > you have
> > to apply necessary patches by hand. I'm going to add
> > patching support
> > (I mean usual oi-userland prep mechanism) for this component in
> > near
> > future. If you are going to use illumos-gate component, you'd
> > better to
> > bump BRANCHID so that your packages would be preferred.
> >
> > --
> > Best regards,
> > Alexander Pyhalov,
> > system administrator of Computer Center of Southern Federal University
>
>
> --
>
> ++
> ||
> | Климов Евгений, Jim Klimov |
> | технический директор   CTO |
> | ЗАО "ЦОС и ВТ"  JSC COS&HT |
> ||
> | +7-903-7705859 (cellular)  mailto:jimkli...@cos.ru |
> |CC:ad...@cos.ru,jimkli...@gmail.com |
> ++
> | ()  ascii ribbon campaign - against html mail  |
> | /\- against microsoft attachments  |
> ++
>
>
>
>
> ___
> oi-dev mailing list
> oi-dev@openi

[oi-dev] /hipster-2014.1 IPS repo

[Andrzej Szeszo]

Hi All

I took latest packages from /hipster and formed /hipster-2014.1 repo
out of them. New IPS repo is much smaller and should make pkg
install/update/etc. operations faster. We've been talking about doing
it for quite some time now and I have finally did it :)

Build box was re-configured to publish new packages to the 2014.1
repo. /hipster repo will not receive any updates from now on and it is
recommended to change your publisher if you want to track the bleeding
edge branch:

# update your system before making the switch
pkg update

# change the publisher URL
pkg set-publisher -O http://pkg.openindiana.org/hipster-2014.1 openindiana.org

Please let us know if you are having problems with the new repo and we
will try to resolve them.

Cheers,

Andrzej

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

Re: [oi-dev] /hipster-2014.1 IPS repo

[Andrzej Szeszo]

Hi Alexander

I will be all related to the fact that the package server is running
older pkg5 bits. I will try to do something about it sometime this
week.

Regards,

Andrzej

On 16 June 2014 07:19, Alexander Pyhalov  wrote:
> On 06/16/2014 04:03, Andrzej Szeszo wrote:
>>
>> Hi All
>>
>> I took latest packages from /hipster and formed /hipster-2014.1 repo
>> out of them. New IPS repo is much smaller and should make pkg
>> install/update/etc. operations faster. We've been talking about doing
>> it for quite some time now and I have finally did it :)
>>
>> Build box was re-configured to publish new packages to the 2014.1
>> repo. /hipster repo will not receive any updates from now on and it is
>> recommended to change your publisher if you want to track the bleeding
>> edge branch:
>>
>
> Hi, Andrzej.
>
> Thanks for doing this. I've just successfully updated my test systems.
>
> One more IPS question - what do you think about Web UI problem?
> It seems that current Web UI doesn't show latest packages. I think it
> selects packages based on entire version  -
> https://github.com/OpenIndiana/pkg5/blob/oi/src/web/shared.shtml#L51 . So,
> when you go to
> http://pkg.openindiana.org/hipster-2014.1/en/catalog.shtml you see only
> packages from 0.151.1.8.1 branch.
> Interesting thing to note - I don't see such behavior on my build server -
> http://buildzone.oi-build.r61.net:1000/en/catalog.shtml - here I see the
> latest packages.
>
> --
> Best regards,
> Alexander Pyhalov,
> system administrator of Computer Center of Southern Federal University

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

Re: [oi-dev] /hipster-2014.1 IPS repo

[Andrzej Szeszo]

Hi Alexander

I will check on 500 error in a moment.

I left 'illumos-gate' project it disabled initially as I wasn't sure 
about the frequency of the builds going forward (and then forgot about 
the fact I have disabled it).


Would building it every night be frequent enough? I think re-building it 
on every commit is a bit too often. I thought it was a good idea when 
setting Jenkins up initially but not anymore :)


Cheers,

Andrzej

On 23/06/2014 07:50, Alexander Pyhalov wrote:


# change the publisher URL
pkg set-publisher -O http://pkg.openindiana.org/hipster-2014.1 
openindiana.org


Please let us know if you are having problems with the new repo and we
will try to resolve them.



Hi, Andrzej.

I've tried to build ISO image for OI today and got the following error 
on pkg image-create:


http protocol error: code: 500 reason: Internal Server Error
URL: 'http://pkg.openindiana.org/hipster-2014.1/publisher/0/'

It seems to be permanent error.

One more question - why illumos-gate build project is still disabled 
in Jenkins?





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

Re: [oi-dev] oi-hipster live-cd with newest zpool features

[Andrzej Szeszo]

Hi All

Sorry for the delay. I finally made some updated images available:

http://dlc.openindiana.org/isos/hipster/OI-hipster-gui-20140701.iso
http://dlc.openindiana.org/isos/hipster/OI-hipster-gui-20140701.usb
http://dlc.openindiana.org/isos/hipster/OI-hipster-text-20140701.iso
http://dlc.openindiana.org/isos/hipster/OI-hipster-text-20140701.usb

We have discussed creating images with frozen entire package on IRC,
to prevent automatic updates to the latest versions. I didn't do it in
the images above. To freeze the entire package manually, run the
command below after installation:

sudo pkg freeze entire@0.5.11-2014.1.0

Cheers,

Andrzej

On 29 June 2014 22:45, Friedrich Kink  wrote:
> Finally I made it on my own ;-). Obviously you sorted out most if not
> all problems with the new /hipster-2014.1 repository. Anyhow I was now
> able to create again a new ISO/usb image with distro_const. However I
> needed to change the slim_install package with metapackages/gui-install
> to make it successfull. This is just for reference if not planned or
> known already. It looks like the slim_install packages is renamed to
> this according to the pkg info
>
>   Name: slim_install
>Summary:
>  State: Not installed (Renamed)
> Renamed to: metapackages/gui-install@0.1,5.11-2014.0.1.0
>  Publisher: openindiana.org
>Version: 0.1
> Branch: 0.151.1.8
> Packaging Date: Tue Jun 24 16:11:23 2014
>   Size: 0.00 B
>   FMRI:
> pkg://openindiana.org/slim_install@0.1-0.151.1.8:20140624T161123Z
>
> Anyhow again thanks forall your quick answers and information.
>
> Fritz
>
> Am 25.06.2014 06:30, schrieb Alexander Pyhalov:
>> friedrich.k...@fkink.de писал 24.06.2014 23:40:
>>> thanks for your quick answer, but unfortunately even the latest hipster
>>> ISO does not support the latest zpool feature "embedded_data". Is
>>> there a
>>> plan for a new ISO, in the past new releases were quite frequent? Can I
>>> get a description/howto how this ISO's are built?
>>>
>>> Fritz
>>
>> Hello.
>> I think we are going to create new ISO soon. But just for now we have
>> some problems with this after migration to new /hipster-2014.1
>> repository.
>>
>> ---
>> System Administrator of Southern Federal University Computer Center
>>
>
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

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

Re: [oi-dev] [developer] The java bits from my build-elsewhere wad, and prior work (Illumos 4719)

[Andrzej Szeszo]

Hi All

OI hipster is maintained and is using pretty much unmodified
illumos-gate. We apply few cosmetic changes to the vanilla tree but we
don't maintain separate illumos-gate git repo. OpenJDK 7 is available
in OI hipster repos so it should be fine after the switch.

No one is currently actively working on OI oi_151aX branch so there is
no one to coordinate the changes with. I guess whoever picks up the
work in the future would have to include OpenJDK 7 and fix any
illumos-gate related build issues.

Cheers,

Andrzej

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