Re: GNU libc on OpenSolaris
David Bartley wrote: Hello, I've been working on porting GNU libc (glibc) to OpenSolaris (see [0] for source code and other downloads). I've also ported NPTL (the glibc thread library), using the corresponding OpenSolaris syscalls. I haven't benchmarked much, but I suspect speed should be comparable to "native" OpenSolaris. At this point I have a working chroot with a number of packages installed and working, and I hope to have a zone booting soon. Xorg, GNOME, and gdb all work. I also have a number of Solaris binaries working, including truss, dladm, zfs, and zpool. (I haven't tried, but it should be fairly straightforward to get dtrace working.) In order to get these working, I implemented additional OpenSolaris extensions (mostly trivial syscall wrappers). Examples are the functions defined in ucred.h, priv.h, and sys/pset.h. Since nexenta is trying to be "OpenSolaris with the GNU userland", it makes sense to use glibc. This would also solve the legal problem that Debian had with linking Sun's libc with dpkg [1]. glibc is licensed under LGPL with a linking exception, so linking CDDL code against the glibc is also legal. In keeping with past glibc ports (e.g. kFreeBSD, kNetBSD), I've used the target string i486-kopensolaris-gnu (the 64-bit target would be x86_64-kopensolaris-gnu). If you want to test this out in a chroot, there's a bunch of pre-built i386 binaries available [2] that can be just untarred into a directory. You'll also need to mount /proc, /dev, and /devices in the chroot via "lofs" (this won't be needed if done in a zone). Many applications will require OpenSolaris headers to build, which can just be copied from an OpenSolaris/Nexenta box (just don't overwrite any headers installed by glibc). Just because you can.. doesn't mean you should.. I mean I feel like saying.. "Look.. no hands" :P Just add zfs or comparable support to the linux kernel and be happy. I mean really.. Otherwise.. yeah.. great work.. ./C ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
New community based development list
Hi all.. I've been tearing apart onnv-gate for a couple months now and have a very clear idea of what it would take to build an entirely from source OpenSolaris technology based distribution. I'll probably post patches and details of my work at a new development list I've setup. I know Nexenta has some core developers already, but for anyone who has questions about the code this is the place to ask. Visit http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/osunix-dev or put subscribe in the subject and send a quick email to [EMAIL PROTECTED] Summary: This list provides a place for new and old OpenSolaris technology developers to collaborate, share ideas, patches and peer review entirely free of constraints. Our major goal is to bring together the pockets of developers to create a sustainable community and drive innovation. Cheers, ./Christopher ps.. ( ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: -lgssapi found at link time, but not at run time
Anil Gulecha wrote: Hi, configure on curl fails as follows (from config.log) .. configure:31776: i386-pc-solaris2.11-gcc -c -g -O2 -I/usr/include conftest.c >&5 configure:31782: $? = 0 configure:31802: result: yes configure:31818: checking run-time libs availability configure:31846: i386-pc-solaris2.11-gcc -o conftest -g -O2 -I/usr/include -Wl,-Bsymbolic-functions -L/usr/lib -lgssapi conftest.c -lldap -lsocket -lnsl -lgssapi >&5 /usr/bin/ld: cannot find -lgssapi collect2: ld returned 1 exit status I can see that the libraries are present under /usr/lib: [EMAIL PROTECTED]:~/src/openssl/curl/curl-7.18.0# ls -l /usr/lib/libgss* lrwxrwxrwx 1 root root 11 Dec 6 21:56 /usr/lib/libgss.so -> libgss.so.1 -rwxr-xr-x 1 root bin 76700 Dec 4 07:52 /usr/lib/libgss.so.1 lrwxrwxrwx 1 root root 18 Dec 6 21:57 /usr/lib/libgssapi.so.2 -> libgssapi.so.2.0.0 -rw-r--r-- 1 root root 160428 Nov 25 17:12 /usr/lib/libgssapi.so.2.0.0 lrwxrwxrwx 1 root root 21 Dec 9 09:04 /usr/lib/libgssapi_krb5.so -> libgssapi_krb5.so.2.2 lrwxrwxrwx 1 root root 21 Dec 9 09:04 /usr/lib/libgssapi_krb5.so.2 -> libgssapi_krb5.so.2.2 -rw-r--r-- 1 root root 171860 Dec 9 03:57 /usr/lib/libgssapi_krb5.so.2.2 lrwxrwxrwx 1 root root 16 Dec 9 09:04 /usr/lib/libgssrpc.so -> libgssrpc.so.4.0 lrwxrwxrwx 1 root root 16 Dec 9 09:04 /usr/lib/libgssrpc.so.4 -> libgssrpc.so.4.0 -rw-r--r-- 1 root root 92868 Dec 9 03:57 /usr/lib/libgssrpc.so.4.0 Any idea why configure is failing? Crazy idea and best practice in general is to also add -R to your ld flags.. This can help the linker find the runtime libs.. failing this posting the cc -# (if you're using sun cc) or a few other things could give more details.. ./C ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: -lgssapi found at link time, but not at run time
Anil Gulecha wrote: Yup.. codestrOm helped me with that. It now fails at a point where we can proceed once heimdal is rebuilt (my other mail on dh_shlibdeps). I have a high level of interest in possibly helping with the krb5/heimdal as it's something on my eventual TODO list.. I've talked with the Sun maintainer about it and the best long term approach is to Firstly, choose to either use upstream (Sun) or vanilla.. There are some added features/benefits to using the Sun version which is what I thought most maintainers would naturally opt for. However, the maintenance of this w/o the help of Sun is a pita. I think the middle ground is a 1x hit of generating a patch against vanilla which can be maintained against any patches provided by Sun and any possible security/bug related issues provided by the vendor. I've got some notes on it if anyone would like to take a poke at it. Topics like this will surely come up on the new list.. ./C ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: New community based development list
Erast Benson wrote: Very interesting development! I like the idea of modular approach to build ON. I do believe that kernel, libc, networking all could be delivered as separate component rather than monolitic jumbo tar drop... And yes, we need to drop closed bins right from the start, i.e. to stimulate its open source alternatives... Yet another reason to split ON. Hi Erast, Please email me offlist so we can coordinate infra issues since I already have a domain and extensive plans. This will avoid confusion and duplicate work. I've also dropped opensolaris-discuss from the cc. For the technical side of this lets continue on the osunix-dev list. Cheers, ./C ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
nexenta-on source package
Hi guys.. I'm trying to find the latest nexenta-on source package.. Can you push that somewhere please.. I'm also curious why it's not available already? Thanks ./C ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: nexenta-on source package
Erast Benson wrote: That was me - I accidentally uploaded the package without source. I'm planning to push it tonight/tomorrow with more CIFS/AD fixes included. Ping.. ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: nexenta-on source package
Erast Benson wrote: Just uploaded ( subscribe to nexenta-chan...@nexenta.org for timely upload notifications ) Yeah, but still this should be uploaded at the same time as the binary and also didn't think you'd mind the friendly reminder. ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Status update of fully open libc
Hi all.. Jörg and I had a really interesting conversation last night and I wanted to publicly share my progress and hope Jörg and others can write down more details so we can start to make an actual plan. To start this is the list of symbols/functions that I know are left in 32bit libc that need reimplementing.. (need to noop them and see if there's anything behind, but) _putwc pics/putwchar.o _scrwidth pics/doprnt.o wcstombspics/strtows.o strcoll pics/scandir.o __iswlower /onnv-gate/proto/root_i386/lib/libc_i18n.a(iswctype.o) strftimepics/cftime.o fnmatch pics/glob.o __mbst_get_lc_and_fppics/doprnt_w.o _set_orientation_wide pics/__fputwc_xpg5.o --- I can make a reproducible way to get this far in my packaging system or something more generic if needed.. Roughly I did this.. clone onnv-gate.. Get the 2007 opensolaris gsoc project from John Sonnenschein If you're using sun cc then you'll have to make some changes to the fbsd code gatetome.patch will need some changes. (this should be obvious) copy the resulting libc.a into the correct place build lib/libc Once the project I'm working on boots and pulls network I'll release a livecd with as much of a development environment as will fit.. Thanks ./Christopher ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: [OSUNIX-dev] Status update of fully open libc
Mark Martin wrote: C. Bergström wrote: Hi all.. Jörg and I had a really interesting conversation last night and I wanted to publicly share my progress and hope Jörg and others can write down more details so we can start to make an actual plan. To start this is the list of symbols/functions that I know are left in 32bit libc that need reimplementing.. (need to noop them and see if there's anything behind, but) _putwc pics/putwchar.o _scrwidth pics/doprnt.o wcstombspics/strtows.o strcoll pics/scandir.o __iswlower /onnv-gate/proto/root_i386/lib/libc_i18n.a(iswctype.o) strftimepics/cftime.o fnmatch pics/glob.o __mbst_get_lc_and_fppics/doprnt_w.o _set_orientation_wide pics/__fputwc_xpg5.o --- Good work, thanks guys! I can make a reproducible way to get this far in my packaging system or something more generic if needed.. Roughly I did this.. clone onnv-gate.. Get the 2007 opensolaris gsoc project from John Sonnenschein If you're using sun cc then you'll have to make some changes to the fbsd code gatetome.patch will need some changes. (this should be obvious) copy the resulting libc.a into the correct place build lib/libc Once the project I'm working on boots and pulls network I'll release a livecd with as much of a development environment as will fit.. Which architectures? Is this a hint at another distro or is this OpenSolaris(tm) 2009.1/64bit clean? By the project I just meant my modular onnv-gate work.. pushing that into a livecd shouldn't be too hard and I think for the curious it would make things a lot easier.. (Yes I am working on 64bit clean, but that's another thread) ./C ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: [OSUNIX-dev] Status update of fully open libc
Joerg Schilling wrote: "C. Bergström" wrote: I can make a reproducible way to get this far in my packaging system or something more generic if needed.. Roughly I did this.. clone onnv-gate.. Get the 2007 opensolaris gsoc project from John Sonnenschein If you're using sun cc then you'll have to make some changes to the fbsd Could you please post a URL fot the code? 18n Emancipation Project http://google-summer-of-code-2007-opensolaris.googlecode.com/files/John_Sonnenschein.tar.gz (I've not looked at this, but while I'm there grabbing links may as well include it) Porting fft http://google-summer-of-code-2007-opensolaris.googlecode.com/files/RaymondThomas_Harper.tar.gz ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: [OSUNIX-dev] Status update of fully open libc
Joerg Schilling wrote: "C. Bergström" wrote: Could you please post a URL fot the code? 18n Emancipation Project http://google-summer-of-code-2007-opensolaris.googlecode.com/files/John_Sonnenschein.tar.gz (I've not looked at this, but while I'm there grabbing links may as well include it) Porting fft http://google-summer-of-code-2007-opensolaris.googlecode.com/files/RaymondThomas_Harper.tar.gz This is extremely few code from John. I thought he did nore. Yes well.. I'm much more interested in your comments of how to implement c locale/ISO8859-x for those missing functions... There's also redoing this using netbsd citrus [1] or going and stealing more from fbsd.. Which makes more sense I don't know.. I've not worked with citrus to know if it meets our general requirements at all, but Patrick/oxygene pointed me at [2] that shows how they've used it to implement wcstombs.. Looks very clean.. Suggestions/comments? ./C [1] http://citrus.bsdclub.org/index-en.html [2] http://opengrok.netbsd.org/source/xref/lib/libc/locale/multibyte_c90.c#95 ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: Upcoming NexentaCore 2.0 Hackathon and Bounties
Significant contributions will be featured on our homepage. And its not just fame that comes your way.. we also have few small bounties to give away. That hackathon starts on the 23rd of this month. Join us on #nexenta to get started. Hi Anil, I'm not sure if the bounties page is up date? There's two that seem interesting.. 1) building onnv-gate on NCP2 2) building an alternative "distro" It's hard to find, but I know exact requirements for building onnv-gate.. The details on this seem kinda fuzzy, because even something small like changing the postgresql version from 8.2 to 8.3 could require a patch (eg..src/libs/mms/) and nightly would just show the missing lib.. so for $150 what exactly are you hoping for? What's the current state? (Sorry, but I also find it rather ironic/funny that erast needs to use SXCE to build nexenta core) For the other part of this email.. I'm sure many people appreciate trying to get new developers interested with small cash rewards, but unless you're offering chunks like gsoc I'm not sure it'll really attract much attention. (I could be wrong) Just a thought.. What about actually trying to push some sort of innovation? I know you guys have some CIFS workgroup patches that are interesting, but what else is Nexenta really doing? I don't mean this sarcastically, but why should anyone even really care? If you say Solaris kernel + ubuntu/debian userland.. I'm going to laugh.. For what it's worth.. some of my project would make it a lot easier for you guys to build onnv-gate and or highly customize it to your needs. If you simply follow the 20 year old monolithic Sun style packaging.. You'll always be stuck like this. If anyone out there is /really/ interested in entirely open source OpenSolaris technology I'd love to hear back. So far with the help of others the *only* thing with closed bits is libc.. Which boils down to how to implement wide char support.. there's options for it and all are obtainable.. Anil.. maybe you could help and put a decent bounty on this? When I mean fully open.. I mean from bootstrapping jamvm so you can build icedtea6 to using small tricks like ksh93's built-in tail/printf.. Sorry if I'm rambling.. Thanks ./Christopher #ospkg @ irc.freenode.net http://www.osunix.org (being updated) ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: Upcoming NexentaCore 2.0 Hackathon and Bounties
Bill McGonigle wrote: On 2009-01-20 1:49 AM, "C. Bergström" wrote: If you say Solaris kernel + ubuntu/debian userland.. I'm going to laugh.. Some of us think this is a good value proposition - can you explain why it makes you laugh? Maybe we'd learn something. I also see nexenta as exciting because of its transactional upgrades and the ongoing improvement process (vs. periodic snapshots), which OpenSolaris lacks. I'm just waiting for full Xen DomU support in 2.0 to make Nexenta a standard component in my toolbox. With the current Nexenta process I don't see any real innovation and little value (I'll explain) I just see them building onnv-gate, converting it to deb and then trying to port any differences from Ubuntu to work.. The repeating message I commonly hear is simply (blindly?) to replace the Sun tools with gnu for better(?) Ubuntu/debian userland support. (or even occasionally religious type arguments) This issue has been beat way too much into the ground. Unbiased I can say is that: gnu userland has added some good/interesting interfaces As I network and work with more developers you'd be surprised how many have duplicated the adding of -iname to Sun find. Why isn't it upstream..? (problem 2) The need for a less corporate patch acceptance policy. (I'm not suggesting to sacrifice smart licensing choices or quality, but to follow successful similar projects) *So back to the point..* How are Nexenta developers determining which interfaces have enough value to replace the Sun tools? Is this really the most ideal approach? What value does this current approach *exactly* add? I'm not sure what you mean by transactional upgrades. I won't defend IPS or SVR4 at all, but I can say that boot environments and the ability to roll-back *are* possible. Nexenta doesn't offer any ongoing improvement to the core onnv-gate (which dare I argue is the most important part of this puzzle) They just lag behind Sun in terms of resources and ability to build/release it faster. It's a lot of code and probably easier to back-port a handful of patches than build/ship the whole thing every two weeks. So what's this mean in terms of real value.. I'm 100% sure Sun upstream applied the patch to fix [1].. Has Nexenta? Have either of them shipped the fix? If it hasn't or has how was that determined.. For me I think having and following clear policy/practices on these things is at the core to any successful project. I'm focusing mostly on the onnv-gate side of things. The argument does change a lot if you switch to focus more on the desktop or additionally packaged software. (postfix.. openoffice.. etc) Both approaches have value and are geared towards more or less the same goal of providing a high quality package being shipped. Hopefully, I'm coming across unbiased.. If in some far off land the Nexenta users/developers were open to more collaboration I'd be all for it. Cheers, ./C #ospkg @ irc.freenode.net http://www.osunix.org (being updated) [1] http://www.openssl.org/news/secadv_20090107.txt ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: Upcoming NexentaCore 2.0 Hackathon and Bounties
Hi Tim..
Tim Spriggs wrote:
Hi Christopher,
Some comments below...
C. Bergström wrote:
I'm not sure if the bounties page is up date? There's two that seem
interesting..
1) building onnv-gate on NCP2
2) building an alternative "distro"
It's hard to find, but I know exact requirements for building
onnv-gate.. The details on this seem kinda fuzzy, because even
something small like changing the postgresql version from 8.2 to 8.3
could require a patch (eg..src/libs/mms/) and nightly would just show
the missing lib.. so for $150 what exactly are you hoping for?
What's the current state?
Good question! There is a nexenta-on source package that is started. I
think the idea is that developers can download nexenta-on and get it
to work if they are interested in doing so. To me, the prize seems
kinda like a cherry on top of a dessert.
I don't consider making onnv-gate/nexenta-on compile to be a dessert of
any sort.. :P I still don't understand what exactly needs to be done or
the current state.. I'd have to undeb it to se what's in the nexenta-on
package.. I mean.. is there a problem with onbld tools.. missing
headers.. patchadd is broken because of zfs root and needs patching.. it
could be simple or a gob of work.. The point was to get it done and
reward a bounty.. I hope not to just stir noise..
For the other part of this email.. I'm sure many people appreciate
trying to get new developers interested with small cash rewards, but
unless you're offering chunks like gsoc I'm not sure it'll really
attract much attention. (I could be wrong) Just a thought.. What
about actually trying to push some sort of innovation? I know you
guys have some CIFS workgroup patches that are interesting, but what
else is Nexenta really doing? I don't mean this sarcastically, but
why should anyone even really care?
Seems people do (care) already. Nexenta is doing apt/dpkg and a whole
bunch of pre-packaged GNU software. I can't speak for everyone but I
do enjoy this combination as it saves me time in upgrades and also
offers all of the benefits (and drawbacks) of the debian packaging
system.
Innovation happens here as well. apt-clone was the first package
upgrade mechanism that allows OpenSolaris users to rollback from a
failed upgrade. Nexenta also attracts users who are familiar with
apt/dpkg and want to try out OpenSolaris. In this way, Nexenta is one
of many distributions that can provide a first "welcome" to the
community.
Ok. you answered people do care, but not sure I'm clear on why..
Nexenta provides pre-packaged gnu software and it provides the apt/dpkg
interface..?
So what's the value if I make a wrapper script around foo package
manager to provide that same interface and have the same gnu software in
the repositories?
For what it's worth.. some of my project would make it a lot easier
for you guys to build onnv-gate and or highly customize it to your
needs. If you simply follow the 20 year old monolithic Sun style
packaging.. You'll always be stuck like this. If anyone out there is
/really/ interested in entirely open source OpenSolaris technology
I'd love to hear back. So far with the help of others the *only*
thing with closed bits is libc.. Which boils down to how to implement
wide char support.. there's options for it and all are obtainable..
Anil.. maybe you could help and put a decent bounty on this?
For the un-initiated, this is a new project that has ambitious goals.
If someone feels that Nexenta can leverage from this development
effort I would love to see collaboration between Nexenta and ospkg.
Honestly.. I think it would be more personal preference than technical
which causes people to not want to work together, but why not stay
optimistic.. :)
I don't see the distribution as stuck, perhaps you can clarify what is
meant by that? Many packages that are well known in the
Solaris/OpenSolaris world are easy to find for those who are familiar
with them. For those that aren't, the package descriptions help to
bridge the gap. "apt-cache search {keyword}" searches both package
names and descriptions.
stuck.. as in besides you.. what Nexenta developer has shipped something
original and usable? (Honest question..) I don't consider repackaging
original work.. (It doesn't mean it's not challenging.. It's just not
original)
When I mean fully open.. I mean from bootstrapping jamvm so you can
build icedtea6 to using small tricks like ksh93's built-in tail/printf..
Fully open is the goal. Work has been done towards an open libc.
I'm a skeptic.. the glibc port is cool and fun, but maybe the author
can add a comment on if it's actually a viable route.
I would love to see various JVMs implemented under Nexenta. Currently
most of the java packages are not being
Re: Upcoming NexentaCore 2.0 Hackathon and Bounties
Hi Anil, I normally would not cc the list on a private email, but this isn't a private discussion between us. (Even though I may be the only one on /my/ side) I'll keep my responses light and try not to stir things up to cause a debate (further) Anil Gulecha wrote: Hi Christopher, I'm keeping this offline as I'd rather avoid a debate on how the project should change it's mission. * Nexenta has not contributed much in terms of code back to opensolaris. Point taken. Nexenta is project trying to provide the Ubuntu package repository with opensolaris advantages. As per this mission, our efforts have been towards makingf these two work together. I'd still ask.. what's the benefit? Is there a particular reason.. Who decided this.. Is this the best path to meet the end goal.. What is the goal? Is this just to make it more convenient so Canonical can provide support? (Which could be a great thing.. who knows..) * No original work done: I've joined in late, so wont comment on things past a year, but I've seen lot of innovation in the project since, not the least of which are Tim's contributions. Such as? * Why do people care?: Why do people use windows? why do people use QWERTY (as opposed to DROVAK), etc? These choices weren't made based on as much on objective or technical merits.. they were used, and the userbase grew. We have a BIG ubuntu/debian userbase out there and _plenty_ of them would be happy with moving to Nexenta and it's apt tools, than other userland/etc. There's a _big_ potential audience, and the Nexenta mission seems like a promising way to easily reach them. This isnt a reply based on technical merits, but on numbers. So? What do converted Ubuntu/debian users bring to the Nexenta community? More testers/bug reports? I'm not really questioning if it's right/wrong.. I'm more questioning why.. I'm missing what makes having apt + some packaged gnu software so special? You could just as well send your spec files to the new /contrib build server and then the difference is having apt.. right? (So we agree that apt > IPS ) I'm building a full packaging framework with QA policies and a host of other features.. If I made something that provides a familiar apt interface and a host of new innovative features.. Would anyone in the Nexenta community be interested..? By numbers do you mean monetary gain to Nexenta corporation or contributions to the community? * Bounty : The bounty was a new idea we (the project) decided to try out this time. The numbers aren't huge, but we decided it'll generate additional interest in the project. We'll know soon. It's still unclear and until it's more specific it's just hot air.. (sorry.. this I won't hold back) * Patches: Yes, this has been upto individual package maintainers, largely, and we haven't yet published a policy document. We do use upstream patched on packages, and critical fixes from opensolaris are applied on sunw* packages. This is one area that we need to improve. *Ruffling feathers : yes, you did, and I also see that you've been to point and voiced your concerns objectively. I try to be more objective than just flippant.. Smack me if I cross the line.. I strongly feel the people interested in open source community outside Sun should work together more than apart. To be open instead of just hold onto something because they refuse to relearn how to add a g in front of their favorite program. Perhaps Nexenta isn't heading in a direction you have in mind, or consider worthy. But it is on a promising road, nonetheless. We are a few developers, and any suggestions towards our mission (making policies more clear, automating and maintaining patches better, licensing clarifications, tools to add value to Ubuntu with opensolaris) will be thankfully appreciated. ok.. for patch policy look to your neighbors Fedora.. automate build.. opensuse build service.. code reading/auditing.. openbsd.. There's a lot to learn from other communities.. those communities usually have leaders/innovators.. that's how they've gained adoption and survived the weather.. If Nexenta corp goes away what's left? *DISCLAIMER* I may be rather blunt/forward.. However.. I'm trying to bring up good points.. Sometimes good things come from questions.. Having some clear policy so others can understand *and* work with you towards a common goal is good. right? Not to change the subject too much, but when will Nexenta release the build scripts? Wouldn't this make it easier for someone to actually fulfill the bounty.. with or without the reward..? I had to bug Erast last time to even release the nexenta-on source package.. Maybe people just don't care or aren't paying attention.. Anyway.. good luck and hopefully this wasn't a waste of time.. ./C ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: Upcoming NexentaCore 2.0 Hackathon and Bounties
Erast Benson wrote: On Tue, 2009-01-20 at 07:49 +0100, "C. Bergström" wrote: state? (Sorry, but I also find it rather ironic/funny that erast needs to use SXCE to build nexenta core) It is ironic. And I said it to you before - it is just luck of interest/time of the community in making the procedure more clean. I think nexenta-on source package is a first step in the right direction. We soon should have it fully build-able out of "apt-get source -b". This bounty is more principle than worth my time, but it is something I can certainly help with. If you set everything up somewhere I may spend a bit trying to help out. ./C ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: Upcoming NexentaCore 2.0 Hackathon and Bounties
Erast Benson wrote: On Tue, 2009-01-20 at 22:12 +0100, "C. Bergström" wrote: Erast Benson wrote: On Tue, 2009-01-20 at 07:49 +0100, "C. BergstrГ¶m" wrote: state? (Sorry, but I also find it rather ironic/funny that erast needs to use SXCE to build nexenta core) It is ironic. And I said it to you before - it is just luck of interest/time of the community in making the procedure more clean. I think nexenta-on source package is a first step in the right direction. We soon should have it fully build-able out of "apt-get source -b". This bounty is more principle than worth my time, but it is something I can certainly help with. If you set everything up somewhere I may spend a bit trying to help out. On Hackathon day I'm going to work on nexenta-on build-related documentation. Currently it is full of FIXME: statements. This should help you to get started. Anil also could help you with SSH/DevZone setup on gnusolaris.org if you don't have one yet. FIXME? Oh. this sounds fun.. (Where on earth would you put those?) Wrapper script around nightly? Makefiles? or c code that fails to compile..? For what it's worth I think part of my progress could be possibly ported to whatever build system you have... You'll have drop my 64bit enhancements, but otherwise it's quite clean and a script could maybe convert it to any other sane build script format. It comes with advantages/disadvantages, but fwiw.. the one time hit is more than worth it to get away from the package maintainers mega onnv-gate build hell. Let me know.. (As a side note... I'm working on a QA framework and new binary format, but if there's some python bindings for manipulating deb files I could probably hook up the whole thing to spit out debs directly) ./C ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: Autobuilder +tags
Tim Spriggs wrote: The autobuilder now has the ability to track tags defined by a user. This means that someone can define a tag called "Missing Java" and tell the builder to keep an eye out for the string "You must specify a valid JAVA_HOME or JAVACMD". Anytime that string is seen in a job, the job will be tagged. This can be a very powerful tool for developers that are looking for a common problem with a lot of sources. For example, I know there is a common file that exists under Linux in /usr/include but has no business being on Solaris. An appropriate patch to anything that uses this include is known to me and should be simple to reapply the same style of patch elsewhere. So I define a tag that looks out for errors relating to that file in build processes. I'm sure we can find other uses for tags but that's the use-case it was coded for. Thanks to anilg/wavejumper for the suggestions. An example tag can be seen here: http://builder.tajinc.org/?f=tags&id_tag=1 Hi Tim, I'm finalizing the new binary package format, but right now it's probably at a functional state. My next step is to start building binary packages! If I ship you a zone.. do you think your autobuilder could be hooked into the OSUNIX build system? (or maybe we push autobuilder into the zone and have it work there?) I have about 500 broken down builds and not sure which ones will succeed or fail.. Having a complete list of the failures would of great help. Easily possible? ping me on irc if interested.. btw.. congrats.. this is a really interesting feature.. ! ./C ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Anyone going to FOSDEM?
Hi Everyone! If anyone is going to FOSDEM this year I'd love to arrange some sort of meet-up for those interested in UNIX/(Open)Solaris development. I'm working hard to try to get the OSUNIX project in shape, but completely outside that willing to offer any help I can. I can offer help for: 1) Getting started hacking onnv-gate 2) debugging with Sun tools 3) Status on removing all closed binaries 4) Basics for getting started with OpenSolaris technology So if you're an old vet and want to bounce ideas or coming from Linux and need a jumpstart let's pick a time place. Add your name and desired time/place to this doc so we can organize it centrally http://www.osunix.org/docs/DOC-1014 Cheers, ./Christopher irc: #ospkg irc.freenode.net ps.. Too keep noise off the other lists feel free to subscribe and replay-to osunix-dev directly.. http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/osunix-dev ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: Upcoming NexentaCore 2.0 Hackathon and Bounties
That may be so but gcj is a build dependency of OpenJDK :) http://apt.nexenta.org/dists/hardy-unstable/contrib/source/devel/openjdk-6_6b11-2ubuntu2.dsc You can also use jamvm, cacao, ecj (?), icedtea6 (aka OpepJDK) so if you just need to build the package and don't care about a fully open bootstrap there's more than one option. For me I'm currently blocked by missing xorg headers for the awt section, but otherwise it should got relatively easy. For those honestly interested FOSDEM is a good time to ping me or twisti who was maybe the first to do it and documented it.. http://www.advogato.org/person/twisti/ Hope that helps.. ./C ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: sun vs. ubuntu issues in dependences ?
Erast Benson wrote: On Thu, 2009-03-05 at 20:07 +0100, Mario-Lorenz wrote: Hi, I'm working on some of the mail-related packages, and found some issues that I would like to ask which the better way for a fix would be. a) fetchmail doesnt build because it can not find krb5-config. It can not find it because the sunw kerberos one is in /usr/sun/bin, which is not in its path. It can not find the Ubuntu one because when porting that package, its name was changed to libkrb5-config. situation with libkrb5 is currently not cleared up yet. I'm voting for OpenSolaris krb5 - to be a default in Nexenta. This would preserver compatibility with OpenSolaris distros. The ubuntu packages which are using krb5 are 99% autoconf/automake aware and should be able to detect OpenSolaris diffs. I'm not 100% familiar with the situation, but in case you guys aren't aware the krb5 implementation in onnv-gate has several rather important sun related improvements. I've briefly discussed making a patch against vanilla with the maintainer before, but it's simply on my TODO list and not done yet. So is this some choice between ubuntu package without sun enhancements or onnv-gate version? ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Reviewing on-nexenta patches
I'm reviewing some of the on-nexenta patches... Is there an issue
tracker or any way you guys actually track this stuff?
If there is a way for me to track I can probably help maintain some
bits. For example there's 250+ on-nexenta patches varying in adding
COMSTAR/WORM to various packaging changes. Some things you may want to
clean-up and ask to push upstream or I can commit to osunix-gate and we
manage conflicts together if/when they happen.
Is this a typo or you guys just changing the name? What's your upstream
policy? hg tip says it's not fixed yet..
diff -r 83872c27739b usr/src/pkgdefs/SUNWfchbar/preinstall
--- a/usr/src/pkgdefs/SUNWfchbar/preinstallTue Oct 28 13:42:58 2008
-0700
+++ b/usr/src/pkgdefs/SUNWfchbar/preinstallTue Oct 28 13:47:16 2008
-0700
@@ -25,12 +25,20 @@
#
#
#
-[ "${BASERDIR}" = "/" ] && BASEDIR=""
+[ "${BASEDIR}" = "/" ] && BASEDIR=""
I'd also love to see a bug report, comments and justification for
b103-specific-0-271f44d3de11-rework.patch
Then there's all the stuff labeled b104-specific..
b104-specific-* | wc -l
119792
Which appears to include some things that were backported, but not
merged by hand. I've already spotted a few areas which could cause a
problem because of this.
./C
___
gnusol-devel mailing list
gnusol-devel@lists.sonic.net
http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: Additions to Sun libc
Anil Gulecha wrote: Hi All, I was going through the Opensolaris release pages[1], and saw - libc Linux/BSD Compatibility Two new functions to the C library have been added for familiarity with Linux and BSD operating systems - asprintf() and vasprintf(). They behave as sprintf(), except that they allocate a string large enough to hold the result, and return a pointer to that string. This would make porter's and autobuilder's job much easier. This was introduced in snv_107 (3+ months ago) The current nexenta kernel (snv_104 based?) doesn't have this or is there plans to port it backwards/update? If you're unable to port it backwards I can also detail how to work around this in a somewhat clean way. ./C --- OSUNIX - Built from the best of OpenSolaris Technology http://www.osunix.org ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
List of core GPL copyright holders
Hi all I've quietly been working on two concurrent issues. One is outside of the scope for this list, but it's tied to Nexenta or some project becoming an official Debian port. I don't have time before Monday, but if someone would be able to generate a list of GPL software and copyright holders included in the base Nexenta releases it would possibly help clear up one of the long standing blocking issues. Thanks ./Christopher ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
