Hi everyone!

With some tinkering of the build system I've taken the onnv-gate build
process and almost seamlessly wrapped it in a modular way. The proof
was when the kernel built and everything installed successfully last night.

I was somewhat surprised that you must use gas from binutils 2.15. I
was overriding aw by explicitly setting it and patching as I hit
incompatibilities, but I'm not sure the amount of work needed was worth
the gain.

-----------
Here's where things get tricky..

There's two options
1) Use my overridden and experimental amd64 only build process and
fix the regressions (2 major ones I know of currently)
2) Build a multilib setup just as Sun currently does it, revert all
my amd64 stuff and more slowly integrate it

With the binary packages rolling I'm looking forward to spinning an iso
before FOSDEM, but not sure what others will find most useful..?

With option #2 I can make a script to remove my changes and possible
spin an iso in the next week. Without additional help the pure amd64
environment could be 1-2 weeks or more before it even minimally boots
and works correctly.

Both options still have the following benefits (or disadvantages
depending how you look at it)

a) onnv-gate is packaged in a very fine grained way
b) under new ospkg building and packaging framework
c) We could have a continuous build server to test any bad commits
from Sun
d) We could more easily test the CR's dropped
e) We're completely free of SVR4
f) The difference between snv_10x and svn_10y will be trivial to roll
updates.
g) We'll have a place to apply patches which upstream won't accept
w/o an SCA (eg interface enhancements from J?rg, Moinak, myself and all
the other devs)
h) We can test new compilers/toolchains/optimizations very easily and
adjust where we are forced to
i) We can start our own community QA work
j) For any distro who uses our packaging we can all work together on
bug fixes, new drivers etc..
k) Anyone who wants to work on the fully open libc will be able to
easily pull a full working dev environment

-------------
Here's the catch
b) we still need xorg built (at least the headers) so that I can
build icedtea6
c) binary package support isn't complete, but from source does work
great though
d) java is and will remain broken until icedtea6 is built which is
after xorg

Some people have offered to help on all this, but so far it's only minor
or I'm blocking things by not giving enough details I think.. I've
tried to file bug reports/RFE at bugs.osunix.org and updating the TODO
list(s) on www.osunix.org, but we need more help from the community and
coordination from those actually doing work to avoid duplication.

So.. What do you want. Options 1) or 2)?

Thanks

./Chrisotpher

#ospkg irc.freenode.net

Search Discussions

  • Cyril Plisko at Jan 24, 2009 at 6:51 pm

    On Sat, Jan 24, 2009 at 4:48 PM, "C. Bergstr?m" wrote:

    Hi everyone!

    Hi Christopher,

    [...]
    Some people have offered to help on all this, but so far it's only minor or
    I'm blocking things by not giving enough details I think.. I've tried to
    file bug reports/RFE at bugs.osunix.org and updating the TODO list(s) on
    www.osunix.org, but we need more help from the community and coordination
    from those actually doing work to avoid duplication.
    I am not sure what other thing, but there is something hat bothers me.
    You seems to be investing heavily into that project of yours, but it
    is not clear (at least to me) what is the ultimate goal (or goals) of
    that builds that you undertake ?
    I think if we can answer the question why are we doing this it will be
    easier to choose how to get to our goals. Please, do not take this as
    an attempt to stall the process, I just think that clear statement of
    target and intention will help people contribute actually.

    Now, if you don't mind, I have a couple of question:

    a) onnv-gate is packaged in a very fine grained way

    Can you please elaborate more on that ? What package boundaries would
    you define to achieve that ?

    b) under new ospkg building and packaging framework
    c) We could have a continuous build server to test any bad commits from Sun

    What criteria would you use to detect these "bad commits from Sun" ?

    d) We could more easily test the CR's dropped

    That puzzles me. What is dropped CR ?

    e) We're completely free of SVR4

    Are you referring to SVR4 packaging or something else ?

    f) The difference between snv_10x and svn_10y will be trivial to roll updates.

    Exactly how ? Are you talking about ON consolidation as delivered by
    onnv repo or the whole SNV ?

    g) We'll have a place to apply patches which upstream won't accept
    w/o an SCA (eg interface enhancements from J?rg, Moinak, myself and
    all the other devs)

    That one gets my vote on a spot :) !

    h) We can test new compilers/toolchains/optimizations very easily and
    adjust where we are forced to
    i) We can start our own community QA work
    j) For any distro who uses our packaging we can all work together on
    bug fixes, new drivers etc..
    k) Anyone who wants to work on the fully open libc will be able to
    easily pull a full working dev environment

    h) - k) are pretty clear (but requires significant (titanic, I would
    say) effort to actually implement)

    --
    Regards,
    Cyril
  • Christopher Bergström at Jan 24, 2009 at 7:58 pm
    Hi Cyril,

    Responses inline..

    Cyril Plisko wrote:
    On Sat, Jan 24, 2009 at 4:48 PM, "C. Bergstr?m"
    wrote:
    Hi everyone!

    Hi Christopher,

    [...]

    Some people have offered to help on all this, but so far it's only minor or
    I'm blocking things by not giving enough details I think.. I've tried to
    file bug reports/RFE at bugs.osunix.org and updating the TODO list(s) on
    www.osunix.org, but we need more help from the community and coordination
    from those actually doing work to avoid duplication.
    I am not sure what other thing, but there is something hat bothers me.
    You seems to be investing heavily into that project of yours, but it
    is not clear (at least to me) what is the ultimate goal (or goals) of
    that builds that you undertake ?
    I have tried to dodge this question because instead of creating yet
    another distro I wanted to unit the current leaders and all work
    together. For this goal I went to Berlin and met with J?rg Schilling,
    I've talked with Moinak extensively and most of the other community
    leaders. On most any day I could probably ask any of them for small
    help and get it if they have time. The 2nd part of this is like herding
    cats though and trying to reduce the amount of duplicated work.

    After some recent discussions these things will start to change:

    1) OSUNIX will become yet another distro.. (I'd like others with
    similar goals to merge with us, but can't save the world if they don't)
    2) shipping a zone != shipping a hw release
    3) marketing
    I think if we can answer the question why are we doing this it will be
    easier to choose how to get to our goals. Please, do not take this as
    an attempt to stall the process, I just think that clear statement of
    target and intention will help people contribute actually.
    Oh.. I know you're very active in the opensolaris community and don't
    take this as an attempt to offset at all, but just wanting honest
    clarification.
    Now, if you don't mind, I have a couple of question:

    a) onnv-gate is packaged in a very fine grained way

    Can you please elaborate more on that ? What package boundaries would
    you define to achieve that ?
    This is mostly directory based with a few exceptions
    usr/src/uts/ == kernel, but I'm also going to glob the base directory
    setup in there as well as the header generation..
    (header generation I've thought to break out, but opted against it for
    now. Also I'd like to micro package the kernel, but that will require
    Makefile changes and more work)
    usr/src/lib/* == each gets an individual package
    usr/src/cmd/* == each gets an individual package

    Each package is by default tightly coupled per snv_xxx version. So
    snv_107 libc won't get mixed with snv_108 kernel or any of the micro
    packages. I've also defined a meta build onnv-gate which will resolve
    all dependencies and install it just as if you were to run nightly.

    Part of the reasoning behind this micro packaging is that if you have a
    bug in libavl.so..
    a) Knowing exactly where that souce/package is will help developers
    b) *IF* there's ever a buggy sun ld (which snv_106 has) you'll be
    able to more easily work around this by overriding that package to
    another version if a patch isn't available
    c) patch management. Since we *are* forking Sun's onnv-gate. The
    better the code to patch tracking ratio the easier it is to
    track/understand/review.

    I have a more reasons which I can go further into detail about.
    b) under new ospkg building and packaging framework
    c) We could have a continuous build server to test any bad commits from Sun

    What criteria would you use to detect these "bad commits from Sun" ?
    bad commit initially will be a change which breaks the build process.
    This should *not* happen, but I have no intention to follow exactly as
    Sun does and as a result something could break. (compiler, 64bit
    cleanness, 3rd party drivers.. etc)

    automated QA will come as well, but that's still in the planning phase
    d) We could more easily test the CR's dropped

    That puzzles me. What is dropped CR ?
    Code review.. A perfect example is

    CR 6418042

    Stolen from zfs-discuss
    "
    My results are much improved, on the order of 5-100 times faster
    (either over Mbuffer or SSH). Not only do snapshots begin sending
    right away (no longer requiring several minutes of reads before
    sending any data), the actual send will sustain about 35-50MB/sec over
    SSH, and up to 100MB/s via Mbuffer (on a single Gbit link, I am
    network limited now, something I never thought I would say I love to
    see!)."
    So.. wouldn't it be nice if mere mortals could test it? The current process for community testing for non-developers is probably at best scary. Using the new packaging I plan to make it easier to add/roll-back even the most bleeding edge stuff.

    e) We're completely free of SVR4

    Are you referring to SVR4 packaging or something else ? Correct
    f) The difference between snv_10x and svn_10y will be trivial to roll updates.

    Exactly how ? Are you talking about ON consolidation as delivered by
    onnv repo or the whole SNV ?
    SNV.. Anything they push in onnv-gate and tag with snv_ minutes or at
    most hours later will be packaged and released with an appropriate QA tag.
    g) We'll have a place to apply patches which upstream won't accept
    w/o an SCA (eg interface enhancements from J?rg, Moinak, myself and
    all the other devs)

    That one gets my vote on a spot :) !
    As it should.. Mirror is up and if you're in europe will be faster than
    Sun's main onnv-gate.. I'm trying to work out commit details for that
    and will start in the near future. To me this isn't something I take
    lightly since it's the core code and ensuring stability/security is a
    very high priority for me.
    h) We can test new compilers/toolchains/optimizations very easily and
    adjust where we are forced to
    i) We can start our own community QA work
    j) For any distro who uses our packaging we can all work together on
    bug fixes, new drivers etc..
    k) Anyone who wants to work on the fully open libc will be able to
    easily pull a full working dev environment

    h) - k) are pretty clear (but requires significant (titanic, I would
    say) effort to actually implement)
    You'd be surprised what a couple determined people can achieve.. Once
    the community is rolling I'd like to find a way to sponsor our own
    development or gain the interest of those commercially invested in
    OpenSolaris technology to look at us for help achieving their goals.
    For university students I could see it being a lot easier to find a
    sponsor to help walk them through the code. Increasing the public
    documentation on various aspects of the code and overall doing a lot
    more than what's being done. Which for many cases isn't much more than
    a cheap repackaging effort.

    I hope this brings a bit more clarity. If you have the time I'd love
    more feedback on your goals and or help with making sure questions are
    answered.

    If you or anyone else wants to drop by and say hi (I'm codestr0m) on
    irc.freenode.net #ospkg please feel free. Sometimes OT, but usually the
    best OpenSolaris technology channel around.

    ./Christopher

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouposunix-dev @
categoriesopensolaris
postedJan 24, '09 at 2:48p
activeJan 24, '09 at 7:58p
posts3
users2
websiteopensolaris.org

People

Translate

site design / logo © 2017 Grokbase