Nick Zivkovic wrote:
> On Thu, Sep 6, 2012 at 4:35 AM, Joerg Schilling
> wrote:
> > "Andrew M. Hettinger" wrote:
> >
> >> That said, I think what Nick was talking about was not a build failure, but
> >> common issues IPS itself can have. I've seen a few (rare) times where it
> >> will just spit
On Thu, Sep 6, 2012 at 4:35 AM, Joerg Schilling
wrote:
> "Andrew M. Hettinger" wrote:
>
>> That said, I think what Nick was talking about was not a build failure, but
>> common issues IPS itself can have. I've seen a few (rare) times where it
>> will just spit out a call-stack. Haveing a goto pag
"Andrew M. Hettinger" wrote:
> That said, I think what Nick was talking about was not a build failure, but
> common issues IPS itself can have. I've seen a few (rare) times where it
> will just spit out a call-stack. Haveing a goto page of potental problems
> and fixes/workarounds would help.
Ap
Francois Dion wrote on 09/04/2012 07:29:09 PM:
>
> On Tue, Sep 4, 2012 at 5:38 PM, Nick Zivkovic
wrote:
> >>> 2) document every single IPS failure and either fix the
> >>> packages or the IPS code (depend on what caused the failure), and
> >>
> >> First thought here is that it needs to be in the
Joerg Schilling wrote:
Andrew Gabriel wrote:
Nick Zivkovic wrote:
Agreed. Also, I see that /opt and /usr/$consolidation overlap in terms
of their purpose.
For example we have /usr/X11. According to `man filesystem` /opt is
meant to hold add-on/third-party software.
/opt was
Alasdair Lumsden wrote:
> 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
>
> use
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-p
Alan Coopersmith wrote:
> >> Which is why it was completely thrown out and Userland started with a
> >> new design from scratch.
> >
> > But as this did not exist before Spring 2010, I asume that the new system
> > is
> > not able to create native Svr4 packages.
>
> Correct. Userland was desi
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 pre
On Wed, 5 Sep 2012, Andrew Stormont wrote:
The only thing you really need for extensions to build is the -I bit. The rest
is Sun Studio pedantry.
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
Alasdair Lumsden wrote:
> 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
On 5 Sep 2012, at 21:33, Alasdair Lumsden wrote:
> 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.
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
On Wed, 5 Sep 2012, Alasdair Lumsden wrote:
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
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 har
On 09/ 5/12 01:09 PM, joerg.schill...@fokus.fraunhofer.de wrote:
> Alan Coopersmith wrote:
>
>> On 09/ 5/12 11:49 AM, joerg.schill...@fokus.fraunhofer.de wrote:
>>> I asume that what you call "userland" is the successor for "sfw".
>>
>> Yes.
>>
>>> The buildsystem for sfw is a nightmare
>>
>> Whi
Alan Coopersmith wrote:
> On 09/ 5/12 11:49 AM, joerg.schill...@fokus.fraunhofer.de wrote:
> > I asume that what you call "userland" is the successor for "sfw".
>
> Yes.
>
> > The buildsystem for sfw is a nightmare
>
> Which is why it was completely thrown out and Userland started with a
> new de
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.
Th
On Wed, Sep 5, 2012 at 2:43 PM, Alan Coopersmith
wrote:
> On 09/ 5/12 10:55 AM, Andrew Gabriel wrote:
>> Nick Zivkovic wrote:
>>> Basically, I'm asking if it is better to have one convention
>>> (everything in /usr/$consolidation) instead of two (some things in
>>> /usr/$consolidation and others i
On 09/ 5/12 10:55 AM, Andrew Gabriel wrote:
> Nick Zivkovic wrote:
>> Basically, I'm asking if it is better to have one convention
>> (everything in /usr/$consolidation) instead of two (some things in
>> /usr/$consolidation and others in /opt/$consolidation)?
>>
>
> There's never been any rule
On 09/ 5/12 11:49 AM, joerg.schill...@fokus.fraunhofer.de wrote:
> I asume that what you call "userland" is the successor for "sfw".
Yes.
> The buildsystem for sfw is a nightmare
Which is why it was completely thrown out and Userland started with a
new design from scratch.
--
-Alan Coo
Bob Friesenhahn wrote:
> On Wed, 5 Sep 2012, Joerg Schilling wrote:
> >
> > As a nice hint: The new Bourne Shell compiles and runs on Cygwin (thanks to
> > no
> > longer depending on sbrk(2)) and if you use it to interpret autoconf
> > scripts,
> > this is 3x faster than bash.
>
> This sounds g
Andrew Gabriel wrote:
> Nick Zivkovic wrote:
> > Agreed. Also, I see that /opt and /usr/$consolidation overlap in terms
> > of their purpose.
> >
> > For example we have /usr/X11. According to `man filesystem` /opt is
> > meant to hold add-on/third-party software.
> >
>
> /opt was meant for un
Andrew Stormont wrote:
>
> On 5 Sep 2012, at 18:04, Nick Zivkovic wrote:
>
> > I think that Andrew want to use a unified build system, instead of the
> > loose confederation of radically different systems that's currently in
> > use.
> >
> > I agree. A unified build system is necessary. The onl
On Wed, 5 Sep 2012, Joerg Schilling wrote:
As a nice hint: The new Bourne Shell compiles and runs on Cygwin (thanks to no
longer depending on sbrk(2)) and if you use it to interpret autoconf scripts,
this is 3x faster than bash.
This sounds great. How does its performance compare with 'dash'?
On Wed, Sep 5, 2012 at 12:56 PM, Alasdair Lumsden wrote:
> 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.
>>
>>
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 com
Nick Zivkovic wrote:
Agreed. Also, I see that /opt and /usr/$consolidation overlap in terms
of their purpose.
For example we have /usr/X11. According to `man filesystem` /opt is
meant to hold add-on/third-party software.
/opt was meant for unbundled software. Ideally, it should be empty
im
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).
On Wed, Sep
On 5 Sep 2012, at 18:04, Nick Zivkovic wrote:
> I think that Andrew want to use a unified build system, instead of the
> loose confederation of radically different systems that's currently in
> use.
>
> I agree. A unified build system is necessary. The only question is:
> what should it be?
>
I think that Andrew want to use a unified build system, instead of the
loose confederation of radically different systems that's currently in
use.
I agree. A unified build system is necessary. The only question is:
what should it be?
Makefile-based, like ports/pkgsrc/oi-build?
specfile-based?
tcl
Andrew Hettinger
http://Prominic.NET || ahettin...@prominic.net
Tel: 866.339.3169 (toll free) -or- +1.217.356.2888 x.110 (int'l)
Fax: 866.372.3356 (toll free) -or- +1.217.356.3356(int'l)
Alasdair Lumsden wrote on 09/04/2012 05:39:58 PM:
> On 04/09/2012 22:42, mag...@yonderway.c
On Wed, Sep 5, 2012 at 4:18 AM, Jim Klimov wrote:
> 2012-09-04 22:25, Andrew M. Hettinger пишет:
>
>> was kept in /bin and /sbin that did not depend on anything. This was
>> done to allow you to NFS mount everything else. IIRC the decision was
>> made to go ahead and make them dynamicly linked bec
On Tue, Sep 4, 2012 at 5:39 PM, Alasdair Lumsden wrote:
> 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 IP
On 05/09/2012 01:30, Alasdair Lumsden wrote:
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
Jonathan Adams wrote:
> >
> > ftp://ftp.berlios.de/pub/schily/
> >
>
> do you have a patch/diffs to source supplied elsewhere? Is this
> project stored in a git repository, or even in an SCCS tar ball
> separate to the Schillix-ON project?
P.S. if you like to check the latest man page, h
Jonathan Adams wrote:
> On 5 September 2012 11:14, Joerg Schilling
> wrote:
> > Linking /sbin/sh to ksh definitely was a mistake and I plan to fix this in
> > SchilliX-ON since a longer time. Before I introduce my fix, I will first
> > replace the unmaintained Bourne Shell from Sun sources by th
On 5 September 2012 11:14, Joerg Schilling
wrote:
> Linking /sbin/sh to ksh definitely was a mistake and I plan to fix this in
> SchilliX-ON since a longer time. Before I introduce my fix, I will first
> replace the unmaintained Bourne Shell from Sun sources by the current
> maintained one which y
Jim Klimov wrote:
> I've recently redone this on my laptop with no problems, following my
> own logs on wiki and bugtracker; the only substantial blocker was and is
> the "/sbin/sh" being a symlink to "../usr/bin/ksh" or somesuch. System
> fails to boot itself when /usr is separate. Replacing thi
2012-09-04 22:25, Andrew M. Hettinger пишет:
was kept in /bin and /sbin that did not depend on anything. This was
done to allow you to NFS mount everything else. IIRC the decision was
made to go ahead and make them dynamicly linked because noone NFS mounts
them anymore anyway, and it meant we had
On Tue, Sep 4, 2012 at 5:38 PM, Nick Zivkovic wrote:
>>> 2) document every single IPS failure and either fix the
>>> packages or the IPS code (depend on what caused the failure), and
>>
>> First thought here is that it needs to be in the bug tracker, but that may
>> not be easily accessible either
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
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
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
> packag
On Tue, Sep 4, 2012 at 1:25 PM, Andrew M. Hettinger
wrote:
> My thoughts. Remember, they are probably only worth what you paid for them!
> ;p
>
> Nick Zivkovic wrote on 09/01/2012 10:42:14 AM:
>
>
>>
>> Yes. I am more interested in contributing drivers and the like. As far
>> as packages go, to b
My thoughts. Remember, they are probably only worth what you paid for
them! ;p
Nick Zivkovic wrote on 09/01/2012 10:42:14 AM:
>
> Yes. I am more interested in contributing drivers and the like. As far
> as packages go, to be honest, I've experienced torture at the hands of
> IPS (though that cou
On 09/ 2/12 10:47 AM, Nick Zivkovic wrote:
> On Sun, Sep 2, 2012 at 11:17 AM, Magnus wrote:
>> On Sep 2, 2012, at 11:18 AM, Alan Coopersmith wrote:
>>> On 09/ 2/12 07:00 AM, Adam Števko wrote:
IPS is documented in the official IPS Developer Guide located somewhere in
the OpenSolaris/Ora
> OpenIndiana aims to be a general-purpose traditional distribution usable on
> server or desktop, not a hypervisor
> (although kvm and qemu packages can be found in the repositories).
I don't see why OpenIndiana can't be _both_. This is software after
all. More choices means more users means pot
On Sep 2, 2012, at 11:18 AM, Alan Coopersmith wrote:
> On 09/ 2/12 07:00 AM, Adam Števko wrote:
>> IPS is documented in the official IPS Developer Guide located somewhere in
>> the OpenSolaris/Oracle page. I went it through lately and I find it a good
>> source for learning to work with IPS, in
On 09/ 2/12 07:00 AM, Adam Števko wrote:
> IPS is documented in the official IPS Developer Guide located somewhere in
> the OpenSolaris/Oracle page. I went it through lately and I find it a good
> source for learning to work with IPS, in general.
http://hub.opensolaris.org/bin/download/Project+
Hi Nick,
On Sep 1, 2012, at 5:42 PM, Nick Zivkovic wrote:
> Yes. I am more interested in contributing drivers and the like. As far
> as packages go, to be honest, I've experienced torture at the hands of
> IPS (though that could very easily be my fault), and am reluctant go
> near it. For exampl
na, e.g maintaining some packages, fixing broken things etc?
>
> Cheers,
>
> Adam
>
> Begin forwarded message:
>
> From: Nick Zivkovic
> Subject: [oi-dev] Desktop Illumos Still Matters
> Date: September 1, 2012 7:17:01 AM GMT+02:00
> To: oi-dev@openindiana.org, disc..
I was just reading through the oi-dev archives (about the resignation
of the OI lead) where a former Sun engineer, claimed that the efforts
made by sun to port OpenSolaris to the desktop/laptop platforms (by
adding wifi support, by making a new audio system, etc), only hurt Sun
in the long run, and
53 matches
Mail list logo
