Re: [oi-dev] Resignation

[Alasdair Lumsden]

> A related issue however is the apparent lack of ownership over the wiki.

In terms of ownership, EveryCity is providing free hosting of various bits of 
OpenIndiana physical infrastructure, but it's down to the OpenIndiana project 
to determine who has ownership. There is a gulf here that nobody has stepped up 
to fill after my resignation.

Keith Wesolowski quipped a joke about OI, referring to it as the Bernie Lomax 
distribution, which I think is quite apt:

https://en.wikipedia.org/wiki/Weekend_at_Bernie's

I don't think the project is going to succeed unless the various interested 
parties come together and figure out who is responsible for what. People are 
going to have to step up and take responsibility, otherwise it's just a lot of 
complaining and hot air about how nothing is happening.

Regarding the wiki directly, various people, myself included, have admin 
accounts and can create more. If you're volunteering, I'm happy to set you up 
with one. If you want access to the zone confluence is running in, I can 
provide that also.

Not that I'm involved any more and I largely just lurk, but I think the 
disconnect between /dev and /hipster needs to end. It's confusing.

I have proposed for years now that:

/hipster = rolling release
/dev = snapshots of /hipster
/release = /periodic snapshots of /dev that are considered more stable

For example you could do automatic /dev releases every 2 weeks. /release can 
come out once a year, and in the month running up to a /release, you can focus 
on fixes rather than new features.

Easy, simple.

It does mean /dev and Jon Tibble's effort making way for Andrzej/ALP/etc's 
hipster effort. The first /release could be based on /dev as is now, but after 
that, my personal opinion is that Jon Tibble should help with the hipster 
effort. Perhaps in particular with ensuring quality /release releases and 
managing that bug fixing process.

Also some of the peanut gallery posts on this mailing list make me want to 
throw up. I don't think anyone should be allowed to attend an OI meeting unless 
they have contributed at least X months worth of commits to the OI github 
account. Talk is cheap, and people should have to earn the right to have an 
opinion on how the project is run.

Back when I was project lead, I made the mistake of soliciting input from all 
interested parties, which resulted in enormous weekly meetings with lots of 
talk and no action. It killed the project, as it became mired in indecision and 
a total lack of focus. What is needed is a single minded lazer sharp focus.

The project is on life support. Commit or GTFO. 
  
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] flowcontrol 10Gbe intel x520‏

[Alasdair Lumsden]

Hi Randy,
Your best bet is to mail the illumos mailing list - none of the illumos 
developers hang out on the oi-dev mailing list, this list is for distribution 
work (i.e. packaging etc).
To test the patch on that issue, you'd have to rebuild illumos-gate and install 
the resulting packages.
Cheers,
Alasdair

From: sim@live.nl
To: oi-dev@openindiana.org
Date: Sat, 26 Apr 2014 23:44:48 +0200
Subject: Re: [oi-dev] flowcontrol 10Gbe intel x520‏




 I found the following issue regarding this nic.Can anyone tell me if the fix 
in this document has been implemented yet or what the status isIt seems to 
solve my problem (if it is a stable fix).If somebody could give me a short mini 
howto on implementing / testing this?
https://www.illumos.org/issues/4063
Regards,
RFrom: sim@live.nl
To: oi-dev@openindiana.org
Date: Sat, 26 Apr 2014 12:25:35 +0200
Subject: [oi-dev] flowcontrol 10Gbe intel x520‏




Hi all,I hope this is readable .
Using an OI 151a7
I'm trying to turn off flowcontroll on an Intel X520-DA2 10Gbe nicI have put 
flow_control   = 0; in /kernel/drv/ixgbe.conf and also done:dladm 
set-linkprop -p flowctrl=no ixgbe0
results after reboot:
dladm show-ether -x ixgbe0
LINKPTYPESTATEAUTO  SPEED-DUPLEX  PAUSE
ixgbe1  current  up   yes   10G-f  
bi--   capable  --   yes   1G-f,100M-f 
bi--adv  -- yes   1G-f  
bi--  peeradv  --   no--
   none
==
dladm show-linkprop -p flowctrl ixgbe0
LINK PROPERTYPERM VALUE  DEFAULTPOSSIBLEixgbe0  
 flowctrlrw   no no no,tx,rx,bi
===The second 
output seems ok, but the first puzzles me. Als the dladm command doesn't show 
any immediate effect, I think it doesn't work.
question on: can somebody clarify to me if flowcontrol is now turned off or 
not? And if not, what do I have to do to turn it off?
I know that there were issues with the ixgbe driver in OI151a7, can this have 
something todo with that? If this is solved in a9, how would I go about adding 
the a9 driver to this a7 system (if thats's possible).
Greetings,

___
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-New-developers] Greetings

[Alasdair Lumsden]

> I'm not exactly sure. I've been using a UNIX-like operating systems for the 
> past 15 years personally and professionally in one form or another. I've 
> followed the free and open source movement for as long. I've always wanted to 
> contribute to a FOSS project but I've never had the time. Now, I find myself 
> with a lot of time and was looking for a project that I could contribute to. 
> I can program in: Shell, C and Lisp relatively well; I'm a quick study. I 
> poked around the OpenIndiana site for where help was needed but didn't find 
> anything. Perhaps you could point me in the right direction?

Hi Scott,

Sorry for the delay in getting back to you!

The OpenIndiana site is quite out of date. The wiki is a bit better, but it's 
also very out of date.

So I'd say the quickest way to get involved is probably to hop onto #oi-dev and 
#illumos on irc.freenode.net - this way you can chat in real time with the devs.

I myself aren't involved at all as a developer although I hang around pointing 
people in the right direction occasionally.

The main area of development is on the /hipster branch (not sure if you're 
familiar with this). You can see the Git repo here:

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

Cheers,

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

Re: [oi-dev] [HEADSUP] gstreamer is rebuilt,

[Alasdair Lumsden]

I never agreed with SFE shipping packages to the system namespace. Conflicts 
and a general mess was inevitable.

They should have shipped to /opt/sfe or similar.



> Date: Tue, 18 Mar 2014 12:39:10 -0400
> From: g...@genashor.com
> To: a...@rsu.ru; oi-dev@openindiana.org
> Subject: Re: [oi-dev] [HEADSUP] gstreamer is rebuilt,
>
> On 03/18/2014 10:15 AM, Alexander Pyhalov wrote:
>> On 03/18/2014 16:54, Gary Gendel wrote:
>>> There is a conflict between the new gstreamer packages and sfe so ffmpeg
>>> cannot be installed after updating gsteamer.
>>>
>>> in sfe-encumbered ffmpeg depends on libschroder which depends on orc.
>>> Gstreamer has orc which conflicts with sfe-encumbered.
>>>
>>> Gary
>>
>> Hello.
>> What do you mean by 'gstreamer has orc'?
>> I think you mean that gstreamer/plugin/base and gstreamer/plugin/good
>> depends on developer/orc.
>> SFE provides system/library/orc. This inconsistency in naming leads to
>> a conflict.
>> Is your system/library/orc coming from SFE?
>> The other issue is that in /dev system/library/orc is at 0.5.11
>> version now. So we have to use fictive package version to allow
>> updates /dev => /hipster.
> 
> # pfexec pkg install ffmpeg
> Creating Plan (Checking for conflicting actions): \
> pkg install: The following packages all deliver file actions to
> usr/include/orc-0.4/orc/orcdebug.h:
>
> pkg://sfe/system/library/orc@0.4.16,5.11-0.151.1.5:20120806T214221Z
> pkg://openindiana.org/developer/orc@0.4.17,5.11-2014.0.0.0:20140225T205246Z
>
> These packages may not be installed together. Any non-conflicting set may
> be, or the packages must be corrected before they can be installed.
> 
>
>
>
> ___
> 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] Git or Mercurial?

[Alasdair Lumsden]

Hi Jim,

You're pretty much right on all of that - github.com/illumos/illumos-gate is 
the main source for illumos.

Some OI stuff has made its way onto https://github.com/openindiana

However much of the legacy OI stuff is still on http://hg.openindiana.org

illumos-gate build instructions should reference the github one. OI stuff 
relating to /hipster should reference github, whilst the /dev stuff probably 
still the old hg stuff.




> Date: Thu, 13 Mar 2014 16:45:43 +0100
> From: jimkli...@cos.ru
> To: oi-dev@openindiana.org
> Subject: [oi-dev] Git or Mercurial?
>
> Hello all,
>
> Many instructions on both the illumos and OI wikis (including some
> pages compiled by myself a couple of years ago) describe Mercurial
> (hg) as the way to fetch the illumos-gate sources. How up-to-date is
> this information? I believe the active development repository for both
> projects has gone over to GitHub, with its simplicity of forks etc.,
> and the hg.illumos.org replicates (checks out/updates) from the Git
> master version. Is this understanding correct?
>
> In consequence, should the Wiki instructions be updated to promote
> the GitHub (original gate or private forks) as the suggested way to
> go (in particular, to easily publish and share fixes and developments
> made by this developer), with HG being a legacy option?
>
> Thanks,
> //Jim Klimov
>
>
> ___
> 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] Test

[Alasdair Lumsden]

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

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

[Alasdair Lumsden]

Hey Alexander,

> Date: Wed, 26 Feb 2014 23:23:25 +0400
> From: a...@rsu.ru
> 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?

Regarding rebuilding binary modules, I don't know - that may be a question for 
the Perl mailing lists.

A lot of the dependencies below may just be wanting the interpreter, rather 
than being a binary module? pkgdepend knows to look at the hashbang at the top 
of scripts.

Cheers,

Alasdair

> 
> Software, which depends on perl 5.16:
> 
> PACKAGE
> pkg:/backup/zetaback
> pkg:/benchmark/filebench
> pkg:/communication/im/pidgin
> pkg:/database/percona-server-55/tests
> pkg:/database/postgres-84/language-bindings
> pkg:/database/postgres-93/language-bindings
> pkg:/desktop/xscreensaver
> pkg:/desktop/xscreensaver/hacks
> pkg:/developer/build/automake-110
> pkg:/developer/build/automake-111
> pkg:/developer/versioning/git
> pkg:/file/mc
> pkg:/image/graphviz/graphviz-perl-516
> pkg:/library/perl-5/database-516
> pkg:/library/perl-5/libwww-perl-516
> pkg:/metapackages/build-essential
> pkg:/network/chat/irssi
> pkg:/network/ipfilter
> pkg:/print/filter/a2ps
> pkg:/print/psutils
> pkg:/runtime/perl-516/module/sun-solaris
> pkg:/service/database/postgres-84/language-bindings
> pkg:/service/database/postgres-92/language-bindings
> pkg:/shell/parallel
> pkg:/system/fault-management/eversholt-utilities
> pkg:/system/management/snmp/net-snmp
> pkg:/system/network/ppp
> pkg:/text/convmv
> pkg:/web/proxy/squid
> pkg:/web/server/apache-22/module/apache-perl
> 
> -- 
> 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] /dev -> /hipster update

[Alasdair Lumsden]

> Date: Fri, 21 Feb 2014 14:59:04 +0400
> From: a...@rsu.ru



> Good day.
> I've been working on updates to several packages in /hipster which are 
> older than in /dev.
> 
> This work is necessary to allow /dev -> /hipster updates.
> 
> Current status is shown here:
> https://docs.google.com/document/d/1teq-uByT4z1wojY74B8J-r35zeLa1CpuEXaBQWhqikY/edit

Excellent work! :-)

Have you thought about pkgrecv-ing the dependents from /dev to /hipster, rather 
than rebuilding?  
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] oi_151a9 roadmap & planning

[Alasdair Lumsden]

> Date: Wed, 19 Feb 2014 12:42:53 +0100
> From: joerg.schill...@fokus.fraunhofer.de

>
> Well it would be great if some people at Illumos would not try to dictate
> things but signal that there is an interest for a collaboration.

illumos is collaborative. In the past year there has been around 50 
contributors all working on the code:

http://github.com/illumos/illumos-gate/graphs/contributors?from=2013-02-17&to=2014-02-16&type=c

Given that SchillixON has 1 collaborator, is it not possible that the barrier 
to collaboration between yourself and illumos is not illumos, but you?

>> It isn't. There are distros using SVR4, dpkg, rpm, IPS, pkgsrc,
>> and/or no packaging at all.
>
> Well, where is the SVr4 package meta data in Illumos?
> Note that IPS meta data is limited compared to Svr4 package meta data and for
> this reason, there is no way to convert meta data correctly.

illumos is not a distribution. It carries packaging metadata in IPS format as a 
convenience for downstream distributions, but downstream distributions are not 
obliged to use IPS. Perhaps in the future illumos will stop shipping package 
metadata completely.

Many other illumos based distributions use other package formats, such as rpm, 
deb and SVR4. Ultimately, packaging is a distribution specific implementation 
detail.

If you wish to use SVR4 in SchilliX, you are free to do so. Nobody is stopping 
you.


> Illumos would need to verify first that Illumos is collaborative.
> Currently we have the unfortunate state that Illumos did not include some
> software even though this was promised and a code review has been presented.
> Colaboration of course also means that partners are trustworthy and implement
> promises.
>
> Once Illumos turned into a trustworthy and collaborative entity, it makes of
> curse sense to file bugs against Illumos.

Illumos is very collaborative. A diverse array of individuals and organisations 
successfully collaborate on illumos every day: 
https://github.com/illumos/illumos-gate/graphs/commit-activity

Illumos has a clearly defined contribution process: 
http://wiki.illumos.org/display/illumos/How+To+Contribute

If you want to collaborate, you have to follow the procedure. Everyone does. If 
you're not prepared to follow the procedure, then that's your problem, and 
nobody else's.

If you correctly follow the procedure, and the community decides it doesn't 
want that specific feature, the mature adult thing to do is to accept this and 
move on and continue to attempt to collaborate on other items.

Forking illumos as SchilliX-ON because you can't follow procedures or because 
people don't want a specific feature integrated is petty and childish. Then 
complaining about it for years afterwards on mailing lists is further evidence 
of stunted emotional development.

If you want to collaborate, collaborate and follow the god damned procedure. 
Otherwise, stop bothering everyone on these mailing lists.

Regards,

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

Re: [oi-dev] basis for better collaboration on illumos and OpenIndiana: small circle, Big circle‏

[Alasdair Lumsden]

(Resending to oi-dev as I recently changed my mailing list email address)
Hi All,

First off - can I ask that people respect others private lives and not CC large 
numbers of people onto this discussion thread, especially those who may not be 
interested. For example Bryan Cantrill has never expressed any interest in 
collaborating on OpenIndiana, and is committed to working on SmartOS and 
illumos. He is a busy man, and it's rude to CC busy people onto discussions 
they most likely don't care about.

Those who care will read the threads on the two mailing lists, illumos-discuss 
and oi-dev.

Dave,

> Date: Sun, 16 Feb 2014 16:38:34 -0500
> From: davidha...@gmail.com
>
> Collaboration Criteria:
> - The original promise was for both Intel & SPARC in the community,
> that promise should be kept.
>
> Forster Other Goals
> - Embedded appliance is something which should be encouraged (beyond
> storage-only appliances)
> - Expansion into other architectures to offer embedded hosting
> opportunities (i.e. ARM, POWER, MIPS)
> - Revisit of embedded ZFS (tiny ZFS was a discussion back in the Sun days)

I think you misunderstand how this whole process works. The process does not 
work like this:

1. Show up on a mailing list, having never made any code contributions
2. Suggest a list of features you think the developers should work on

The process works like this:

1. Choose an area of the operating system you wish to improve
2. Ask on the mailing list if this is a good idea
3. Work on the code
4. Share code
5. Code gets integrated

These mailing lists are not a peanut gallery. Porting the OS to another 
architecture, such as ARM, involves considerable effort, several man-years of 
work by highly skilled engineers. Your list of suggestions demonstrates a 
complete misunderstanding of the amount of work involved in doing these things.

There are only two ways that, for example, an ARM port or an embedded ZFS port 
of illumos would happen:

1. A commercial entity decides that they can profit from such an endeavour, and 
hires someone to work on it
2. One or more enthusiasts take it on as a personal passion project

How can you influence this? With 1, you develop a business plan and try to find 
if any investors are interested in paying for it to happen. People don't work 
for free. With 2, sorry, nobody is going to work on it for you just because you 
asked nicely.

Even SPARC support in OpenIndiana, which is already part of illumos, lacked 
sufficient interest to attract developers willing and able to complete it. If 
you want SPARC support, you need to step forward and work on it.

Nobody is obligated to work on any of this. You have no right to tell people 
what to do. Nobody does.

If you have contributed code, then you may be able to influence the opinion of 
existing developers and perhaps encourage them to work on a feature you'd like. 
However it is up to them whether they do so or not. If it doesn't align with 
their goals, then most likely they'll decline.

OpenIndiana's contribution method is very clear. Checkout 
http://github.com/OpenIndiana/oi-userland and start hacking. Until you've done 
this, you have no project karma.

On the topic of collaboration, illumos sees plenty of collaboration, with a 
regular stream of commits from various entities, both commercial and community. 
You can see the commit log here:

http://github.com/illumos/illumos-gate/commits/master

OpenIndiana has 7 or 8 active developers, who collaborate together via #oi-dev 
on irc.freenode.net, via email, and via the oi-dev mailing list.

Collaboration between distributions is a moot point. OI is a collaborative 
distro who welcome contributions. The other distributions were started by their 
respective founders not because OI doesn't collaborate, but because they have 
different goals.

People cannot show up out of the blue and shout "Hey man, progress is so slow! 
This sucks! You know what? You guys need to collaborate! How about you port to 
POWERPC cause I heard its awesome. By the way can you port GNOME3 and I really 
need my AMD graphics card working, also can you add support for my new netbook. 
Any chance of USB3 support? Thanks guys, let me know when it's done!" 

All it does is /piss people off/.

Regards,

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

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

[Alasdair Lumsden]

> Date: Fri, 14 Feb 2014 15:23:51 +
> From: keith.wesolow...@joyent.com

> But I guess that's just me. Bluntly, leading with OI or treating it as
> special is thoroughly and uncompromisingly insane. Pretending that, in
> 2014 no less, achieving desktop application parity with 1997 GNU/Linux
> is an important goal in operating systems development probably covers
> half the syndromes described by the DSM-5. In the community I *thought*
> we were a part of, that's a nonissue, because the insanity is kept off
> to the side, separate from the core effort and merely one consumer among
> equals. To each his own. Live and let live. What I'm learning here is
> that many people don't see things that way, and want to explicitly
> define illumos and OI as having a single, shared vision. If that's
> what's happening here, I'll be aboard the next train out of this
> nuthouse.

Hi Keith,

You've made an assumption that OI is purely a desktop OS. What a ludicrous 
viewpoint.

OpenIndiana aims to be a general purpose operating system for use in numerous 
deployment scenarios, including on servers. Heck, I'd bet most OI installations 
are on servers doing storage work.

Nobody ever made the claim that OI wanted to compete with Linux for the 
desktop. That's a complete waste of everyone's time. My personal development 
work on OI was all done on a MacBook. My goal at the time was to have a 
replacement for OpenSolaris, which we had been using on servers at my dayjob.

However there are plenty of people who do want to run it on the desktop, and 
who are you to tell them they should not do this?

You seem to think that anyone wanting to have an illumos OS that supports the 
desktop, thinks it can compete with the likes of Windows 8 and Mac OS X. 
Bullshit. Most of the folk running OI on their desktop just want a functional X 
Windows with the latest desktop FOSS. They're workstation power users, probably 
spending most of their time in a terminal window. I seriously doubt they are 
thinking OI will ever gain widespread adoption amongst the general public.

There are also plenty of reasons why having a strong general purpose distro 
with desktop support is in everyone's interest. Plenty of server customers wish 
to run the likes of LibreOffice, Firefox etc in headless mode, and OI 
facilitates this kind of development work.

There are also plenty of people who want to run a community maintained 
distribution that's not affiliated with any commercial entity, which OI 
provides. Given the community status, and given the shared heritage, it's 
fitting that illumos use OI as a reference distro for builds and integration 
work.

Not that I represent the distribution any more, or have any say in these 
things. But someone has to set the record straight.

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

Re: [oi-dev] [discuss] Re: oi_151a9 roadmap & planning

[Alasdair Lumsden]

> From: darth.seri...@gmail.com 

> 
> Thank you all for your response. I am driving you to re-think. It is 
> my personal dream to see our community finally take off and overcome 
> this "heritage of missing collaboration" from Sun in illumos and 
> OpenIndiana. 

With all due respect Seth, you don't know what you're talking about. These 
discussions were had years ago. Who are you to tell us all what you think we 
should all be doing? What gives you the right to pop up out of nowhere, and 
tell others what to do?

We've all made our choices. We all have diametrically opposed viewpoints on how 
things should be done. Many of these viewpoints are irreconcilable, such as the 
IPS debate. I love IPS, and many of the core OI devs love IPS. IPS in our 
opinion is an excellent package management system. I can't speak for all the OI 
devs but I have absolutely no interest what so ever moving away from it.

Peter, Jorg and Martin hate IPS. They still think it can't deliver file based 
packages, demonstrating a complete bloody mindedness the likes of which you'll 
only find in UNIX circles. Maybe you'll get some consensus there, but I doubt 
it. Tribblix, OpenSXCE and Schillix are each distinct separate operating 
systems. Each of them is a personal passion project. Each of them has been done 
mostly in isolation with few outside collaborators. I can't see any of them 
abandoning their babies now.

OpenIndiana is the only distro with a wide (albeit still tiny in the grand 
scheme of things) community developer base. You want to help? Join #oi-dev on 
irc.freenode.net and check out oi-userland and start hacking:

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

This circle jerk nirvana future you wish to create will never exist. If you 
want to help, pick a project and start hacking. Talk is cheap.  
  
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] oi_151a9 roadmap & planning

[Alasdair Lumsden]

Hi Seth,

When I started OpenIndiana, I wanted to avoid the "Linux Distribution
Fragmentation" issue, so I created a community distro and tried to solicit
input from everyone and try to keep everyone happy.

I failed miserably. Nobody wants to collaborate, everyone wants to do their
own thing. Hence the huge number of distros you see before you.

Even OpenIndiana itself can't agree on things, hence /dev vs /hipster, one
spearheaded by Andrzej Szeszo, the other by Jon Tibble.

The problem with OpenSolaris was that it was a diabolical mess... a vast
array of undocumented consolidations all using disparate build systems,
cobbled together with a horrific shambles of a system called distro-import.

The OmniOS guys saw this mess and decided "fuck that" and started from
scratch. A server OS, keeping key things like the IPS package system.

Nexenta is a lost cause, their internal politics and agendas made
collaboration impossible. They are schizophrenic - they couldn't decide
between making a Debian like illumos based OS, a storage OS or a Desktop
OS, nor how to do it. Total shambles. Their attempt at collaboration on
"illumos-userland" and then subsequent reversal completely screwed OI at a
key time.

Joyent have one clear goal - Datacenter. SmartOS is great for that. They
have no interest in helping anyone else out with their distributions. They
don't want illumos to succeed as a desktop OS competitor to Linux, to the
point of being actively hostile to the entire concept. Grep the #illumos
irc log for wesolows.

TribbliX was a for fun desktop-oriented distro (correct me if I'm wrong) by
someone that hates IPS and loves SVR4 packaging. I got the impression Peter
never seemed to want to help OI out directly because of the IPS issue.

XStreamOS, DilOS, Schillix etc all have their own goals and agendas, and
again, have no interest in collaborating.

There is no community. Only self centered individuals who think their way
is best. Fragmentation was inevitable. I stated very clearly that I thought
fragmentation would kill illumos. I still feel that today - fragmentation
is killing illumos. Instead of one strong OS, we have a dozen fringe ones.

Nobody listened. Don't expect them to now.

Alasdair.


On Wed, Feb 12, 2014 at 9:30 AM, seth Nimbosa wrote:

> Basically, we need to take one step back so we can move forward.
>
> the OpenSolaris community as it is has always been small from the start
> after Sun was swallowed by Oracle and all official development ceased
>
> we had to start over with illumos and OpenIndiana,
> however, there has not been much collaboration outside of Nexenta and
> Joyent internal developement, and there is a general feeling of a hack and
> slash attitude within illumos and OpenIndiana circles, not very inviting to
> contributors as significant UNIX code-base inherited from Sun's Solaris
> core is shrinking while the bloat and half-baked code is growing
>
> I think people behind TribbliX, XStreamOS, DilOS, napp-it and OmniOS
> should get together with Schillix and OpenSXCE (previously MartUX) in
> re-creating the original code-base with significant code improvement
> plugged in, if any..
>
> another concern is the 3-Gigabyte download for live media!!!  i remember
> there was a time when there was a light OpenSolaris LiveCD based on build
> 134 (700++ MB), which was easy to try and actually instantly install, from
> which additional packages can be added to build the system that's right for
> you.. even with fast internet connection a 3-GB media is too hard to
> swallow and a high barrier for would-be developers and casual slackers
> trying a modern UNIX-based system
>
> I haven't kept track how build 134 metamorphosed into build 151a9 today,
> since 2011 I was busy in developing Network Technologies and integrated
> solutions through Unified Communications and virtualization working with
> Cisco.com after my failed attempt at volunteering at Sun just when Oracle
> bought it, but i think it is never too late to take one step back and pick
> the pieces of our OpenSolaris community, as the only open source UNIX
> community
>
> a large-scale community collaboration of all OpenSolaris-based
> distribution is needed, and I am willing to do my part in bringing this
> together, hopefully people from the illumos Foundation can help, but the
> community must move forward with or without their stewardship, what we need
> is a massive de-duplication of efforts in our community focused on
> code-based development not dictated by corporate pragmatic decisions alone..
>
> we can start with a BitBucket or a GitHub repository to rehabilitate the
> OpenSolaris code and compile all significant improvements and replacements
> with minimal code-slashing and considerable code-review, this can be done
> incrementally
>
> Sincerely yours,
>
> Seth Nimbosa, your Brother and Comrade-in-Arms
> 
> http://twitter.com/nimbosa
> FB.com/nimbosa
>
>
>
>  -- ** * ** --
>
> * Normal is getting dressed in clothe

Re: [oi-dev] Release engineering // planing

[Alasdair Lumsden]

Hi All,

Back in the days of oi-build, we tried to have a process, and enforce
quality, and it just resulted in super slow progress followed by
near-death. Andrzej didn't contribute at all as he didn't like
the bureaucracy, he just wants to hack-and-go.

So after all that, I basically think Andrzej is completely right with his
current approach - breaking things should be allowed. You can't make
an omelette quickly and easily without breaking a few eggs.

Hipster is an experimental development branch for making rapid progress. If
you break something, you can fix it after, no big deal.

I do think that /dev should get moved to /release, and /hipster should go
to /dev. Not many know about hipster beyond the oi-dev list. It would show
people in the outside world that progress is being made on OI.

And on an unrelated note, someone motivated enough should do something
about www.openindiana.org - it's ugly and out of date :-)

Regards,

Alasdair



On Thu, Jul 11, 2013 at 3:19 PM, Ken Gunderson wrote:

> At Thu, 11 Jul 2013 01:12:50 +0200,
> Adam Števko wrote:
> >
> > Hi Erol,
> >
> > On Jul 10, 2013, at 11:50 PM, Erol Zavidic  wrote:
> >
> > Good evening folks,
> >
> > thanks for your feedbacks so far, here's the summary clustered in
> some way:
> >
> > 1.0 - Release Engineering:
> > 1.1- should not be bureaucratic, i.e. rather an internal
> agreement (Alex)
> >
> > I support this type for now.
> >
> > 1.2- the process of pushing updates to /dev or /stable repos is
> undefined
> > (Alex)
> >
> > 1.3- safeguarding /stable repo (Jon)
> > 1.4- streamline code review and integration process LGTMs (Adam)
> > 1.5- build of many desktop packages impossible due to missing
> Manifests
> > (David)
> > 1.6- creation of development, release and stable branches within
> hipster
> > repository (Erol)
>
> I don't code and been away from OI for a while visiting other
> interesting lands.  It's good to see OI getting some traction.  I have
> used platforms developed on the release, stable, and testing model for
> many years, e.g. FreeBSD.  It worked.  But I question whether this may
> have become rather outdated with the advancement of more modern, agile
> like models.  For example, on the desktop I have been using Archlinux,
> wh/uses a rolling release model, and it has been working out quite
> nicely.  This model eliminates the extra manpower required to maintain
> separate branches.  Of course not many that I know of are using Arch
> server side and I think a /stable branch may be beneficial and
> justifiable on OI.  OTOH, OI was intended as continuation of OS, so
> maybe desktop is it's niches, especially in light of SmartOS and
> OmniOS offerings for server side use.  What compelling features does
> OI offer to compete with these?  Hence, maybe best not to and focus on
> desktop niche.  Maybe not...
>
> In any case, I have been doing some "DevOps" Engineering as of late
> and moving more towards a rolling release model would facilitate
> "Continuous Delivery" <http://continuousdelivery.com/>.  Frequent
> smaller changes make breakages easier to track than "vetting" big
> releases and keep things fresher on the desktop.
>
> Just a few thoughts.  We now return you to your regularly scheduled
> programming...
>
> Peace-- Ken
>
> ___
> 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

Re: [oi-dev] Hipster zone update: command_substitute: cannot duplicate pipe as fd 1: Bad file number

[Alasdair Lumsden]

Hi Lou,

Pipe errors mean the libc in the zone is out of step with the libc in the
global zone or the kernel running. Postwait added some new features to some
system calls including pipe which are not backwards compatible. You will
need to make sure your NGZ has updated properly and got the latest libc
bits. It's possible your pkg update didn't get everything...

Regards,

Alasdair


On Tue, Jul 9, 2013 at 4:54 PM, Lou Picciano wrote:

> Adam, Alexander, Tks for comments on this...
>
> No, the GZ on this machine has been updated to a8, though some weeks ago
> now. It's worth noting that all of the many NGZs updated at that time are
> working beautifully; not a hiccup.
>
> We did have similar mileage to yours at that time, though, in that many
> services were not starting; filesystem/local turned out to be the root of
> those evils... The ultimate culprit there was the mount command,
> segfaulting due to the need for the updated libc (Tks to JT-EC and igork
> for help). We were also seeing the 'unable to unmount filesystem' problems
> which others have reported.
>
> Solution to above was updating GZ as well (make perfect sense; sure), and
> rebooting it.
>
> Current situation is different: Attempt to update _another_ NGZ - still
> seeing the 'unable to unmount' errors, but pkg (-R /zone/root) image-update
> appears to work just fine. But the subsequent zlogin never gets to the
> OpenIndiana banner; it reports this:
>
> The Illumos Project SunOS 5.11  illumos-b49b27dcJuly 2013
> -bash: command_substitute: cannot duplicate pipe as fd 1: Bad file number
> -bash: command_substitute: cannot duplicate pipe as fd 1: Bad file number
> root@:
>
> Looking at repo, enough stuff has changed that I'm assuming the GZ needs
> another update to make all this hang together.
> Hypothesis check, experts?
>
> Regards to all,
> Lou Picciano
>
>
>  - Original Message -
> From: Adam Števko
> To: OpenIndiana Developer mailing list
> Sent: Mon, 08 Jul 2013 00:00:40 - (UTC)
> Subject: Re: [oi-dev] Hipster zone update: command_substitute:
> cannotduplicate pipe as fd 1: Bad file number
>
> Hi,
>
> I have same issue. However, my zone seems to be in some inconsistent
> state, where no SMF service started. I upgraded zone to hipster release,
> but the GZ is on /dev. Can this be the issue?
>
> Cheers,
> Adam
>
> On Jul 7, 2013, at 1:14 PM, Lou Picciano  wrote:
>
> Have recently updated many of our zones to a8 Hipster - working great! And
> thanks for your hard work, Andrzej and others...
>
> Having just updated yet another zone - using the repo as of late
> yesterday( 06 July), we see the following on zlogin. Never get near the
> OpenIndiana banner:
>
> The Illumos ProjectSunOS 5.11  illumos-b49b27dcJuly 2013
> -bash: command_substitute: cannot duplicate pipe as fd 1: Bad file number
> I'll have to dig through the various .profiles and scripts which may be(?)
> on this container, but does above ring any bells?
>
> Lou Picciano___
> 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
>



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

Re: [oi-dev] OpenSXCE: To live or to die

[Alasdair Lumsden]

twitter.com/MartinBochnig/status/341654750053400576>
> 11.   [image: Martin Bochnig] *Martin Bochnig* @*MartinBochnig*
><https://twitter.com/MartinBochnig> 
> 2h<https://twitter.com/MartinBochnig/status/341654715823685632>
>
>How to build stuff or packages? As long as no sponsor helps us, maybe
>I never release ANY src.
>
>
> ___
> 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

Re: [oi-dev] OI project reboot required

[Alasdair Lumsden]

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

Re: [oi-dev] OI project reboot required

[Alasdair Lumsden]

Hi,

One thing to keep in mind that OI has (or at least, had) the largest
install base of any OpenSolaris derived distro, thanks to the fact it is
"upgrade compatible" with OpenSolaris. If you don't maintain that, then
there is no point in continuing with OI - you may as well start with OmniOS.

My personal view was that I wanted OI to be to illumos what Debian was to
Linux - a community maintained general purpose operating system.

If we had managed to kick OI into shape with regular releases and up to
date software, it might have had a bright future. It certainly had plenty
of users.

Alasdair


On Thu, May 9, 2013 at 2:05 PM, ken mays  wrote:

> Hello,
>
> 1. Provide an updated kernel userland (i.e. Illumos-gate, rev:
> 19e11862653b or higher). This allows people that use OI for server-based
> projects to stay in sync with Illumos development on a much wider scale.
>
> 2. Optionally, implement JDS updates already maintained by Milan from
> http://pkg.opensolaris.cz/osol/en/index.shtml.
>
> That is it. This also keeps most things consistent to other project work
> dealing with GNU/userland/spec-files-extra testing with <= oi_151a7.
>
> You can do this with very minimal manpower and not need to rebuild
> components / entire consolidations as much (aka 'project overkill'). You
> can also
> just dump the updated packages in a IPS repo for testing and review.
>
> You don't necessarily have to 'make world' right off the cuff. Start
> small, then think big.
>
> Fact: Entire distribution projects like Tribblix, Milax/OpenSXCE, EON, and
> DilOS are maintained by 1-2 people.
>
>
> Hope that helped,
>
> Ken Mays
>
>
>
>
>
>
>
>
>
>
>   --
>  *From:* Andrzej Szeszo 
> *To:* OpenIndiana Developer mailing list 
> *Sent:* Thursday, May 9, 2013 4:01 AM
> *Subject:* [oi-dev] OI project reboot required
>
> 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
>



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

Re: [oi-dev] Building OpenIndiana

[Alasdair Lumsden]

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

If you want to "build OI", you need to understand that there is no single
way to build the whole OS, there is no equivalent of, for example,
FreeBSD's "make buildworld". Each consolidation would have to be built
separately, then merged with distro_import.

If you just want to update a single package, you could identify what
consolidation the software you want to update lives in (which you can see
in the packages metadata, for example "set
name=org.opensolaris.consolidation value=gnome" indicates the JDS
consolidation). Then build that consolidation (or just the package in
question). But if any other software depends on what you're updating, you
have to rebuild it, and that often crosses consolidation boundaries.

If I had more time and motivation I still think it would be worth sorting
the OI mess out, but time and motivation are in very short supply. I
started OI because our business used OpenSolar

Re: [oi-dev] State of development

[Alasdair Lumsden]

Strong leadership and a very very large investment in man-hours.

The problem with OI is the build and assembly of it, i.e. the "release
engineering". It's very difficult and very tedious as-is. Nobody wants to
do it. Well, almost nobody - Jon Tibble has taken this on, but given the
amount of work involved, I am not surprised progress has been slow.

The whole way the OS is built needs refactoring. At the moment there are a
large number of different build systems, "consolidations" in Sun parlance,
such as JDS (desktop), SFW (Sun Freeware), userland-gate, pkg5, xnv, etc
etc. This needs to all be reduced to one single easy to use build system
(ideally).

I attempted to do this with oi-build, which took the best build system
(userland-gate) and automated building with Jenkins (a continuous build
system). But oi-build got politicised, Nexenta wanted to collaborate with
OI on the userland, so oi-build became illumos-userland, which went
nowhere, and ended up pissing everyone off to the point people lost
interest and the whole thing died. Then I resigned.

I don't know what Jon Tibble's plans are, I think the last time I spoke
about it he favoured a slow movement of things into oi-build over time.
Perhaps that's a good place for contributors to get started.

I imagine people do want to contribute, and would, if they had an easy way
to do so, with documentation and guidance and a helping hand.


On Mon, Apr 15, 2013 at 8:21 PM, Jim Klimov  wrote:

> On 2013-04-15 20:56, Jose-Marcio Martins da Cruz wrote:
>
>  Alasdair Lumsden wrote:
>>
>>> OpenIndiana was started as an open source community developed distro
>>> similar to Debian, but due to a
>>> lack of interest there are only a few developers working on it part
>>> time, so updates are slow, and
>>> limited in scope due to the size of the project.
>>>
>>
>> Does this means that you think OpenIndiana is dead ? If yes, how to
>> avoid it ?
>>
>
> That is a two-fold question.
>
> If it is "how to avoid OI" - the answer is, alas, trivial ;)
>
> If it is "how to avoid DEATH of OI" - commit fixes and RFE/bug reports.
> One frequently requested vector is regular and frequent integration of
> updated versions of common open-sourced software and particularly of
> security patches (maybe porting of those and feeding back upstream, if
> existing bugfixes are not verbatim applicable on Solaris/illumos/OI).
>
> Test the new solutions provided by upstream code repositories that they
> don't break OI and provide the feedback that these can be pulled into OI
> (or if they should be avoided because of this and that, which needs to
> be fixed).
>
> On the organizational side, build an up-to-date information (or validate
> existing one) about constructing the distro, including rebuilds of the
> kernel, userspace and 3rd-party (SFE) software. And get some process in
> place to more regularly roll out package updates and live-media distro
> images. After all, OI is largely just one of many methods to package
> common software, which other distros fulfil with their methods. There
> is likely some code unique to OI (such as, perhaps, the installer and
> its default behavior, or the GUI-related things mostly absent from the
> server-oriented distros), but much of the kernel and updated utilities
> RTI'd recently are common with the upstreams (illumos-gate et al).
>
> Here's my thoughts on this,
> //Jim Klimov
>
>
> __**_
> 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

Re: [oi-dev] State of development

[Alasdair Lumsden]

Hi GB,

If you're looking to move to a new OpenSolaris derived distro (i.e. based
on illumos, which is where all the kernel/core userland development takes
place across all distros) then there are many choices besides OpenIndiana.

I'd strongly recommend looking at SmartOS or OmniOS. SmartOS is developed
commercially by Joyent, a large cloud computing provider in the US. OmniOS
is also developed commercially by OmniTI, a fairly large IT services
company. SmartOS may make a good choice as you're from a BSD background, it
uses pkgsrc for packages.

OpenIndiana was started as an open source community developed distro
similar to Debian, but due to a lack of interest there are only a few
developers working on it part time, so updates are slow, and limited in
scope due to the size of the project.

Regards,

Alasdair




On Sun, Apr 14, 2013 at 4:16 PM, Magnus  wrote:

>
> On Apr 14, 2013, at 10:51 AM, G B wrote:
>
> > OI's last release was Oct 2012, so my question is when is the next
> release (151a8) scheduled to be released?
>
> If you're coming from OpenBSD, this shouldn't be at all alarming.
> ___
> 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

Re: [oi-dev] 2324 bring unrar changes from userland-gate

[Alasdair Lumsden]

On 10/ 1/12 09:11 PM, Adam Števko wrote:

I restored the original CDDL license for Makefile. As p5m file was fully 
recreated, I left illumos CDDL version.

Changeset: 
https://bitbucket.org/xenol/oi-build-2324/changeset/7bc51366b2e8945f43f6bfc72a38d7614d613d11


Hi Adam,

Cool - thanks. It was more just the copyright line, it's fine (and 
preferred) to update the CDDL to the new one, but that's not too 
important. The main thing is preserving Oracle copyright on any files 
created by them.


Understood regarding the .p5m file! Cool stuff :-)

Just Milan's recommendation regarding the legacy action version number, 
and then it's +1!


Cheers,

Alasdair

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

Re: [oi-dev] 2324 bring unrar changes from userland-gate

[Alasdair Lumsden]

Hi Adam,

On 10/ 1/12 07:42 PM, Adam Števko wrote:

URL: https://www.illumos.org/issues/2324
Changeset: 
https://bitbucket.org/xenol/oi-build-2324/changeset/e4324e058d735b541e1603ba97840b49cc407d9c

To sum up, oracle removed one patch, which was accepted by upstream. Package 
can be compiled by studio and works.

Any feedback welcome.


Looks good! Only one comment and it looks like the Oracle copyright 
lines were removed rather than just added to. Since they were the 
original author we need to keep those - would you mind adding them back?


Otherwise, +1!



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

Re: [oi-dev] is there a vector for donating to OI?

[Alasdair Lumsden]

On 07/09/2012 06:07, garrett.dam...@dey-sys.com wrote:

There have been technical disagreements, and I've pointed out that there has 
been in the past what I think represents a lack of clear vision for OI.  But 
that's *my* opinion, and I don't speak for illumos in this regard.  (Nor can I 
-- or anyone else -- illumos is moving towards a mutual benefit corporation 
that would preclude a single person dictating the position of illumos.)


I'm sorry if our vision wasn't communicated properly.

When OI started, Oracle were still publishing all the source to 
OpenSolaris including ONNV. OI was started to provide binary builds of 
that so that those of us using OpenSolaris could continue to do so. This 
made us equivalent to the CentOS->RedHat relationship.


Then Oracle closed the gate and illumos took on a life of its own, and 
soon after OpenIndiana abandoned any notions of being a clone of Solaris 11.


The new vision that arose from this was very much about being the 
leading *community* developed illumos based general purpose operating 
system. Basically what Debian is to the Linux world.


I hope that's clear.


However I think OI and illumos have been fairly symbiotic -- indeed OI still builds upon 
the illumos base, and at the moment OI is the "de-facto" reference distribution 
of illumos.  However, if OI is considering a different base -- say SchilliX -- then that 
would probably represent a significant rift.   (I have some concerns about the topics of 
conversation on oi-dev of late; decisions to for example change the shell or filesystem 
layout can have broad ramifications.  While a distro can choose to do as it wants, if 
there is that much difference between the base and the distro, then it will be much 
harder for the base developers to continue to use the distro as a reference.)


The relationship has been entirely symbiotic and I don't think we've 
really had that many disagreements, perhaps only some tension at the 
beginning. OI was always understaffed and it took a lot of time and 
effort for the volunteers to get up to speed on how everything worked.


A lot of the talk you've seen on the oi-dev mailing list regarding 
changing the default shell, splitting off /usr or switching to Schillix 
is coming from the peanut gallery of people who like to provide their 
opinions on things but who have never actually contributed to the project.


We have no intention of moving away from illumos-gate nor making any 
major changes. I also want to RTI all the non-branding related changes 
in our illumos-gate fork - we only maintain it because none of us have 
had time to RTI stuff.


Cheers,

Alasdair

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

Re: [oi-dev] is there a vector for donating to OI?

[Alasdair Lumsden]

On 06/09/2012 20:27, Ken Gunderson wrote:

As for Alasdair having resigned as project lead, I would politely ask
  if we could prevail upon him to re-don his lead hat for this one last
  action.  Why?  In short; I feel he, likely more than anyone, has the
  community's trust.


Hi Ken,

Sure I don't mind providing some input on this...

I think OI is a member of the illumos family and I'd be more than happy 
for the illumos foundation to take donations on our behalf, as long as 
it's earmarked for OI use specifically. If someone wants to donate to OI 
rather than illumos, it makes sense for it to be ringfenced. (Otherwise 
they'd just donate to illumos).


It may be worth illumos setting up some kind of method of taking 
donations via something like PayPal. The illumos website could let 
people donate to illumos, and the OpenIndiana website could let people 
donate to OpenIndiana (but via the same facility), with some way of 
differentiating between the payments so they can be earmarked for 
illumos-general or OpenIndiana (or other projects that live within the 
illumosphere).


Does that make sense? Or is that too complicated?

I also am happy for it to take a cut of the donations for administrative 
overheads, as long as it's not too excessive. Obviously there is work 
involved in maintaining the foundation.


Cheers,

Alasdair

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

Re: [oi-dev] Please comment #2314 isc-dhcp

[Alasdair Lumsden]

Hi Gary,

I have pushed this now:

https://hg.openindiana.org/oi-build/rev/064bc3aa72d4

Many thanks for your contribution!

Cheers,

Alasdair

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

Re: [oi-dev] [userland] 3079 add libssh2 into illumos-userland

[Alasdair Lumsden]

Hi Adam,

That's now committed:

https://hg.openindiana.org/oi-build/rev/2d33e1c69966

Cheers,

Alasdair

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

Re: [oi-dev] Please comment #2314 isc-dhcp

[Alasdair Lumsden]

Hi Gary,

On 09/09/2012 23:02, Gary Gendel wrote:

Alasdair,

It was my understanding that these are the bookkeeping database files
that are created by the server. As such, they do not need to
be installed. If I am mistaken then we should put them back.


I think they're pre-created so that the files have the correct 
permissions. Probably better to leave them in.


Rather than do another changeset to bit bucket, I can make the change 
for you and push what you've done so far, which I'll do now for you.


Cheers,

Alasdair


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

[oi-dev] Post 151 development

[Alasdair Lumsden]

Hi All,

I'd like to raise the topic of post-151 development.

Jon (Tibble/Meths) - obviously you've been doing great work on the 
prestable builds. I think I asked when we should ship to /stable, and 
basically I got the impression you weren't comfortable doing that until 
we had most of the CVEs fixed and could support it from a security 
standpoint.


I don't think that's realistic right now, as CVEs are coming out faster 
than we can fix them.


So as such, I'd like to propose that one of the next prestables be a 
candidate for being shipped to "/release", rather than "/stable" and the 
notion of /stable be abandoned for now.


We could do something like aim to push a /release every 6 to 12 months, 
and we can aim to backport critical bug and security fixes to it from 
/dev. But it will give users a bit of stability and free us up to move 
/dev forward faster.


That fits in with OpenSolaris, where /release wasn't guaranteed free of 
security holes (you had to pay for that). Obviously we can still ship 
CVE and bug fixes to it, but it sets realistic expectations and 
hopefully addresses your concern with using the name "/stable"


The goal with the above proposal is that once users have /release, we 
can push forward with /dev and moving things from SFW/JDS/etc over to 
the small oi-build that prestable currently builds from.


The work I was doing on /experimental was idealistic, and because Jon 
kept updating /dev faster than I could keep up with it, /experimental 
was pretty much constantly broken and not fit for purpose. It was a 
giant leap too far, and unworkable.


If we push /release, then we can recommend users who want stability 
switch to it, and we could, for example, aim at shipping /dev releases 
every 4 to 6 weeks, as Jon has already been doing with the prestables.


Just to avoid any confusion, the /experimental repo I created was based 
on the latest prestable at the time I generated it, plus an overlay of a 
complete build of https://hg.openindiana.org/oi-build.


What I'm proposing is instead that we base future /dev releases on this:

https://hg.openindiana.org/sustaining/oi_151a/

where we slowly move things from the legacy consolidations, over to the 
skeleton oi-build you can see here:


https://hg.openindiana.org/sustaining/oi_151a/oi-build/

Obviously we can source recipes from userland-gate and illumos-userland.

Why do it this way? Because it lets us take baby steps, push out regular 
releases, and generate ISO images. It's not a big giant leap, and to a 
large extent it's something Jon Tibble has kind of already been doing it.


Jon, what do you think of this idea? Is it workable?

Thanks,

Alasdair

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

Re: [oi-dev] [userland] 3079 add libssh2 into illumos-userland

[Alasdair Lumsden]

On 09/09/2012 22:12, Adam Števko wrote:

Bump, anyone else?


LGTM!

I'll ship it to oi-build shortly.

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

Re: [oi-dev] Please comment #2314 isc-dhcp

[Alasdair Lumsden]

On 04/09/2012 23:45, g...@genashor.com wrote:

I've cleaned up and updated isc-dhcp to 4.2.4-R1. This already has the
updates provided by Oracle so I removed the patches which are not
required. I also removed duplicate items in the p5m file and fixed the
Makefile so the BIND sub-module gets built correctly. This is my first
foray into helping with oi userland so be critical so I can grow as a
contributor. Thanks.

My clone is at https://bitbucket.org/ggendel/oi-build


Hi Gary,

Thanks for contributing this - I see you also updated the 
copyright/license notice as per Adam's comments - thanks for doing that.


Just one last thing - you removed dhcpd4.leases~, dhcpd6.leases and 
dhcpd6.leases~ - could you talk me through this change?


Cheers,

Alasdair

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

Re: [oi-dev] Desktop Illumos Still Matters

[Alasdair Lumsden]

On 05/09/2012 21:58, Joerg Schilling wrote:

Alasdair Lumsden  wrote:
It seems that you missunderstand the problem.

The main issue is that the build system linked against /usr instead of linking
against something like: /home/user/proto/usr


userland-gate still links against /usr - it has a per-package proto area 
rather than a build-system wide proto area.



-   It may be that you would need to manually install at least older
versions of strategic tools before you may start to compile at all.
The programs in question are gmake, bash, gm4, ...


That is not an issue with userland-gate or oi-build. You do have to
install gmake, bash and a bunch of dependencies, but they're all
available in the package repo.


It is not a real issue with SchilliX either but for a looking at a
self-contained system it would.


-   It installs unmodified autoconf results in /usr/include with the
effect that you cannot compile depending other software using
an older version of the compilers than the one you used to compile
sfw.


Can you supply an example? I'm not sure I understand this complaint.


Check e.g. the notes about sfw in:

ftp://ftp.berlios.de/pub/schillix/AN-0.8


"You need to comment out line 71 of the file 
/usr/include/net-snmp/net-snmp-config.h

do that it then looks this way:

/*#define HAVE_CPP_UNDERBAR_FUNCTION_DEFINED 1*/

This is needed as the sunstudio-12 compiler and gcc-3.4.3 do not support 
__FUNCTION__"


That's an autoconf problem, not a problem with the build system. If you 
build software with a new compiler, autoconf will detect its new features.


To work around it, the net-snmp build recipe can modify the generated 
header prior to packaging it.


However, typically a distribution will ship with a particular supported 
compiler version, and the headers of the software on the system will 
match that version. It is unreasonable to expect an older compiler to 
link against all software delivered by the system when the system uses a 
newer compiler.




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

Re: [oi-dev] Desktop Illumos Still Matters

[Alasdair Lumsden]

On 05/09/2012 21:36, Andrew Stormont wrote:

These sorts of scripts are just broken.  What it really should do is check the 
value of CC before adding any compiler specific flags.  Patching it to do that 
would be my preferred way of solving the problem.


That works too.

The thing is they're pretty dumb in operation - they pick up the 
compiler environment, which in the case of mysql was optimised for the 
database server. Client libraries really won't benefit from the 
optimisations.


We could store the Sun Studio optimisations, and expose them with CC is 
detected as Studio, but gcc users miss out on them. So for equality it 
seems easier just to strip them.


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

Re: [oi-dev] Desktop Illumos Still Matters

[Alasdair Lumsden]

On 05/09/2012 21:22, Bob Friesenhahn wrote:

What do you suggest as a better replacement for this?


Oh it's easy - you strip most of them out after the file is generated. 
Very easy to do with a post-install sed rule in the build recipe.


The bulk of them are pointless optimisations that aren't really relevant 
when compiling an extension. The main LDFLAGS to preserve are -L/-R and 
-l, and for CFLAGS its -D and -I.


As an example, mysql_config spits out this for CFLAGS:

-I/usr/mysql/5.1/include/mysql  -xprefetch=auto -xprefetch_level=3 -mt 
-fns=no -fsimple=1 -xbuiltin=%all -xlibmil -xlibmopt -xnorunpath 
-DHAVE_RWLOCK_T -DUNIV_SOLARIS


The only thing you really need for extensions to build is the -I bit. 
The rest is Sun Studio pedantry.


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

Re: [oi-dev] Desktop Illumos Still Matters

[Alasdair Lumsden]

On 05/09/2012 21:12, Alan Coopersmith wrote:

Correct.  Userland was designed from the ground up for IPS, since that was the
only packaging system in use when it was created.


Nexenta enhanced their fork of userland to support generating .deb 
packages, so adding SVR4 probably wouldn't be too hard.


Why you'd want to is another matter.


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

Re: [oi-dev] Desktop Illumos Still Matters

[Alasdair Lumsden]

On 05/09/2012 19:49, Joerg Schilling wrote:

The buildsystem for sfw is a nightmare:

-   It only works if the whole set of tools has already been
installed in /usr on the compiling system before with exactly
the same version as the one that is going to be compiled.

This causes that you need an unknown number of iteration to
compile and install on the build machine before you are able
to compile everything at all.

You need at least one additional install/compile cycle before you
can be sure that the compile/link results will no longer change.


It sounds like what you want is a completely self contained build 
system, like pkgsrc, which bootstraps itself, requires only a compiler, 
knows how to build things in the correct order, and installs everything 
to a custom destination prefix.


That approach is fine for building 3rd party software, but not for 
maintaining system software which ships to /usr.


Why? Because even in a minimal zone, bootstrapping involves overwriting 
things in /usr that are already maintained by the packaging system. You 
could build software and upgrade to those packages as you go, but that's 
very hard to do especially when refactoring packages.


If you instead tried to install everything to a custom destination 
prefix, you couldn't then just package it up and install it to /usr, 
because lots of software embeds their build prefix in the binary. If you 
built stuff with /foo as your prefix, then packaged it and delivered it 
to /usr, /usr/bin/someprogram would be looking for 
/foo/etc/someconfigfile.conf


It's far easier just to use a build zone and install the dependencies 
you need, and ensure your build zone is running the latest bits from the 
package repository.



-   It may be that you would need to manually install at least older
versions of strategic tools before you may start to compile at all.
The programs in question are gmake, bash, gm4, ...


That is not an issue with userland-gate or oi-build. You do have to 
install gmake, bash and a bunch of dependencies, but they're all 
available in the package repo.



-   It installs unmodified autoconf results in /usr/include with the
effect that you cannot compile depending other software using
an older version of the compilers than the one you used to compile
sfw.


Can you supply an example? I'm not sure I understand this complaint.

I do find it highly annoying that a lot of software jots down the 
compiler flags it was built with and stores them in a 
[softwarename]_config file, such as mysql_config, which is used by 
extensions to get the CFLAGS/LDFLAGS/etc. On OSOL/OI these are often Sun 
Studio flags that aren't compatible with gcc.


You then end up in a situation where if you're doing "gem install 
somelibrary" or "pecl install somelibrary" with gcc as your compiler, it 
chokes when linking against a system program that supplies Sun Studio 
CFLAGS/LDFLAGS.


SFW was a nightmare for many reasons, but not the reasons you listed.

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

Re: [oi-dev] Desktop Illumos Still Matters

[Alasdair Lumsden]

Hi Nick,

On 05/09/2012 18:49, Nick Zivkovic wrote:

Someone thought it would be a good idea to have a unified build system
across consolidations.

I think it's a pretty good idea to standardize on one build system.

I'm merely asking which one would be preferred by the community
(assuming the community would be willing to standardize).


The decision was already made by the core OI devs to use the 
userland-gate format. That's the future unified build system. So the 
choice doesn't really have to be made again - it's why "oi-build" is in 
userland-gate format.


Cheers,

Alasdair

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

Re: [oi-dev] Desktop Illumos Still Matters

[Alasdair Lumsden]

I've actually realised it would be really useful if there was a single 
document explaining all this stuff, a kind of "In the beginning there 
was..." style walk through of how things came to be.


I'll try to write one over the next few weeks and put it on the wiki, as 
it would probably help new developers get their head around things.


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

Re: [oi-dev] Desktop Illumos Still Matters

[Alasdair Lumsden]

Hi All,

On 04/09/2012 22:42, mag...@yonderway.com wrote:

On Tue, 4 Sep 2012 13:25:39 -0500, "Andrew M. Hettinger"
 wrote:


One of the biggest issues here isn't that packages are particularly HARD
to
make with IPS (they aren't). It's that there are about three different
approaches to it, and we need to get that standardized. Many of the
packages are tied up in the consolidations, which DO seem to have a high
barrier to entry.


So what are the cliff's notes to the three different approaches, and is one
of those approaches going to have a lower barrier to entry with still
high-quality results?  I'm thinking along the lines of a third party repo.


I think there's a bit of confusion surrounding the terms involved.

A consolidation is just a logical grouping of packages, such as "JDS" 
(Java Desktop System, renamed to just "desktop" on Solaris 11), "SFW" 
(Sun Freeware, replaced with "userland" in Solaris 11), etc.


The big issue is that all the consolidations use different build 
systems. JDS uses RPM style spec-files similar to SFE (Spec files extra, 
a collection of 3rd party package recipes). SFW used a horrible Makefile 
based system. Userland is an excellent replacement for SFW, and uses 
Makefiles but in a way very similar to the FreeBSD ports tree or pkgsrc.


I was attempting (with some others) to get OI updated in a "giant leap 
forward" replacing SFW with userland-gate (renamed to oi-build, and 
later illumos-userland after Nexenta started meddling). The idea was 
that we would try to focus on one single build system, the userland-gate 
style, which is the best of the lot. New software would go in there, and 
if we needed to update something in another consolidation, we would 
instead re-implement the recipe for it in userland-gate format.


Unfortunately my approach with /experimental was quite ambitious and 
didn't quite work how we wanted.


Jon Tibble is continuing to release new OpenIndiana builds (such as 
prestable 6, released *today* - 
http://wiki.openindiana.org/oi/oi_151a_prestable6+Release+Notes) and is 
advocating we do move to a single build system based on userland-gate, 
but more slowly and in a more controlled fashion.


oi_151a actually already has a mini userland-gate/oi-build, which you 
can see here:


https://hg.openindiana.org/sustaining/oi_151a/oi-build/

It's used to deliver some additional software and some bits from other 
consolidations have been moved there.


It is probably where people should focus their efforts moving forward.

Incorporations are probably what people are bitching about, which are 
there to provide "lockstep" upgrades between known working version sets 
of software. "entire" is the best known incorporation, which with each 
release locks all system software at a particular version.


Incorporations are needed to prevent your system getting shafted. Lets 
say you are on oi_148, and in oi_151a we introduced some new software 
called "foo". Foo depends on version 2.0 of "bar". oi_148 delivers "bar" 
version 1.0. Without incorporations, if you "pkg install foo" it will 
upgrade "bar" no questions asked. Any software linked against bar 
probably just stopped working with libbar.so.1 changed to libbar.so.2.


Incorporations present a challenge when you're developing software, 
because they stop you installing new versions of things. The way to get 
around this is to have "empty" incorporations on your development 
system, that way you are free to shaft your own install if you want to. 
It's like taking your seatbelt off.


Incorporations map to consolidations, so SFW, JDS, etc each have their 
own incorporation. This means the incorporations have to be updated when 
you move software from one consolidation to another, eg from JDS to 
oi-build.


Hope this makes sense.

Alasdair

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

Re: [oi-dev] Resignation as OI Lead

[Alasdair Lumsden]

Hi Milan,

On 30/08/2012 08:46, Milan Jurik wrote:

Hi,

it is not good you resign. And it is not good to see OI going nowhere.
Here I had long e-mail about how stupid is to think OI is threat to
Nexenta (Oracle way of thinking), how irrelevant is what Bryan Cantrill
says, how stupid is to give up developer desktops etc. But nobody would
read it and it is not important now.


I'm sorry for resigning, but I was sacrificing considerable amounts of 
personal time and energy to the project. It couldn't continue indefinitely.


I was hoping that we could set up a framework for others to contribute 
and carry things forward, but there was just too much baggage to deal 
with. OmniOS's approach of starting from scratch was the easy way out, 
something we couldn't do.


I'd say illumos-userland was the final straw. It took the wind out my 
sails, especially with the "working set" farce where Bayard absorbed 
everyone's changesets then disappeared. The whole illumos-userland thing 
kind of pissed everyone off



More important is - what is immediate impact of your resignation? Is it
end of OI?


It is not the end of OI, as long as others want OI to continue and can, 
for example, help Jon Tibble with his efforts, something I may do if I 
can find time.


But I was unable to muster the time/energy to lead the project, so 
continuing as lead was leading the project no-where. I had to resign to 
make way for someone else - I hope someone will step forward, or that 
the project will continue without a leader.



 From my point currently Jon is moving /dev slowly forward - is he
willing to continue in it with help from few remaining people?


I hope so.


oi-experimental is dead end, so is illumos-userland. Good thing. It was
big switch breaking things and wasting resources.


Well, it wasn't that big a switch - Solaris 11 has userland-gate, and it 
was just that. Andrzej Szeszo has the latest JDS built along with the 
latest userland-gate running on his desktop PC at home. He managed to 
get it all built and working. It was unfortunate he was unable/willing 
to upstream his work. It was possible, though, Andrzej's work proves 
this. We just needed talented, committed developers with time and energy.



oi-build is slowly taking attention as much better way in our current
situation.

There is question about prestable, if it should stay as prestable or we
can accept it as moving dev (as it is now in reality). Would automated
release every 2 weeks help? Yes, some releases can be broken but we have
BEs and people will be forced to fix things or leave.


I don't know. Jon's reservation about releasing his prestable builds as 
stable was that there was still loads of CVEs in it.


Automated releases would improve things but there would be a lot to 
automate.


I feel oi-build as a framework is the future, but we tried to jump to it 
too quickly. An incremental approach based around Jon Tibble's work, 
where packages are moved one by one from SFE/JDS/etc into oi-build would 
fix that.


There are however some big challenges. We no longer have the in-house 
skills to rebuild JDS. With your work on SFE and expertise with 
spec-files, perhaps that is something you could help with?



Currently I fixed the most of things around OI SFE so I can move my
attention back to illumos and OI after my vacation the next week. With
small change, from July I switched my position in company and my spare
time is very limited. But long winter nights are comming :-)


I think OI would greatly benefit from your input Milan and I'm pleased 
you're considering helping it.



Best regards

from mad man who is using OI as his primary desktop at home


You're not alone :-)

Alasdair

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

[oi-dev] Resignation as OI Lead

[Alasdair Lumsden]

Dear OI Developers,

It is with much sadness that I hereby resign as project lead. I may, if 
the situation improves under a new project lead, stick around to offer 
my opinion or occasional assistance, but my resignation is final; I have 
no wish to return to the project in a leadership capacity.


My resignation is primarily driven by a lack of time; I simply cannot 
commit the hours necessary to maintain a project of this size. I have my 
life, my health (primarily mental), and my future to think of.


But it is also in part due to frustrations with the difficulty of making 
any progress on the project. OpenSolaris was maintained by a large 
corporate entity. We however, are volunteers, contributing our personal 
time to work on a project we believed in. For many of us this was the 
first open source project we had ever contributed to, myself included. 
The task at hand was vast, and we were ill equipped to deal with it.


But what really, right from the very beginning, upset me, was the lack 
of interest from the large commercial players benefiting from Illumos, 
and from those who had been paid to work on Solaris at Sun. Instead, 
what we got, was grief regarding the name (Project Indiana seemingly 
being a sore point for Solaris engineers, something I was completely 
unaware of when we chose "OpenIndiana"), hostility towards IPS, and a 
total lack of interest, encouragement or friendship from people many of 
us looked up to when we were mere end-users of Solaris under Sun.


Right from the very beginning, Illumos was on life-support. I have no 
doubt that Nexenta, Delphix, and Joyent in particular will continue to 
innovate and that SmartOS will be a success, but support for Solaris 
from the open-source software community has over the past 2 years gone 
from bad to worse. Only the other day the MongoDB developers responding 
to an issue with it segfaulting on OI stated "OI isn't supported, use 
Linux":


https://groups.google.com/forum/?fromgroups=#!topic/mongodb-user/45C7M_po1No

I lay the blame of this squarely on the lack of a successful general 
purpose distribution of Solaris/Illumos. OpenIndiana was my attempt at 
competing with the Linux distros, but our lack of progress has torpedoed 
it. Nobody in their right mind would use OI - it ships severely out of 
date insecure software, lacks some of the most common 3rd party apps 
such as LibreOffice, and so much simple shit that should just work, such 
as "pecl install", "gem install", "pip install" or whatever barfs due to 
nonsense SunStudio flags, to the point you need a background in computer 
science and compiler flags to get it to work. Not fit for purpose.


So what exactly are 3rd party software developers such as the FFMpeg or 
MongoDB developers supposed to use to develop and test their software 
on? Buy a SmartDatacenter? Install a storage product? Run it on a 
database appliance?


All of you, Joyent, Nexenta, Delphix, are complicit in the increasing 
irrelevance of Illumos. OI, even in it's current current state, is by 
far the most widely used Illumos distro, so by not supporting it beyond 
contributing to the Illumos core, you've all shot yourselves in the 
foot. With a fucking shotgun. What's sad is that you don't even see it.


It didn't have to be this way. With some assistance we could have made 
large strides forward - we had lots of solid ideas of how to get things 
moving. What we lacked was time, graft, and expertise from those who 
worked on this professionally - items easily supplied by those with deep 
pockets and plenty to gain from our success.


Instead we got the Illumian farce from Nexenta, along with their senior 
staff claiming OI is an existential threat to their continued existence. 
And when I asked for help back in November, we got Bryan Cantrill 
telling us all "when you want to do something, just do it" - rich coming 
from someone paid to work on all this whilst the OI devs volunteer their 
personal time, often at considerable personal sacrifice, to work on this 
stuff.


With the ZFSOnLinux port becoming increasingly popular (so many of the 
Linux users I know are using it), and 
brtfs/dtrace-on-linux/upstart/whatever else slowly brewing away, even 
some of the core features of Illumos are becoming less and less 
important. Yes, the Linux equivalents suck in one way or another, some 
are completely and fundamentally broken by design, but it doesn't matter 
- what matters is perception and the typical Linux user is happy with 
"good enough". When I encourage my Linux-using friends to try OI they 
laugh in my face. OI and Illumos to them is a dead platform. Add to that 
our increasingly out of date and poor hardware support due to the march 
of never ending new LAN/SATA/SAS/motherboard/GPU chipsets and you start 
to get the picture.


I hope, I really do hope, that Illumos does not become entirely 
irrelevant. But when less and less software works out of the box, and 
when heavily used products such as MongoD

Re: [oi-dev] Addition of GeoIP to oi-build

[Alasdair Lumsden]

So,

64bit builds seem to be a bit broken with the default behaviour. It's 
fixed by my 2682 changeset:


https://bitbucket.org/alasdairlumsden/illumos-userland-2682/compare/..illumos/illumos-userland

I'll put a workaround in the GeoIP build for now which can be backed out 
once 2682 goes in.


Cheers,

Alasdair

On 23/12/2011 16:44, Игорь Пашев wrote:

BTW:
in make-rules/shared-macros.mk :
CC.gcc.32 =$(GCC_ROOT)/bin/gcc -m32
CXX.gcc.32 =$(GCC_ROOT)/bin/g++ -m32
CC.gcc.64 =$(GCC_ROOT)/bin/gcc -m64
CXX.gcc.64 =$(GCC_ROOT)/bin/g++ -m64
CC =$(CC.$(COMPILER).$(BITS))


2011/12/23 Jeppe Toustrup mailto:openindi...@tenzer.dk>>

On Thu, Dec 22, 2011 at 16:24, Игорь Пашев mailto:pashev.i...@gmail.com>> wrote:
 > include ../../make-rules/shared-macros.mk 
 >
 > COMPONENT_NAME = GeoIP
 > COMPONENT_VERSION  = 1.4.7
 > COMPONENT_SRC  = $(COMPONENT_NAME)-$(COMPONENT_VERSION)
 > COMPONENT_PROJECT_URL  = http://www.maxmind.com
 > COMPONENT_ARCHIVE  = $(COMPONENT_SRC).tar.gz
 > COMPONENT_ARCHIVE_HASH =
sha1:2db3a61e19dfaa0e4131217b155a59ba4bd0c5cc
 > COMPONENT_ARCHIVE_URL  =
 > http://geolite.maxmind.com/download/geoip/api/c/$(COMPONENT_ARCHIVE)
 >
 > include $(WS_TOP)/make-rules/prep.mk 
 > include $(WS_TOP)/make-rules/configure.mk 
 > include $(WS_TOP)/make-rules/ips.mk 
 >
 >
 > build: $(BUILD_32_and_64)
 >
 > test: $(TEST_32_and_64)
 >
 > install: $(INSTALL_32_and_64)
 >
 > BUILD_PKG_DEPENDENCIES = $(BUILD_TOOLS)
 >
 > include $(WS_TOP)/make-rules/depend.mk 

I just tried that Makefile with a few changes:
- Changed version to 1.4.8.
- Updated SHA1 hash for tar ball.
- Set the compiler to GCC.

And this results in libraries in both the /usr/lib and /usr/lib/amd64
folder, however, both sets of files are 32-bit according to "file".

I'll have to look closer into this, but I'm not sure it will be on
this side of the holidays.

--
Venlig hilsen / Kind regards
Jeppe Toustrup (aka. Tenzer)

___
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] 2483 Bring libcaca into illumos-userland from s10-userland

[Alasdair Lumsden]

Hi All,

I have committed libcaca to oi-build.

Cheers,

Alasdair

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

Re: [oi-dev] SVR4-based illumos distro WAS: how to fix support for system_locale in sysidcfg for non global zone installation

[Alasdair Lumsden]

(Moving this to oi-dev)

On 27/05/2012 16:47, Jim Klimov wrote:

2012-05-27 4:15, Alasdair Lumsden wrote:

As project lead I can tell you that we won't be doing SPARC
unless someone comes along and takes ownership of that project,
and we definitely won't ever be doing SVR4 packaging as long
as I'm project lead.


"No Bart, you cannot have the cookie now after all.
Your mother made a very loud point!" (C) The Simpsons


Sorry :-) I subscribe very strongly to the design principles of IPS 
which came about due to shortcomings in SVR4. IPS may have some 
implementation weaknesses, but it admirably solves the problems it set 
out to and in my experience works very well indeed.


When people pine for the days of SVR4 I just get annoyed, because it's 
trying to undo progress. Yes, IPS requires retooling and relearning, but 
ultimately IMHO it's very worth it.


There are a number of blog posts on this topic by Stephen Hahn:

https://blogs.oracle.com/sch/entry/observations_on_packaging

(Click next through the blog posts as there's quite a few)


I think, supporting the minimal-interruption *migration*
from legacy (SVR4) systems would be more important to me
than an SVR4-based distro, especially if that option is
so firmly fought against.

However, comfortable migration "should" support running
legacy local (fullroot) zone roots provided as-is (i.e.
without IPS packaging), even if not directly supporting
installation of such (SVR4) zones with OI.

Do you loudly object even to that?


No, and if a sound implementation was presented for us to integrate I'm 
sure we would.


However as unpaid volunteers working on a community project we need to 
stay focused on what's important, and right now that's things like:


1. Getting our /stable release out
2. Sorting out /experimental and our release engineering processes
3. Updating software, fixing security holes, fixing bugs



Then to clarify:

1) SVR4 support: as I see - at the moment SVR4 are installable
on OpenIndiana "as is", including the pre/post-scripts, which
is good for those legacy users who can't/won't migrate for
whatever their reasoning is. Is this going to remain in place,
or are there plans to rip out pkgadd,etc. and still claim
being "the upgrade path"? ;)


There are no plans to rip it out.


One limitation that I see however, is that an SVR4 package
installed in GZ does not get auto-installed/updated in LZ...
Oh well, that's likely an IPS brand thing...


That's by design. SVR4 package installation is there as a compatibility 
thing and not for general systems management. IPS branded zones are 
effectively isolated containers with their own private package sets. A 
fresh zone gets a minimal set of software.



2) Is there a documented and/or scripted upgrade path for
users of SVR4-based systems to export-import their zones
into an IPS system (i.e. use same-named SUNW* package names
if available via IPS and update them from an old SXCE/Sol10
image to the current OI baseline upon zone import)?
Something simple, working in-place on (a clone of) the old
zone dataset, and that would not require reinstalling the
whole set of zones and manually migrating the settings, data,
installed third-party programs (packaged or standalone)?


That would be a huge amount of work. Things have changed so very much 
since Sol10 and SXCE that there is no 1:1 direct mapping any more and 
most software would just break horribly.


There are however Solaris 10 branded zones. Potentially that brand could 
be adapted to SXCE. The problem is that SXCE was a moving target with 
lots of builds.



To the very least, it would suffice if the SXCE zones just
worked "as is" in OpenIndiana, allowing for quick upgrades
of the host OS and little downtime for tasks-in-zones being
upgraded later - alas, they don't, even after some hammering.


Again, you want an SXCE implementation of Solaris 10 branded zones.

The main problem is that the core system software (like the ifconfig, 
zfs, etc) commands inside the zones have to be kept in sync with the 
global zone. I am not sure how the S10 brand achieves this.


But once it's done you're left with this aging security nightmare 
frankenstein of a zone, so why bother?


People are better off investing the time in properly migrating their 
legacy apps and data into modern zones. That way you get the latest 
software with the latest security updates, in a far more supported fashion.


I appeal to your logical side.


3) Regarding sparse-root zones: does the IPS theory firmly
forbid the sparse-root zones with their benefits of faster
provisioning, smaller footprint on disk/RAM/cache, fast
propagation of OS-wide updates, and whatever else people
liked about them? Or is it possible to tame IPS code into
compatibility with the concept of sparse read-only rootfs
(/usr, /lib...)?


As far as I know sparse zones support wa

Re: [oi-dev] [developer] how to fix support for system_locale in sysidcfg for non global zone installation

[Alasdair Lumsden]

On 26 May 2012, at 17:46, Garrett D'Amore wrote:

> sysidtool (where this lives) is not part of illumos-gate.  Its a part of 
> OpenIndiana.  I'm having trouble locating the sources they used for this.  
> I'm not entirely certain the source for it *is* open.  Evidently it was part 
> of the installer and was never opened up.  I'm a little dismayed about this 
> -- I never realized this to be the case, although admittedly there are 
> distributions which make no use of sysidtool at all.

I'm not sure where the sysidcfg code lives (Will have to have a rummage) but 
I've never liked the way any of it works and I'm sure I'm not alone.

We (OpenIndiana) may want to adopt the approach OmniOS took which is to get rid 
of it and use something much simpler. If the OmniOS approach is sufficiently 
good enough for most people then we could just import it. I imagine adding 
compatibility with the sysidcfg file would be pretty trivial if anyone really 
cared about it.

Alasdair



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

[oi-dev] 2682 Supply CC, CXX, CFLAGS, LDFLAGS etc to CONFIGURE_ENV by default

[Alasdair Lumsden]

Hi All,

I have a rather large changeset for review:

https://bitbucket.org/alasdairlumsden/illumos-userland-2682/compare/..illumos/illumos-userland

This abstracts a large amount of unnecessary common autoconf code out. The key 
files are make-rules/configure.mk and make-rules/shared-macros.mk

I have also updated the CDDL header for each file I've changed as well as 
updated the digest from sha1 to sha256 (which userland-gate are doing).

Cheers,

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

[oi-dev] Fwd: [userland] hackathon info

[Alasdair Lumsden]

FYI - location info for the hackathon.

Begin forwarded message:

> From: Bayard Bell 
> Date: 21 May 2012 15:12:13 CEST
> To: userl...@lists.illumos.org
> Subject: [userland] hackathon info
> Reply-To: userl...@lists.illumos.org
> 
> The hackathon will take place May 23rd at Middenweg 33, flat 3:
> 
> http://g.co/maps/by6q3
> 
> If you're feeling energetic, we'll also be there May 24th. The nearest
> rail station in Amstel (this would be quite a walk from Amsterdam
> Centraal), which should be a 15 minute walk. The nearest landmark is
> Oosterpark, which is less than five minutes away. It's slightly more
> difficult getting from the flat to the conference hotel because you
> have to thread through bridges to get there, make it a longer trip
> than as the crow flies.
> 
> If you want to get rail routes from Schiphol airport (there's a train
> station underneath the airport's massive central lobby), please see
> the Dutch national rail company (Nederlandse Spoorweg) site:
> 
> http://www.ns.nl/en/travellers/home
> 
> If you haven't already, please e-mail me with your mobile number (even
> if I have/should have it from exchanges previous to the conference, it
> would be helpful if I didn't have to dig it up), and I'll put together
> a phone directory for everyone who's attending.
> 
> Cheers,
> Bayard
> 
> 
> ---
> illumos-userland
> Archives: https://www.listbox.com/member/archive/191052/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/191052/22216987-e95844d6
> Modify Your Subscription: 
> https://www.listbox.com/member/?member_id=22216987&id_secret=22216987-664aa7bb
> Powered by Listbox: http://www.listbox.com


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

Re: [oi-dev] Assorted recipes

[Alasdair Lumsden]

Hi Jeff,

On 10 May 2012, at 04:46, Josef 'Jeff' Sipek wrote:

> I've been a bit too lazy about this, so at least I'll let you guys know
> about a couple of things I've done for my test repo.  Feel free to take them
> and get them integrated:

Great! Thanks for posting these... Having a starting point reduces the amount 
of effort involved significantly. If nobody picks these up I'll definitely get 
them polished off and put up for final review.

If people are busy and don't have time to do the polishing/integration 
themselves then this is definitely the next best thing and I'd love to see more 
of these. A work in progress is a million times better than nothing at all.

> postfix (missing SMF manifest):
>   http://hg.31bits.net/oi-jeffpc/oi-build/rev/d27273c8771f
> 
> notion window manager [1]:
>   http://hg.31bits.net/oi-jeffpc/oi-build/rev/961d976c440e
>   http://hg.31bits.net/oi-jeffpc/oi-build/rev/793871cc2fa9
> 
> irssi's path fix:
>   http://hg.31bits.net/oi-jeffpc/oi-build/rev/78657b9613fe
>   (pretty sure that the i86pc-solaris-64int is wrong too since the
>   Makefile only builds a 32-bit binary)
> 
> fix lua build (without this, the lua build won't know how to do popen and
> other POSIX-y stuff):
>   http://hg.31bits.net/oi-jeffpc/oi-build/rev/9b3ec2748616
> 
> I've been using these for a couple of months and things seem to work pretty
> well.

Cool stuff!


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

Re: [oi-dev] Downloading archives to a common area

[Alasdair Lumsden]

On 10 May 2012, at 00:42, Bayard Bell wrote:

> I think this is better than setting ARCHIVE_MIRROR, which may be
> useful for other purposes--it's even more handy for managing our
> source archive if you can populate what's current with a global gmake
> download to one directory and then rsync that to dlc. As you say, with
> multiple workspaces, you can simply symlink this to a single copy of
> the archives, and with this done, you don't have to copy to pop into
> the workspace; you get archive dedup for free with nearly zero effort.

Yes indeedy - it's really helpful especially for bulk builds. You can also 
restore the old behaviour by setting USERLAND_ARCHIVES=./ (or possibly 
=$(COMPONENT_DIR)). And you can still make use of an alternative ARCHIVE_MIRROR.

It also looks like Oracle attempted to implement USERLAND_ARCHIVES originally 
but either didn't finish, or broke it later on when adding support for multiple 
archives in a component. So this is fixing a currently broken feature.

I'd like to write a continuous-integration rule for pushing valid archives 
(based on the digest) automagically up to the dlc mirror. I'll look into that 
soon.

> The only downside is that userland-fetch might blow away your only
> copy because of digest mismatches in the component Makefiles, so you
> probably want to use snapshots a bit more than you might have done.
> People like me doing development on laptop SSDs get a big win for the
> reduced storage overhead.


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

Re: [oi-dev] Downloading archives to a common area

[Alasdair Lumsden]

On 10 May 2012, at 01:41, Bayard Bell wrote:

> On Thu, May 10, 2012 at 1:20 AM, Gordon Ross  wrote:
>> On Wed, May 9, 2012 at 7:42 PM, Bayard Bell  
>> wrote:
 It also lets us add $(WS_TOP)/archives to .hgignore and no longer have to 
 put up with seeing downloaded archives in the "hg status" output.
 
 Before I begin work on this changeset for illumos-userland, does anyone 
 have any feedback?
>> 
>> I'd like to see some caution against blowing away archives in there,
>> if possible.
>> Otherwise sharing it gets quite difficult.
> 
> Yes. Can someone [else--it's not so hard, and I'm happy to help
> someone else through it, but I'm already a blocky resource] scope
> changes in userland-fetch?

I have created:

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

I may look at this once I've finished my higher priority changesets, unless 
someone else wants to take the issue before hand.
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [userland] illumos-userland hackathon May 22 in Amsterdam

[Alasdair Lumsden]

On 10 May 2012, at 21:05, Damian Wojsław wrote:
> http://www.meetup.com/illumos-User-Group/events/56953802/
> http://www.openstoragesummit.org/
> 
> THis is all I got. :)

Ditto! So I have some info:

1. The hackathon is on the 23rd of May, all day
2. It will be in an apartment instead of the hotel
3. I'll be staying in the apartment, there may be room for others if you notify 
buffyg now now now
4. I'm arriving on 22nd May and leaving 25th May, so staying 3 nights.

Hopefully see some of you there!

Cheers,

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

Re: [oi-dev] [userland] illumos-userland hackathon May 22 in Amsterdam

[Alasdair Lumsden]

Hi All,

I need to book flights for this as time is running out and I still don't 
really have enough information in order to choose dates and times - can 
someone please confirm:


1. What day the hackathon is on (22nd?)
2. What time of day the hackathon is (all day? just the evening?)
3. What accommodation has been booked and what days is it available on?

I can't easily choose what flights to get without the above information, 
and I need to know if I need to book a hotel room etc.


I am interested in us getting an apartment hotel with bedrooms and 
staying there, even if only on the floor in a sleeping bag. But I need 
to confirm I have *somewhere* to sleep :-)


Thanks,

Alasdair


On 05/05/2012 02:37, Bayard Bell wrote:

We're looking at a change of venue to include accommodation (i.e.
apartment with WiFi as place both to crash and to hack), courtesy of
Nexenta. If you're interested and particularly if you'd like
accommodation, please RSVP by private mail to me ASAP.

Cheers,
Bayard


---
illumos-userland
Archives: https://www.listbox.com/member/archive/191052/=now
RSS Feed: https://www.listbox.com/member/archive/rss/191052/22216987-e95844d6
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=22216987&id_secret=22216987-664aa7bb
Powered by Listbox: http://www.listbox.com



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

Re: [oi-dev] pkg.openindiana.org/experimental updated - now with gcc-44

[Alasdair Lumsden]

Hi Milan,

Urgh what a mess of output that is.

It comes down to the unfortunate fact that the work being done to /dev is 
conflicting with the work I'm doing on /experimental. Right now you're on 
0.151.1.4 which has newer versions of things like the nvidia package, so 
/experimental is no longer an "upgrade", it'd be a downgrade for some packages 
which pkg forbids.

I'm going to have to come up with a quick and easy way of overlaying 
illumos-userland on top of the latest release of /dev each time a new version 
of /dev comes out. Once /stable comes out this won't be a problem as things 
will logically fork.

I'm not entirely sure what's going on with gnome-incorporation there but it's 
pointless fixing that until /experimental is updated.

Unfortunately I won't be able to look at it today as I have to go out, but I've 
bumped this to the top of the priority list.

Cheers,

Alasdair


On 6 May 2012, at 08:20, Milan Jurik wrote:

> Hi,
> 
> slightly better:
> 
> http://www.opensolaris.cz/builds/new.pkg.log.txt
> 
> Best regards,
> 
> Milan
> 
> Alasdair Lumsden píše v so 05. 05. 2012 v 01:00 +0100:
>> Hi Milan,
>> 
>> Could you try now?
>> 
>> I haven't sucked in the new prestable version yet but I've resolved the 
>> conflicts, so it should install.
>> 
>> 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 mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] 2680 & 2681 - Juggling archive and source dir

[Alasdair Lumsden]

Hi All,

2680 Extract source archives to a subdirectory
2681 Downloading archives to a common area

I decided to do these two as a single changeset since they're intertwined.

https://bitbucket.org/alasdairlumsden/illumos-userland-2680/changeset/34c2dff6cc0d

Cheers,

Alasdair


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

[oi-dev] 2679 dcmtk package has wrong package fmri

[Alasdair Lumsden]

Hi All,

Changeset for review:

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

https://bitbucket.org/alasdairlumsden/illumos-userland-2679/changeset/d87c903444d1

Cheers,

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

Re: [oi-dev] Extracting archives to a source subdirectory

[Alasdair Lumsden]

Hi Sriram,

On 5 May 2012, at 17:53, Sriram Narayanan wrote:
> Assuming a spec file based approach, wouldn't the SOURCES folder
> already take care of this ?

illumos-userland is more like pkgsrc/FreeBSD ports tree in its 
layout/structure. It doesn't follow spec file conventions.

Cheers,

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

Re: [oi-dev] [userland] Re: Downloading archives to a common area

[Alasdair Lumsden]

On 5 May 2012, at 17:41, Andrew Stormont wrote:

> I think this is a great idea.

Great - thanks for the feedback! Glad I'm not the only one that thinks it would 
be useful.

I'll get on with a changeset that people can test.

Cheers,

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

[oi-dev] Extracting archives to a source subdirectory

[Alasdair Lumsden]

Hi All,

Another improvement we integrated into s10-userland was to extract component 
tarballs into a subdirectory of the component directory. We used:

$(COMPONENT_DIR)/source

We did this primarily so it could be added to .hgignore, as "hg status" on a 
tree with all the components downloaded, extracted and built would take a very, 
very long time as hg traverses all the extracted directories. It's also a bit 
tidier.

It was fairly easy to do this:

SOURCE_DIR =$(COMPONENT_DIR)/$(COMPONENT_SRC)
->
SOURCE_DIR =$(COMPONENT_DIR)/source/$(COMPONENT_SRC)

Cheers,

Alasdair


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

[oi-dev] Downloading archives to a common area

[Alasdair Lumsden]

Hi All,

One improvement we added to s10-userland, was to download archives to a single 
top level archives directory instead of into the component directory.

We used:

$(WS_TOP)/archives

We did this by defining "USERLAND_ARCHIVES?= $(WS_TOP)/archives" in 
shared-macros.mk and fixing up prep.mk.

There are a few benefits to this, one is that if you have lots of 
illumos-userland workspaces, they can all share a single archive directory. It 
can be NFS or lofs mounted, and it makes rsyncing the contents of that 
directory up to our mirror archive a lot easier than manually picking through 
all the component directories.

It also lets us add $(WS_TOP)/archives to .hgignore and no longer have to put 
up with seeing downloaded archives in the "hg status" output.

Before I begin work on this changeset for illumos-userland, does anyone have 
any feedback?

Cheers,

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

[oi-dev] Deduplicating illumos-userland

[Alasdair Lumsden]

Hi All,

In s10-userland, early on we abstracted a lot of commonly used macros up into 
the shared-macros area. Unfortunately illumos-userland doesn't have this and it 
has created a situation where a lot of Makefiles unnecessarily duplicate macros.

For example, in s10-userland we added the following to configure.mk

CONFIGURE_ENV   +=  CC="$(CC)"
CONFIGURE_ENV   +=  CXX="$(CXX)"
CONFIGURE_ENV   +=  CFLAGS="$(CFLAGS)"
CONFIGURE_ENV   +=  LDFLAGS="$(LDFLAGS)"
CONFIGURE_ENV   +=  PKG_CONFIG="$(PKG_CONFIG_PATH)"

# Tell autoconf about 64bit builds
CONFIGURE_OPTIONS.64 += --build=x86_64-pc-solaris$(SOLARIS_VERSION)

CONFIGURE_LOCALSTATEDIR =   $(CONFIGURE_PREFIX)/var
CONFIGURE_OPTIONS += --infodir=$(CONFIGURE_INFODIR)
CONFIGURE_OPTIONS += --sysconfdir=$(CONFIGURE_SYSCONFDIR)
CONFIGURE_OPTIONS += --localstatedir=$(CONFIGURE_LOCALSTATEDIR)

In shared-macros.mk we added:

LDFLAGS+=   $(LD_BITS)

(Note that the --build above needs improving for SPARC, can probably be derived 
from MACH64 somehow)

The above is all completely missing from illumos-userland/userland-gate for no 
apparent reason. In s10-userland, we found adding this stuff this flushed out a 
lot packaging mistakes. For example a lot of software leverages pkgconfig, and 
64bit builds were using 32bit pkgconfig cflags/ldflags. Also autoconf/libtool 
use --build to determine various things related to bittiness; setting -m64 is 
not by itself always enough.

We found few cases where the above caused issues (I can't think of any off the 
top of my head). There are occasions when a software component has a configure 
script that is not generated by autoconf, that barfs on some of the above 
flags, but the correct way to deal with that is set CONFIGURE_OPTIONS= instead 
of += and define the precise arguments it takes, since these non-autoconf 
configure scripts are rare and always bespoke.

Ideally we want to cater for the general common cases first, avoid unnecessary 
duplication, and err on the side of safety (which --build and PKG_CONFIG for 
64bit improves). Here is random example of how this will cut down on duplicated 
cruft:

--- gd2/Makefile2012-05-05 14:31:12.052620402 +0100
+++ /tmp/gd2_Makefile_new   2012-05-05 16:58:11.668117871 +0100
@@ -37,18 +37,11 @@
 include ../../make-rules/ips.mk
 include ../../make-rules/lint-libraries.mk
 
-PKG_CONFIG_PATH_32 = /usr/lib/pkgconfig
-PKG_CONFIG_PATH_64 = /usr/lib/$(MACH64)/pkgconfig
-
 PATCH_LEVEL = 0
 
 CFLAGS += $(CPP_LARGEFILES)
 CPPFLAGS += $(CPP_LARGEFILES)
 
-CONFIGURE_ENV += CFLAGS="$(CFLAGS)"
-CONFIGURE_ENV += CPPFLAGS="$(CPPFLAGS)"
-CONFIGURE_ENV += PKG_CONFIG_PATH="$(PKG_CONFIG_PATH_$(BITS))"
-
 CONFIGURE_OPTIONS  +=   --includedir=$(CONFIGURE_INCLUDEDIR)/gd2
 CONFIGURE_OPTIONS  +=   --disable-static
 CONFIGURE_OPTIONS  +=   --disable-rpath


We also created a new make-rules/gnu-ld.mk file that could be included to get 
GNU ld (unfortunately needed for some multimedia software that uses linker 
features the Sun linker doesn't support). One for OI would contain:

COMPONENT_BUILD_ENV+=   LD_ALTEXEC=/usr/gnu/bin/ld
COMPONENT_INSTALL_ENV+= LD_ALTEXEC=/usr/gnu/bin/ld
CONFIGURE_ENV+= LD=$(ECPREFIX)/bin/ld
CONFIGURE_OPTIONS+= --with-gnu-ld

(Note on s10-userland we actually supply a 32bit and 64bit build of 
gnu-binutils as we found a 64bit gld was necessary to link some 64bit objects - 
I forget the details but this is something that we can look at down the road 
when we start packaging that software up).

We could also add a make-rules/ncurses.mk:

# Use ncurses
CURSES_DIR_32=  /usr/gnu/lib
CURSES_DIR_64=  /usr/gnu/lib/$(MACH64)
CURSES_DIR= $(CURSES_DIR_$(BITS))
LDFLAGS+=   -L$(CURSES_DIR) -R$(CURSES_DIR)
CPPFLAGS+=  -I/usr/include/ncurses

This ncurses definition block is used in a number of components that require 
ncurses, so it makes sense to abstract it out.

The gnu-ld.mk/ncurses.mk files are used by simply adding an "include 
../make-rules/[blah].mk" line to the component Makefile.

Before I file some issues and begin work on some changesets, does anyone have 
any feedback/comments?

Cheers,

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

Re: [oi-dev] 2483 Bring libcaca into illumos-userland from s10-userland

[Alasdair Lumsden]

On 5 May 2012, at 16:31, Andrew Stormont wrote:
> Not a fan of the license but the changes LGTM.

Copied verbatim from the source. They're a strange bunch.

> Does this require gcc-4.4 to build?

It won't build with Studio out of the box. It could be patched, but I don't 
think it's worth doing for this novelty item. I'm not entirely sure what the 
policy is on building with gcc is at the moment - should I remove GCC_ROOT? If 
I want to use 4.4 by default should I set that elsewhere?

> Also if this is intended for illumos-userland it might be a good idea to
> cc userland@

Doh, good point. Old habits die hard. Set the To to userl...@lists.illumos.org 
and the CC to the oi-dev list.

Cheers,

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

[oi-dev] 2483 Bring libcaca into illumos-userland from s10-userland

[Alasdair Lumsden]

Hi All,

Looking for a review for this:

https://bitbucket.org/alasdairlumsden/illumos-userland-2483/changeset/5e2953636726

Cheers,

Alasdair


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

Re: [oi-dev] pkg.openindiana.org/experimental updated - now with gcc-44

[Alasdair Lumsden]

Hi Milan,

Could you try now?

I haven't sucked in the new prestable version yet but I've resolved the 
conflicts, so it should install.

Cheers,

Alasdair


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

Re: [oi-dev] pkg.openindiana.org/experimental updated - now with gcc-44

[Alasdair Lumsden]

Hi Milan, All,

I haven't had a chance yet to fix the long list of issues with it yet, sorry 
for taking a while.

The /experimental repo is literally just a dump of illumos-userland over a 
pkgrecv of 0.151.1.3 from /dev (Plus the sfw incorporation adjusted).

There are some conflicts that need resolving, and incorporation fixing. I guess 
I will also now have to find a magic way of importing the latest pre-stable too.

Will keep you all updated with progress.

Cheers,

Alasdair


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

Re: [oi-dev] pkg.openindiana.org/experimental updated - now with gcc-44

[Alasdair Lumsden]

Hi Milan,

That's quite odd - it isn't doing a full update. Something will most likely be 
wrong with an incorporation.

Could you try:

pkg install -nv pkg://oi-experimental/entire@0.5.11,5.11-1.1:20120421T025607Z

This should hopefully explode with some useful error messages.

Cheers,

Alasdair


On 2 May 2012, at 21:12, Milan Jurik wrote:

> Hi Alasdair,
> 
> is it expected that update from oi_151a3 will look like:
> 
> 
> # pkg update -nv
>Packages to update:12
> Estimated space available: 263.17 GB
> Estimated space to be consumed:  64.24 MB
>   Create boot environment:Ne
> Create backup boot environment:   Ano
>  Rebuild boot archive:Ne
> 
> Changed packages:
> openindiana.org -> oi-experimental
>  compress/xz
>5.0.3,5.11-0.151.1.3:20120329T221326Z ->
> 5.0.3,5.11-1.1:20120421T024155Z
>  developer/build/onbld
>0.5.11,5.11-0.151.1.3:20120329T221409Z ->
> 0.5.11,5.11-1.1:20120421T024848Z
>  developer/gob2
>2.0.16,5.11-0.151.1.3:20120329T221432Z ->
> 2.0.16,5.11-1.1:20120421T025010Z
>  developer/icu
>0.5.11,5.11-0.151.1.3:20120329T221434Z ->
> 0.5.11,5.11-1.1:20120421T025011Z
>  library/icu
>0.5.11,5.11-0.151.1.3:20120329T221921Z ->
> 0.5.11,5.11-1.1:20120421T030345Z
>  library/idnkit
>0.5.11,5.11-0.151.1.3:20120329T221958Z ->
> 0.5.11,5.11-1.1:20120421T030434Z
>  library/python-2/mako-26
>0.4.1,5.11-0.151.1.3:20120329T222044Z ->
> 0.4.1,5.11-1.1:20120422T185043Z
>  library/python-2/ply-26
>3.1,5.11-0.151.1.3:20120329T222046Z -> 3.1,5.11-1.1:20120423T011107Z
>  library/python-2/pybonjour-26
>1.1.1,5.11-0.151.1.3:20120329T222047Z ->
> 1.1.1,5.11-1.1:20120423T011100Z
>  package/pkgbuild
>1.3.104,5.11-0.151.1.3:20120329T56Z ->
> 1.3.104,5.11-1.1:20120421T031136Z
>  system/input-method/library/libchewing
>0.5.11,5.11-0.151.1.3:20120329T224223Z ->
> 0.5.11,5.11-1.1:20120421T032530Z
>  system/input-method/library/libhangul
>0.5.11,5.11-0.151.1.3:20120329T224232Z ->
> 0.5.11,5.11-1.1:20120421T032537Z
> 
> ?
> 
> Best regards,
> 
> Milan
> 
> Alasdair Lumsden píše v st 02. 05. 2012 v 01:23 +0100:
>> Hi All,
>> 
>> I have updated the /experimental repo available at:
>> 
>> http://pkg.openindiana.org/experimental
>> 
>> This now contains oi_151a3 overlayed with what was previously available in 
>> /experimental, plus gcc-44 - all at version string 1.1
>> 
>> Please give this a go and report back any issues. To use it, first update to 
>> oi_151a3, then do:
>> 
>> pkg set-publisher -p http://pkg.openindiana.org/experimental
>> pkg set-publisher -P oi-experimental
>> pkg set-publisher --non-sticky openindiana.org
>> 
>> Your pkg publisher output should look like this:
>> 
>> PUBLISHER TYPE STATUS   URI
>> oi-experimental   origin   online   
>> http://pkg.openindiana.org/experimental/
>> openindiana.org  (non-sticky) origin   online   
>> http://pkg.openindiana.org/dev/
>> 
>> You can then "pkg update -nv" to see if it will successfully update, then 
>> you can actually do the update with "pkg update -v"
>> 
>> Note that this hasn't been extensively tested yet and is "hot off the 
>> press". If you have any issues, please report back with full details.
>> 
>> I have tidied up sfw-incorporation by stripping out any packages present in 
>> illumos-userland. If I have missed any, you can do this to correct:
>> 
>> pkgrepo -s file:///tmp/sfw-repo create
>> pkgrepo -s file:///tmp/sfw-repo set publisher/prefix=sfw-repo
>> pkg contents -m sfw-incorporation > /tmp/sfw-incorporation.p5m
>> 
>> Then edit the file at /tmp/sfw-incorporation.p5m, (remember to strip out the 
>> timestamp in the pkg fmri), then publish it with:
>> 
>> pkgsend -s file:///tmp/sfw-repo publish --fmri-in-manifest 
>> /tmp/sfw-incorporation.p5m
>> 
>> You can then install this with:
>> 
>> pkg set-publisher -p file:///tmp/sfw-repo
>> pkg set-publisher -P sfw-repo
>> pkg set-publisher --non-sticky oi-experimental
>> pkg install -v pkg://sfw-repo/consolidation/sfw/sfw-incorporation
>> 
>> There may be other consolidation boundary issues that need fixing - if you 
>> encounter any, let me know! We're now in good shape to start cranking 
>> changes out into illumos-userland and moving packages over from other 
>> consolidations :-) It would be good to start importing the work aszeszo did 
>> converting JDS packages to userland-gate format and also look at a JDS 
>> rebuild.
>> 
>> 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 mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] pkg.openindiana.org/experimental updated - now with gcc-44

[Alasdair Lumsden]

Hi All,

I have updated the /experimental repo available at:

http://pkg.openindiana.org/experimental

This now contains oi_151a3 overlayed with what was previously available in 
/experimental, plus gcc-44 - all at version string 1.1

Please give this a go and report back any issues. To use it, first update to 
oi_151a3, then do:

pkg set-publisher -p http://pkg.openindiana.org/experimental
pkg set-publisher -P oi-experimental
pkg set-publisher --non-sticky openindiana.org

Your pkg publisher output should look like this:

PUBLISHER TYPE STATUS   URI
oi-experimental   origin   online   
http://pkg.openindiana.org/experimental/
openindiana.org  (non-sticky) origin   online   
http://pkg.openindiana.org/dev/

You can then "pkg update -nv" to see if it will successfully update, then you 
can actually do the update with "pkg update -v"

Note that this hasn't been extensively tested yet and is "hot off the press". 
If you have any issues, please report back with full details.

I have tidied up sfw-incorporation by stripping out any packages present in 
illumos-userland. If I have missed any, you can do this to correct:

pkgrepo -s file:///tmp/sfw-repo create
pkgrepo -s file:///tmp/sfw-repo set publisher/prefix=sfw-repo
pkg contents -m sfw-incorporation > /tmp/sfw-incorporation.p5m

Then edit the file at /tmp/sfw-incorporation.p5m, (remember to strip out the 
timestamp in the pkg fmri), then publish it with:

pkgsend -s file:///tmp/sfw-repo publish --fmri-in-manifest 
/tmp/sfw-incorporation.p5m

You can then install this with:

pkg set-publisher -p file:///tmp/sfw-repo
pkg set-publisher -P sfw-repo
pkg set-publisher --non-sticky oi-experimental
pkg install -v pkg://sfw-repo/consolidation/sfw/sfw-incorporation

There may be other consolidation boundary issues that need fixing - if you 
encounter any, let me know! We're now in good shape to start cranking changes 
out into illumos-userland and moving packages over from other consolidations 
:-) It would be good to start importing the work aszeszo did converting JDS 
packages to userland-gate format and also look at a JDS rebuild.

Cheers,

Alasdair



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

Re: [oi-dev] Which rge driver is in the latest bits?

[Alasdair Lumsden]

Hi Milan,

It comes from illumos-gate. We have our own patches applied to the tree, but 
nothing major:

https://hg.openindiana.org/sustaining/oi_151a/illumos-gate/

Our last sync with illumos-gate was 5 weeks ago.

Cheers,

Alasdair



On 21 Apr 2012, at 14:11, Milan Jurik wrote:

> Hi,
> 
> could somebody give me hint which rge is in the latest published bits?
> Among issues I found this one - https://www.illumos.org/issues/2040
> 
> I am asking because I have big problems with rge, it is able to download
> only few packets and then stops to work. I would like to debug it but I
> need to know from where bits are comming.
> 
> Best regards,
> 
> Milan
> 
> 
> ___
> 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] Webrev: Issue 2024 - ZFS dedup=on should not panic the system when two blocks with same checksum exist in DDT

[Alasdair Lumsden]

On 20 Apr 2012, at 00:56, Jim Klimov wrote:

> 2012-04-20 3:40, Alasdair Lumsden wrote:
>> Hi Jim,
>> Did you mean to send this to the illumos developer list rather than the OI 
>> one?
> Hmmm... yes, I guess so.
> This was my first attempt after all ;)
> 
> I'll repost then. What is your estimate, how much different
> really are the sets of readers of these two lists? ;)

Quite large I imagine :-) OI has few kernel developers working directly on it. 
Most if the Illumos kernel developers work for commercial entities such as 
Nexenta, Joyent and Delphix who all have their own distros.


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

Re: [oi-dev] Webrev: Issue 2024 - ZFS dedup=on should not panic the system when two blocks with same checksum exist in DDT

[Alasdair Lumsden]

Hi Jim,

Did you mean to send this to the illumos developer list rather than the OI one?

Cheers,

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

Re: [oi-dev] New BE every package update?

[Alasdair Lumsden]

On 15 Apr 2012, at 21:50, Milan Jurik wrote:
> The reality is that I am flooded with several new BEs per day. My grub
> list is increasing frequently. OK, I have to live with it :-)

There's also:

pkg --no-backup-be

:-D

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

Re: [oi-dev] samba security

[Alasdair Lumsden]

Hi Martin,

We've obtained the Debian security patches for 3.5.6 which should hopefully 
apply fairly cleanly against our 3.5.5:

http://security-tracker.debian.org/tracker/source-package/samba

We're looking into things.

Cheers,

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

Re: [oi-dev] samba security

[Alasdair Lumsden]

On 15 Apr 2012, at 18:59, Martin Walter wrote:

> Would it be not easier and better to just make the newest version available?
> E.g. I would much more prefer just a samba-3.6.4 package than an updated 
> samba-3.5.5.

Yes, if we were on the new build system. So updating samba for /experimental 
wouldn't be too hard.

But samba for oi_151a is stuck in an old build system, so updating it would 
require more effort than anyone we have is willing to take on. And as Rich 
pointed out, isn't really what the stable branch is about.

If you have time you could have a look to see if there is a patch that applies 
against samba-3.5.5 that fixes the CVE. The usual place to look is other 
distro's patch sets against samba where their version is close to ours. *That* 
would be genuinely helpful and more use to us than building stuff :-)

Cheers,

Alasdair


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

Re: [oi-dev] samba security

[Alasdair Lumsden]

Hi Martin,

On 15 Apr 2012, at 15:10, Martin Walter wrote:

>> Unfortunately however the new version probably won't make the stable branch. 
>> The stuff in illumos-userland will be destined for /experimental followed by 
>> /dev.
> 
> pkg.openindiana.org/experimental is last updated at 2011-11-19 !?
> 
> I think such critical security holes should be fixed asap. Otherwise
> it is really a risk to run Openindiana on big fileservers.

The binary repo was last updated quite a while ago, but work continues on the 
source side at:

https://hg.openindiana.org/illumos-userland/
and
https://hg.openindiana.org/upstream/oracle/userland-gate

The challenge is manpower - 151a was built using a collection of highly 
unpalatable build systems that few of our developers want to work on. The 
reason for the delay between oi_151 and our next big release (not the stable) 
is that we're completely re-tooling around a single build system. Once done, 
we'll be able to churn out updates far more easily.

However the retooling effort has been derailed and held up by the fact it 
started life as oi-build and became a collaborative effort with Nexenta called 
illumos-userland, which they are going to also use for Illumian. A lot of 
resources have had to be diverted to sorting out collaborating with them and 
dealing with the consequences of this. We're nearly there and hopefully things 
will speed up again once we get into the swing of things.

If you'd like things to proceed faster, I'd like to point out that the devs 
working on OI are contributing their free time to do this. If you value OI then 
you're welcome to assist us and help get things updated faster.

The stable release is about backporting critical security fixes, and this one 
sounds like the kind of thing we should look at backporting. So we will look 
into it and see what can be done. But it probably won't involve a version bump, 
more a patch to the older version.

Cheers,

Alasdair





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

Re: [oi-dev] samba security

[Alasdair Lumsden]

On 15 Apr 2012, at 13:54, Bayard Bell wrote:

> A version of 3.6.4 is pending for the illumos-userland head.

Hi Walter,

Unfortunately however the new version probably won't make the stable branch. 
The stuff in illumos-userland will be destined for /experimental followed by 
/dev.

Cheers,

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

Re: [oi-dev] Strange output during upgrade to the latest prestable

[Alasdair Lumsden]

Hi Milan,

I've just checked, and it's because the new OI prestable ships with a newer 
version of pkg which no longer delivers the cat1m file.

The newer pkg version I believe is the S11 pkg version backport to S11X to 
facilitate upgrading between the two versions. It looks like 
cat1m/pkg.depotd.1m was moved into the package/pkg/system-repository package in 
S11 but the backport doesn't provide it.

We might want to patch it back into being supplied for the actual stable build.

Cheers,

Alasdair


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

Re: [oi-dev] Strange output during upgrade to the latest prestable

[Alasdair Lumsden]

Hi Milan,

On 15 Apr 2012, at 11:52, Milan Jurik wrote:
> Removal Phase73/3158 
> Warning - directory /tmp/tmppQR55O/usr/share/man/cat1m not empty or not
> expected during operation - contents preserved
> in /tmp/tmppQR55O/var/pkg/lost
> +found/usr/share/man/cat1m-20120415T121445Z

We'll need to look into why cat1m has changed.

Is /tmp/tmppQR55O not where the cloned boot environment was mounted for the pkg 
to operate on?

Cheers,

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

Re: [oi-dev] userland history problems

[Alasdair Lumsden]

Hi Bayard,

Sorry for not getting back to you sooner - I think the answer is "go for it".

We only get this opportunity once, so lets take it. The hassle factor is worth 
it, checking out the tree again is trivial.

Cheers,

Alasdair


On 12 Apr 2012, at 22:03, Bayard G. Bell wrote:

> Unless I hear any compelling objection, I'm going through with this this
> weekend.
> 
> On Tue, 2012-04-10 at 18:51 +0100, Bayard G. Bell wrote:
>> In the course of fulfilment of my request for git mirroring, I've
>> learned that we have a slight problem in our history: someone forgot to
>> put a space between their name and the angle brackets surrounding their
>> e-mail address. There are two ways to fix this: one is to ask github to
>> disable validation of this data, the other is to fix the history, which
>> is a destructive change.
>> 
>> Since we're just getting on our feet, I'm inclined to make two
>> substantial clean-ups in the history, one is to fix these commit
>> records, and the other is to remove backed out changesets so they don't
>> show up in annotations (which seems reasonable, given that the net
>> effect is that no change happened, which to my mind shouldn't have two
>> records against it for most repository contents).
>> 
>> That means everyone using illumos-userland will need to re-clone for
>> both mercurial and git. I know it's ugly, but I think this is pretty
>> much the last point at which we can bite the bullet and clean this up
>> properly--the other option is a workaround, whereas this is a painful
>> fix. On the plus side, we'll finally have mirrors of the canonical
>> available as illumos/illumos-userland.
>> 
>> Cheers,
>> Bayard
>> 
>> 
>> 
> 
> 
> 
> 
> ___
> 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] RFC: new meeting time Thursdays at 7PM UK time

[Alasdair Lumsden]

Hi Bayard,

Fine for me!

Cheers,

Alasdair

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

Re: [oi-dev] Support OI and illumos for GSoC 2012

[Alasdair Lumsden]

Hi Bayard,

I think your comments regarding VBox being not-fit-for-purpose for Illumos/OI 
development are completely valid and worth mentioning.

What are the plans regarding recruiting students onto GSoC? I'm not familiar 
with how the whole process works. Is this something we need to advertise to 
Universities/Students?

Cheers,

Alasdair




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

Re: [oi-dev] PostgreSQL 9.1.3 requires OpenSSL 1.0.0

[Alasdair Lumsden]

On 2 Mar 2012, at 05:48, Richard PALO wrote:
> bad news, the latest binary update from
> http://www.postgresql.org/ftp/binary/v9.1.3/solaris/solaris11/
> requires OpenSSL 1.0.0.

Boo! That sucks.

> (probably because Oracle compiled it)

Hmm, I have my doubts, as Oracle yanked all traces of Postgresql out of Solaris 
11. But who knows!

> So, the question is  will OpenSSL 1.0.0 make it into the upcoming
> stable release?

No, due to the huge number of things the version bump touches. But it is in 
pkg.openindiana.org/experimental

> I guess one could also ask if a useable 9.1.3 pg release (with a
> compatible pgadmin) will make it into the base oi repositories?

If new versions of Postgresql arrive,  probably only into /experimental and 
thus into the next /dev release after /stable comes out.

Cheers,

Alasdair


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

Re: [oi-dev] status of dcmtk and Xmedcon

[Alasdair Lumsden]

Hi Paolo,

We haven't committed these as far as I'm aware - unfortunately oi-build 
got tied up in some cross-distribution politics and we're now 
collaborating with Nexenta on illumos-userland, based on oi-build.


We will try to get these reviewed and put back into this soon - again 
sorry for the delay.


Cheers,

Alasdair

On 29/02/2012 09:15, paolo marcheschi wrote:

Hi

I'm sorry to bother you, but what is the status of the two packages I tried
to port ? Dcmtk, and Xmedcon ?

Are they published, is there an IPS repository where I can download these
new packages?

Thank you

Paolo



___
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] ntfs-3g and fuse

[Alasdair Lumsden]

Hi Jean-Pierre,

Would you have any interest in adding this to the illumos-userland build 
framework so that it ships with the distribution in future releases?

Regards,

Alasdair


On 28 Feb 2012, at 09:58, Jean-Pierre André wrote:

> Hi,
> 
> I am now releasing the fuse kernel module for OpenIndiana. Ntfs-3g
> now fully passes the standard tests with this kernel module and without
> need of the workarounds I had to insert earlier to cope with the bad
> behavior of the fuse kernel module originated from OpenSolaris.
> 
> A few optimizations would still be useful. I might have a look at them
> if there is enough demand.
> 
> Available on http://b.andre.pagesperso-orange.fr/openindiana-ntfs-3g.html
> are three packages ready for use :
> 
> - a full ntfs-3g package in 32-bit mode with the fuse-lite library
>  and ntfsprogs
> - a full ntfs-3g package in 64-bit mode with the fuse-lite library
>  and ntfsprogs
> - a fuse kernel module package for both the 32-bit and 64-bit modes
> 
> The raw source files (not packaged according to OpenIndiana
> standards) are also available there.
> 
> I am keeping these files available on line for some time. I also keep
> the change sets available to whoever enters the source code of the
> fuse kernel module into a public source code management
> repository.
> 
> Enjoy,
> 
> Jean-Pierre
> 
> 
> Jean-Pierre André wrote:
>> Hi,
>> 
>> Milan Jurik wrote:
>>> Hi Jean-Pierre,
>>> 
>>> Jean-Pierre ANDRE píše v út 24. 01. 2012 v 15:16 +0100:
 Hi,
 
 As a maintainer of ntfs-3g, I have received bug reports on OpenIndiana. 
 Digging into them, I found there were almost all caused by the buggy fuse 
 kernel module, which nobody seems to care about. So I had to do it 
 myself
> 
> 
> 
> ___
> 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] [userland] 2142 update python2.6 to 2.6.7

[Alasdair Lumsden]

On 24/02/2012 22:48, Bayard Bell wrote:

I've run the test suite for python 2.6.4 and 2.6.7 with gcc 4.4 and
studio. It turns out that considerably more modules have problems under
studio than gcc, none fail on gcc that don't also fail on studio, but
one module (sys) seems to fail slightly differently, which I'll investigate.


Great work! Haven't had a chance to review the changesets but I'll be 
very happy when we ship Python, Ruby, PHP and friends built with gcc - 
eggs/gems/pecl will finally work as intended without exploding on native 
extensions that assume gcc :-)


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

Re: [oi-dev] open-fabrics pkg on OpenIndiana 151a

[Alasdair Lumsden]

Hi Syoyo,

Sorry for not getting back to you on this, this was due to oi-build becoming 
illumos-userland, a shared project between OpenIndiana and Illumian.

We should be able to review and integrate this soon.

Cheers,

Alasdair

On 6 Feb 2012, at 08:25, Syoyo Fujita wrote:

> Hello Alasdair,
> 
> I've wrote some patches for open-fabrics component to work with
> OI151a(+Illumos)
> 
> https://github.com/syoyo/oi-build/tree/ofed-1.5.4.1
> 
> As a bonus, I've updated OFED version from 1.5.3 to recent 1.5.4.1(RC2).
> 
> I've confirmed it can compile and can create IPS package, but not
> confirmed yet it works well on many OpenIndiana/Illumos environment.
> 
> I'm happy if you or someone InfiniBand + OpenIndiana people contribute
> to testing my components.
> 
> Thanks in advance.
> 
> On Mon, Nov 28, 2011 at 7:50 PM, Syoyo Fujita  wrote:
>> Hello Alasdair,
>> 
>> Thank you for quick response.
>> 
>> As reported https://www.illumos.org/issues/378,
>> I got same problem in building open-fabrics, and I resolve it by
>> replacing /usr/include/sys/ib/adaptors/* header files provided by
>> Oracle Solaris 11.
>> Current tavor and hermon header files shipped with OI seems old, even
>> though I don't know it is ok to just replace header files with new
>> one.
>> 
>> Also, I have to add AF_INET_SDP 33 definition to /usr/include/sys/socket.h
>> (This is also added in Solaris 11's header file).
>> 
>> With this, most components of open-fabrics compile OK.
>> But could not run rdma_bw command for example. I got seg fault.
>> 
>> $ ./rdma_bw
>> 27677: | port=18515 | ib_port=1 | size=65536 | tx_depth=100 | sl=0 |
>> iters=1000 | duplex=0 | cma=0 |
>> Segmentation Fault (core dumped)
>> 
>> So, finally, it seems that open-fabrics source&patch will work with
>> Solaris 11 kernel/modules/system header.
>> 
>> Does OI provide Solaris 11-compatible kernel and modules? Grabbing a
>> dev tree of Illumos?
>> If so, I'd like to use it to test the build of open-fabrics.
>> 
>> --
>> Syoyo
>> 
>> On Sat, Nov 26, 2011 at 7:32 AM, Alasdair Lumsden  
>> wrote:
>>> Hi Syoyo,
>>> 
>>> On 25 Nov 2011, at 12:06, Ｓyoyo Ｆujita wrote:
>>> 
>>>> I'd like to build open-fabrics pkg(SUNWofusr) from source on OpwnIndiana 
>>>> 151a, to use InfiniBand verbs on OpenIndiana.
>>> 
>>> Check out:
>>> 
>>> http://hg.openindiana.org/oi-build/file/5a82dc248330/components/open-fabrics
>>> 
>>> This has some documentation:
>>> 
>>> http://wiki.openindiana.org/oi/Building+with+oi-build
>>> 
>>> oi-build originates from the userland-gate project at Oracle for Solaris 
>>> 11. Unfortunately open-fabrics doesn't build on OI (although most of 
>>> userland-gate does), so you might need to do some work to get it to build. 
>>> But it should be a good start, and certainly much easier to build it from 
>>> oi-build than from the old sfw-gate.
>>> 
>>> 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 mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [userland] Re: illumos-userland update

[Alasdair Lumsden]

On 21 Feb 2012, at 11:48, Kartik Mistry wrote:
> Agree. I can write process of making Debian packaging tools we have
> for/from IPS plus some general information. Which will be best place
> for that? illumian wiki page?

I'd say any documentation regarding tools shipped with illumos-userland should 
be on the Illumos wiki.

For OpenIndiana we'll probably have distro-specific instructions on our wiki 
but aim to avoid duplicating content and instead refer to the Illumos-userland 
documentation on the Illumos wiki for how to build with it.



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

Re: [oi-dev] How to name package with PAM module?

[Alasdair Lumsden]

On 22 Feb 2012, at 13:16, Andrew Stormont wrote:

> I think what you want is "pkg:/library/security/pam/module/pam-sqlite"

+1

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

Re: [oi-dev] GRUB fonts

[Alasdair Lumsden]

On 22 Feb 2012, at 16:49, Dmitry Kozhinov wrote:
> As new ISOs are to build soon, may I suggest a small and easy-to-implement 
> fix:
> Current fonts in GRUB menu are almost unreadable on some older CRT monitors 
> (dark-gray letters on black background with white shadow). Only white shadow 
> is clearly visible, dark-gray hides on black. Please someone who are in 
> control, change the color scheme.

I agree.

Is this a menu.lst thing? Anyone fancy supplying a patch/changeset?
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] illumos-userland update

[Alasdair Lumsden]

Hi All,

Earlier this month at FOSDEM we had some very positive discussions about moving 
OI and Illumian forward with our joint effort on illumos-userland. Further 
discussions have been held between the key people driving this, which I'd like 
to outline in this email.

Here are the key points:

1. Master repo at ssh://h...@hg.illumos.org/illumos-userland
2. Web browsable http mirror at http://hg.openindiana.org/illumos-userland/
3. Review process to be largely the same as for oi-build
4. Mirrors on BitBucket and Github to follow shortly

Igor (igork) of Nexenta has been working hard on getting illumos-userland into 
shape for Illumian, including adding Debian dpkg support, making things build 
with gcc 4.4, and adding software.

Igor's commits weren't community reviewed and don't consist of discrete 
changesets with a bug ID, so Bayard (buffyg) has backed these out for now. Igor 
and others are going to work together on getting these changes broken up into 
reviewable changesets so they can be re-committed.

We're also going to be working on processing the backlog of outstanding reviews 
on the mailing lists to get them committed to illumos-userland. For anyone who 
has contributed a changeset for review, thanks for your patience so far, 
hopefully we'll get them in soon.

We'll need to adapt the OI continuous integration to build from the new 
illumos-userland, and we'll also need to train others on Jenkins. If anyone is 
interested in helping with the continuous integration please let me know.

Bayard is working on getting gcc 4.4 into shape, which is going to be our 
default compiler for now as we transition software over to it. We're making gcc 
4.4 the default and GCC's libraries such as libgcc and friends will be symlinks 
from /usr/lib to /usr/gcc/4.4/lib, and GCC won't have any RPATH hackery in it.

We'll look at supplying GCC 4.6 for end users to use should they wish, which 
may ship with RPATH hackery so if someone uses GCC 4.6 to build software, it 
adds an RPATH of /usr/gcc/4.6/lib so such software can find the right libgcc 
version. We're also looking into adding Clang support at a later date, with a 
view to transitioning C software over to this in the future, but this is very 
much on the back burner as there are much more important things at the moment.

Andy (andy_js) is looking at adding desktop components into illumos-userland, 
such as Gnome. How this will tie in with OI and JDS updates is unclear but 
there's a lot of scope for collaboration. Andrzej (aszeszo)

In terms of our roadmap for getting the contents of illumos-userland into a 
release, our plan is to get illumos-userland building on the current OI Jenkins 
build box, which auto-publishes to /experimental.

To get /experimental into shape, we intend to clone /dev to /experimental, and 
publish all the illumos-userland software to it. IPS/pkg5 will be rebuilt and 
published with branding fixes (the /experimental one is based on the S11->S11X 
backport). We will relax the incorporations in /experimental by removing 
version data, to allow incremental software updates during development. The 
package list in the incorporations can be updated as software is added or moved 
from the legacy OpenSolaris consolidations (Such as JDS) to illumos-userland, 
and potentially they can be auto-generated by a script based on packaging 
metadata if sufficiently complete (to be investigated).

Jon Tibble (Meths) is working on getting /dev published to /stable with his 
pre-stable builds. This has been paired back in scope to covering critical 
remote root exploit fixes. Maintaining /stable is hard due to the legacy Sun 
build systems and the age of the software. The key driver is that once /stable 
has shipped we can start doing regular publishes from /experimental to /dev, 
the process of which should simply involve adding version data to the 
incorporations.

Once we have regular /dev builds we can start moving towards our next stable. 
Some of the key goals I'd like to see for the next stable are:

1. Primary compiler will be GCC 4.4, with 4.5 and 4.6 support (4.5 for compat 
with S11)
2. OpenSSL 1.0
3. OpenJDK
4. Updated Firefox & Thunderbird
5. Updated Python & Ruby
6. Latest Apache, lighttpd, nginx, PHP, MySQL and Postgresql packages
7. Chromium
8. VirtualBox open source edition

Andrzej has had success in building the latest JDS, which now spits out IPS 
packages rather than SVR4 ones. Rebranding work is required however hopefully 
we can catch up with Solaris 11 here.

I think that covers the most important points. Exciting developments ahead!

Cheers,

Alasdair



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

Re: [oi-dev] lx zone

[Alasdair Lumsden]

On 13/02/2012 15:57, carlos antonio neira bustos wrote:

Hi

on build 143 i cannot see these  directories that are specified by the
brandz design document.

usr/src/uts/common/brand/lx source for kernel-level lx support
usr/src/uts/common/brand/lx/procfs source for the lx /proc
usr/src/uts/common/brand/lx/dtrace source for the lx syscall provider

im retrieving the source code tree using :
hg clone ssh://a...@hg.opensolaris.org/hg/onnv/onnv-gate
 onnv-b142

Am I  doing something wrong here or the brandz design document has been
not updated ?.


Did you remember to do "hg update onnv_142" in the checked out source tree?

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

Re: [oi-dev] error in pkg5 - from oi-prestable

[Alasdair Lumsden]

On 11 Feb 2012, at 14:11, Gordon Ross wrote:

> There's also the difference that "pkg" is real source code, (right?)
> where most other things in userland are just build recipes.
> 
> If I correctly understood the suggestion for a separate "tools" gate,
> then I think that sounds helpful.

Well! There are options here. pkg could be treated just like every other bit of 
software inside illumos-userland, like gcc or openssl.

The build recipe could check it out, do the build, publish it. Indeed, we 
already have a rather dirty version of this in s10-userland:

http://hg.openindiana.org/users/aszeszo/s10-userland/file/86bc2641a3a0/components/pkg5

I quite liked the idea of having a single repo to check out to be able to build 
the whole OS - makes it much easier for people to get involved with OS 
development. But pkg is more specific to OpenIndiana than it is to Illumian, so 
perhaps OI and Illumian need separate repos for where we deviate?

Back when this was oi-build, my plan was for it to be able to build everything 
- illumos-gate, pkg-gate, etc, all treated as components.

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

[oi-dev] Opening the wiki to registrations

[Alasdair Lumsden]

Hi All,

To bolster community involvement I wondered if it was worth opening the wiki up 
to registrations.

My concern with this right from the beginning was keeping the quality high and 
preventing spam.

On the quality front, I think as long as people police the thing it should be 
okay. However preventing spam may be harder - the comment box has a captcha and 
yet we get quite a bit of comment spam.

Perhaps someone would be interested in investigating better captchas for 
confluence?

Cheers,

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

Re: [oi-dev] ntfs-3g and fuse

[Alasdair Lumsden]

Hi Jean-Pierre,

Great work! I wonder if we could find a way to get these fixes applied 
upstream.


We would also like to add ntfs-3g to oi-build (illumos-userland)

Cheers,

Alasdair

On 24/01/2012 14:16, Jean-Pierre ANDRE wrote:

Hi,

As a maintainer of ntfs-3g, I have received bug reports on OpenIndiana. Digging 
into them, I found there were almost all caused by the buggy fuse kernel 
module, which nobody seems to care about. So I had to do it myself

If anybody is interested, please see 
http://b.andre.pagesperso-orange.fr/openindiana-ntfs-3g.html

Bugs fixed in the fuse kernel module :

- Return st_blocks as defined by the file system
- Process the error returned by the file system on unlink()
- Do not send create() for existing files to the file system
- Delete sent messages when no reply is expected (memory leak)
- Clear the gaps left when writing beyond the end of file
- Fix the reference count on directories in order to send releasedir (memory 
leak)

I have still not found why the file size is limited to 2GB.

Please note I am not the maintainer or packager of fuse, so whoever wants to 
take it over would be welcome.

Regards

Jean-Pierre



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



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

Re: [oi-dev] New prestable release - oi_151a1 0.151.1.1

[Alasdair Lumsden]

Nice work JT!

This is very promising indeed :-)

On 16 Jan 2012, at 19:58, Jon Tibble wrote:

> Hi all,
> 
> Today I turned on the repo and made the tarball of said repo available for 
> the first prestable release.  Depending on how we go porting security fixes 
> to this or the rest of the community gets on sorting experimental into 
> looking like a sensible oi_151a replacement will determine which becomes OI's 
> first stable release.
> 
> The release notes and more information can be found here:
> http://wiki.openindiana.org/oi/oi_151a_prestable0+Release+Notes
> 
> There won't be ISOs for this one but there will for a near future prestable.  
> The aim of these is to be more frequent so I don't think it is really worth 
> producing ISOs for every release but rest assured there will be some tested 
> before anything goes stable.
> 
> Unless something particularly funky goes in you'll probably see illumos get 
> bumped every prestable, other than that I'll welcome mainly security fixes.
> 
> Enjoy,
> 
> JT
> 
> ___
> 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] Building Userland on Solaris 10

[Alasdair Lumsden]

On 01/ 4/12 07:09 PM, Bayard G. Bell wrote:

On Wed, 2012-01-04 at 14:51 +, Alasdair Lumsden wrote:

Hmm, that's going to be much harder! Effectively you have the
"bootstrap" issue we originally faced when doing this, where you don't
have sufficiently new versions of python, expat, libxml2, etc to get
pkg5 to build easily.


Is using an Oracle-provided layered IPS rather than having to bootstrap
a build at the version we use an option for Solaris 10 support?


It might, if it's new enough. I found some versions of Glassfish shipped 
with IPS but it was quite old.


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

Re: [oi-dev] Building Userland on Solaris 10

[Alasdair Lumsden]

Hi John,

On 01/ 4/12 02:21 PM, John Center wrote:

What would I need to do to build Userland on Sol10/SPARC?  I'm prepared
to adapt whatever is needed to get this to work.


Hmm, that's going to be much harder! Effectively you have the 
"bootstrap" issue we originally faced when doing this, where you don't 
have sufficiently new versions of python, expat, libxml2, etc to get 
pkg5 to build easily.


You will want to follow my rough guide here:

http://blogs.everycity.co.uk/alasdair/2011/01/building-ips-pkg5-on-solaris-10/

Once you have a working pkg5, you should be able to use the s10-userland 
framework to build stuff, although you'll be missing gcc and lots of 
other important stuff.


It's not going to be easy, and most of the build recipes in s10-userland 
assume x86 so I have no idea how well they'll work with SPARC. But we'll 
be happy to accept commits to make stuff work on SPARC and eventually a 
pkg5 bootstrap tarball for SPARC.


If this all seems like too much work, you might want to consider OpenCSW?

Cheers,

Alasdair

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

Re: [oi-dev] Addition of GeoIP to oi-build

[Alasdair Lumsden]

Hi Jeppe,

On 12/19/11 10:40 PM, Jeppe Toustrup wrote:


Could somebody please look through this change set, and see if
everything looks okay?
https://bitbucket.org/Tenzer/oi-build/changeset/7ca13070e339


Great stuff - thanks for doing this!

A few comments:

1. Could you replace the OpenSolaris CDDL notice with the Illumos one

2. Was this taken from userland-gate or written by yourself? If taken 
from userland-gate, you can keep the Oracle copyright in the Makefile 
and .p5m, otherwise remove it. In either case, please do add your own 
copyright line.


3. Use a transform at the top to set etc/GeoIP.conf and GeoIP.dat 
preserve=true, via:


 default preserve true>
 default preserve true>

This will ensure that if someone edits the conf or replaces the GeoIP 
database that it won't be wiped out on a "pkg update"


Apart from that, it looks good! Thank you very much for contributing this.

Cheers,

Alasdair



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

[oi-dev] Weekly Meeting on Tuesday Dec 20th at 19:00 UTC

[Alasdair Lumsden]

Hi All,

We should have a quick weekly meeting before the Christmas festive 
period kicks in - I've set the time at 19:00 so igork from Nexenta can 
join us, it will be 11pm for him then.


There is no fixed agenda, but I imagine it will revolve around 
illumos-userland, Illumian and getting things moving again as 
development has been quite quiet recently.


Hopefully "see" you all on Tuesday!

Cheers,

Alasdair

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

[oi-dev] Heads Up: CDN turned off, mod_bw enabled

[Alasdair Lumsden]

Hi All,

Due to the high cost of hosting OpenIndiana's dlc.openindiana.org on the 
CDN, I have decided to instead discontinue this in favour of getting 
worldwide mirrors online.


As of now, dlc.openindiana.org points at the origin server in the UK 
instead of the CDN. I have enabled mod_bw in Apache and restricted 
downloads of the .iso/.usb files to 250KB/sec.


We will be contacting worldwide mirrors asking them to mirror 
dlc.openindiana.org via rsync (which is not rate limited) and once we 
have a reasonable number we can update the website to list these. And 
obviously we still have the torrents too.


Thanks,

Alasdair

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

[oi-dev] Outstanding RTI's for oi-build

[Alasdair Lumsden]

Hi All,

Are there any outstanding RTI's for oi-build?

We could do with a process of tracking these - Trisk mentioned at the 
last meeting the possibility of getting a new status type like "Awaiting 
RTI" added to Redmine - Trisk did you have any luck with this?


Cheers,

Alasdair

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

Re: [oi-dev] 1818 - Upgrade m4 to latest version

[Alasdair Lumsden]

Hi Bart,

On 11/27/11 02:07 PM, Bart Coddens wrote:

Hi List,

Can this be reviewed ?

https://bitbucket.org/bcoddens/oi-build/changeset/06a34066db9b

it published fine on my machine and works without problems.


Many thanks for providing this. GNU themselves on the Autoconf website 
say "Autoconf works better with GNU M4 version 1.4.14 or later" so 
updating from 1.4.12 to 1.4.16 sounds like a good move.


I don't know if there will be any build consequences of doing this, 
however the whole point of /experimental is to find out.


Only one minor nitpick before a +1, could you add your Copyright to the 
Makefile? Also, what was the reasoning behind removing the opensolaris 
arc_url?


Cheers,

Alasdair

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