[request-sponsor] change of sponsor for 6394677
I'd like to indicate a change in sponsor for: 6394677 ufsrestore cannot restore file ACL from: myself to: Viswanathan.Kannappan at sun.com thanks! -- frankB
[request-sponsor] Reminder: Requesting sponsor for 5007466 PSARC/2004/480
On Fri, 18 Sep 2009 18:13:05 +0200, Joerg Schilling Joerg.Schilling at fokus.fraunhofer.de wrote: Frank Batschulat (Home) Frank.Batschulat at sun.com wrote: On Fri, 18 Sep 2009 17:59:39 +0200, Joerg Schilling Joerg.Schilling at fokus.fraunhofer.de wrote: For a complete implementation of 2004/480, we would need to have it in ON in case that ON should be self contained. Note that for a complete implementation, ufsdump/ufsrestore need to link against librmt. fwiw, having ufsdump/ufsrestore use librmt is afaik, a slightely different, call it follow up project of the star implementation. This is one of the primary the main goals in PSARC/2004/480 which was way before ZFS root, and way before ZFS being the defacto standard file system in OSOL. Hence, I'd rather suggest taking this particular part out of the discussion for now, which is of course, the most obvious reason for a request to integrate into ON, but then -- frankB It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
[request-sponsor] 1224122 windex not created by install/upgrade
On Sun, 25 May 2008 04:24:44 +0200, Roland Mainz roland.mainz at nrubsig.org wrote: ... for the log: I am currently _rewriting_ the manpage subsystem from scratch (the frontend already exists as http://svn.genunix.org/repos/on/branches/ksh93/gisburn/scripts/shman.ksh ; I'm now waiting for the ksh93-integration update1 to land before doing the remaining work). IMO it may be nice to syncronize the work a Interesting, does that imply if I go and remove ksh/ksh93 from the system I won't have a functioning manpage subsustem ? thanks --- frankB
[request-sponsor] Bug Id:6440094
On Thu, 14 Feb 2008 15:02:01 +0100, krishna kumar krishnackl at gmail.com wrote: Hi, We started working on this bug with id 6440094 Synopsis: nfs4 mount broken, fails with EFAULT sorry, but this is already being sponsored and in the works cheers frankB
[request-sponsor] Looking for sponsor for star integration
On Thu, 03 Jan 2008 16:37:37 +0100, Bonnie Corwin Bonnie.Corwin at Sun.COM wrote: Hi Joerg, Is there a bug filed related to this ARC case? If not, please file one and let me know the bug ID. I need that for tracking purposes. Bonnie, the corresponding bugs would be: 4496994 consider replacing existing /etc/rmt with equivalent from `star' distribution 5007466 include ``star'' in /usr/sfw --- frankB In the meantime, I've added this to the 'awaiting sponsor' list using the PSARC case number. Thanks a lot. Bonnie Joerg Schilling wrote: This is about http://opensolaris.org/os/project/star/ Which tries to implement PSARC 2004/480 I understand 2004/480 in a way that it needs to create /usr/lib/librmt.so* and /usr/include/schily/* to allow ufsdump/ufsrestore to be converted to benefit from the enhanced interoperabiltiy of the rmt client code in my rmt library. I understand the ksh93 case in a way that reusable shared libraries are a preferred result. As ksh93 uses a common framework from David Korn and Glenn Fowler, star, cdrecord and other software I wrote or I maintain (schily software) uses a common portability framework. Single programs only use parts of this framework and are only shipped with parts of the framework. For this reason, I recently created a schily source consolidation that can be loaded from ftp://ftp.berlios.de/pub/schily/ The latest is: ftp://ftp.berlios.de/pub/schily/schily-2007-12-24.tar.bz2 if you call: make INS_BASE=/usr/sfw DESTDIR=/tmp LINKMODE=dynamic install you will get a tree /tmp/usr/sfw/* with dynamic libraries and dynamically linked binaries for all I did yet distribute in source. If you call: make CCOM=cc64 INS_BASE=/usr/sfw DESTDIR=/tmp/64 LINKMODE=dynamic install you will get a tree with 64 bit binaries in /tmp/64/usr/sfw/* There is not yet a way to compile to the resuting 32/64 bit tree on Solaris from one call only. The important information here is that the star source distribution contains only a subset of the common schily portability framework. The one that is needed for star. If you start with the schily source consolidation, you get everything. BTW: This also includes the easy to learn editor ved that is listed in the UNESCO free software list. Maybe this should also be in OpenSolaris... If you look at this background, you may understand why I have problems with the shell makefile from the sfw source tree. As this source consolidation includes the programs from cdrtools and as Solaris currenly comes with a very outdated version of cdrtools, I recommend to think about using the schily source consolidation as a base in future. BTW: marry christmas and a happy new year J?rg ___ request-sponsor mailing list request-sponsor at opensolaris.org -- frankB PS: Gutes Posting. Philosophisch und so weiter... Excellent posting. Philosophic and so on...
[request-sponsor] Working on Bug id 6291460 6291454
On Wed, 24 Oct 2007 16:20:19 +0200, John Beck jbeck at eng.sun.com wrote: Naveen This is to inform that navinem(naveenbsq at gmail.com) is working on Naveen the Bug id 6291460 6291454 and will be completing the fix by 04-11-07 fwiw, 6291454 has been fixed in build 20. cheers frankB
[request-sponsor] CR 6462361 Cannot make hardlinks to device nodes on lofs
On Tue, 14 Nov 2006 10:03:03 +0100, Richard Lowe richlowe at richlowe.net wrote: Hey folks, I'm looking for a sponsor for: CR 6462361 Cannot make hardlinks to device nodes on lofs Rich, I'll sponsor this for you - can you pass your relevant materials/diffs/ thoughts onto me directly (frank DOT batschulat AT sun DOT com) as well as your OSS contract ID. cheers frankB
