[osol-discuss] scm-migration heads-up: gpyfm no longer delivered
[Bcc'ing opensolaris-discuss, since tools-discuss seems not to cover everyone] If you're not using a SUNWonbld package from the scm-migration project, or have configured Mercurial to use a merge application other than gpyfm you can (and should) ignore this message. gpyfm (the pygtk based merge tool) has been removed from the scm-migration project gate, if you are currently using gpyfm for your merges under Mercurial you will have to make changes (if you configured your ~/.hgrc with hgsetup(1), this is you). As of now, hgsetup(1) will configure your ~/.hgrc such that with Hg 1.0 (which is in snv_88 and greater) filemerge(1) from TeamWare will be used if it is available, and meld or gpyfm if it is not. If you're on the SWAN and have TeamWare in your $PATH, this should just work for you. If you're not on SWAN, you almost certainly have none of those tools at the moment. There are meld packages both in SFE and available from: http://opensolaris.org/os/project/scm-migration/files/ gpyfm is available from: (source) ssh://[EMAIL PROTECTED]//hg/scm-migration/gpyfm-gate and: (package) http://opensolaris.org/os/project/scm-migration/files/ Otherwise, for those not on SWAN, you'll want to find a suitable alternative for yourselves, I have no particular recommendation. If you're on SWAN and are still using Hg 0.9.5, a script such as: #!/bin/ksh exec /opt/teamware/bin/filemerge -a $2 $1 $3 $1 Set as ui.merge in your ~/.hgrc is sufficient to use filemerge for merges done under Mercurial, but we'd encourage you to upgrade to Hg 1.0 in the near future as the tools will drop support for 0.9.5 soon. A further heads-up about that will be sent to tools-discuss, at such a time as it happens. Please direct questions, comments, etc, to [EMAIL PROTECTED] Sorry for any inconvenience. -- Rich (and the scm-migration project) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] using webrev
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
Gavin Maltby wrote:
On 09/24/07 13:37, [EMAIL PROTECTED] wrote:
[cut]
I am also sending this to the tools-discuss list. Maybe someone
there has a 1 pager. As it is, it looks like there
are probably several ways to do this, but you have to know the path
to take in advance...
Try http://dlc.sun.com/osol/scm/SUNWonbld/ - zillions there, but
SUNWonbld-latest.{i386,sparc}.tar.bz2 looks like it should be
what you want. pkgadd this and it will install into the
usual SUNWonbld destinations (/opt/onbld) - so take care
of anything you have there at the moment. Now add
/opt/onbld/bin and /opt/onbld/bin/$(uname -p) to your
path, and the webrev should work for you. I believe
wx there is also hg aware - eg it can find all files
you have edited and create a wx active file. You
should be able to wx init your workspace and have it find
all modified files, then wx webrev will do the business.
Gavin
Ok. hg status and hg diff pick up the changes just fine... What's
with webrev?
Is this still a problem after your mail of this morning saying that an
updated version of Hg got it working?
If so, could you send me (off-list, if you want) some more detail
about what's going on.
-- Rich
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-code] CANNOT build ON source b66 on Solaris Express b66
陶捷 Tao Jie wrote: Dear all: I'm building ON source b66 these days. But I fail all the time, no matter what I've tried, the nightly opensolaris.sh or cd usr/src/uts; dmake all. My build environment is: Intel P4 with 512M memory, Solaris Express B66 + Sun Studio 11 I can't install the Solaris Express Developer edition (with the SunStudio 11) because the memory is only 512MB. Hence, I installed Solaris Express first, and then installed SunStudio11 from the DVD manually. The log output below suggests you're using Studio 12, not Studio 11. Studio 12 should not (yet) be using for building ON, you need 11. -- Rich Nightly distributed build started: Wed Jul 4 00:00:35 CST 2007 Nightly distributed build completed: Wed Jul 4 03:10:30 CST 2007 Total build time real3:09:55 Nightly argument issues Warning: the N option (do not run protocmp) is set; it probably shouldn't be Build environment /usr/bin/uname SunOS inspiron 5.11 snv_66 i86pc i386 i86pc /opt/onbld/bin/nightly opensolaris.sh nightly.sh version 1.113 2007/05/04 /opt/SUNWspro/bin/dmake dmake: Sun Distributed Make 7.8 SunOS_i386 2007/05/03 number of concurrent jobs = 4 32-bit compiler /opt/onbld/bin/i386/cw -_cc cw version 1.22 primary: /opt/SUNWspro/bin/cc cc: Sun C 5.9 SunOS_i386 2007/05/03 shadow: /usr/sfw/bin/gcc gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) 64-bit compiler /opt/onbld/bin/i386/cw -_cc cw version 1.22 primary: /opt/SUNWspro/bin/cc cc: Sun C 5.9 SunOS_i386 2007/05/03 shadow: /usr/sfw/bin/gcc gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [ogb-discuss] Project Proposal - (what is/was Indiana)
Ian Murdock wrote: On 5/31/07, Al Hopper [EMAIL PROTECTED] wrote: On Thu, 31 May 2007, James Carlson wrote: Roy T. Fielding writes: As I said, the proposal is obviously wrong. One of these days, Sun marketing will stop trying to run this project from the peanut gallery, but that doesn't change the fact that the proposal cannot be accepted by OpenSolaris as written. On the plus side, it looks like ogb-discuss is a direct pipe to the pages of news.com.com. We could do worse. OR - we could have OGB members that think with their brains and not with their fingers (over the keyboard) and do much, much better when it comes to writing project proposals for highly visible OpenSolaris initiatives. Please cut us some slack. On the one hand, you want transparency. So, we're being transparent, and you're seeing what's going on in real time. We want to spin up a project so we can talk about product requirements rather than simply present them to you, which by definition means much of what's being proposed isn't fully formed, and you criticize the proposal for being vague. What if Glynn had posted a fully fleshed out PRD? Would you not be criticizing him for not getting community input? You can't have it both ways. Everything else aside, I agree. You're being forced into a position where whatever you do will be seen as wrong by some group or other, and that's bogus in the extreme. The proposal needs a short description, and a sponsoring community, not a onepager. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [ogb-discuss] Re: [osol-discuss] Project Proposal - (what is/was Indiana)
Brian Gupta wrote: 1.4 Involvement There is a strong intention for this to be a community grass roots project, with open contribution. We hope for this project to be consensus driven, though ultimately the project leads will need to dictate direction if that proves unfeasible for delivering a timely release. While many of those decisions can be made within that specific project area, based on requirements, there may be a real need for a sole arbitor, Ian Murdock. This block concerns me.. I would hope that the project follows standard procedures; which, as far as I can tell, don't specify sole arbiters. If there are sole arbiters, it should be a natural effect of a lack of participation, not by dictation. It also would seem to directly counteract any desire to be a binary distribution named OpenSolaris given it would be under the sole control of somebody other than OpenSolaris. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: User Mode Driver
Paul Durrant wrote: On 3/13/07, John Plocher [EMAIL PROTECTED] wrote: Paul Durrant writes: The current ON processes are just wrong for open source. The ON development process forces developers to look beyond the current confines of their project and understand/manage the impact that their development choices have on others. That's true of most parts of the process, yes. But as Paul says below, supplying Sun with hardware is not one of those parts (I'd be less concerned if the entity was actual an OpenSolaris entity, but it isn't. It's *one* distributor). I agree, that there are testing requirements, and there should be. But I don't think give Sun hardware should be one of them, if anything it's Sun's responsibility to acquire said hardware via whatever means it chooses, not a requirement for the one *integrating* to gift it. I don't see how giving h/w to Sun does this. I can see how that is required for a driver to be included in Sun's Solaris distro, but availability of h/w has no bearing on quality of source code. As I see it, ON should allow source in that passes architecture and peer code reviews. The distros should test, and if problems are found CRs should be raised. Why should one distro vendor's testing gate integration into the common source? Paul ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Revenge of the Unkillable Process
Ben Rockwood wrote: Dennis Clarke wrote: Ben, I'm reading this and calling up Cory Omand also who is the resident Apache2 guru here at Blastwave. We know that the worker model has been tweaked here to cooincide with work from the CoolStack. I am sure that Stefan Teleman will also have some insights. Regardless of what Apache may be doing it does not explain the userland process wedgeing the whole zone and then the Global zone. Let me look at this closely and .. I want to reproduce this here. I have snv_59 here on Sparc. Will that suffice ? I also have an Opteron machine that needs to be brought up to snv_59. Let me know what I can do to help to duplicate the issue and then perhaps track down the root cause. The issues I'm having is on snv_43 on Opteron. As of yet I have no reason to believe that this is solved on snv_56 (which I'm migrating all our systems to) and while there is a sendfilev fix in snv_57 I'm not certain that applies here. Unfortunately this issue is not reproducible. So little information is available when it happens that I can't isolate commonality by which to formulate a method to reproduce. Frankly, if I could reproduce it I could fix it... and thats the kicker. The big pictures issue for me is still the basic: why can a process end up in this state? and why can't I do something about it other than reboot? Thanks to the mdb tips offered in this thread I'll hopefully have some better information next time I encounter the problem. Though I guess this is customer facing, which may hamper things somewhat, the first thing I'd suggest is forcing a dump next time it happens, then you have a dump to dig through more leisurely and/or provide to interested parties. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Eric Boutilier wrote: On Fri, 23 Feb 2007, Stephen Hahn wrote: * Laszlo (Laca) Peter [EMAIL PROTECTED] [2007-02-22 18:29]: So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). The JDS team (well, Dermot ;) is working on adding more packages (mostly the tools required for building JDS). Obviously, it's easier for us to deliver these through the JDS consolidation. However, they really don't belong there. Neither do some of the packages we already deliver into Solaris, like Python, libpng, libogg, etc. I think the GNU Solaris community would be a perfect place for these, if it wasn't a community but a project (or a consolidation?). I propose that we launch a project that aims for creating a repository of spec files that follow the /usr/gnu rules. Sun could pick the packages that we want to integrate into Solaris and support, other packages could be available from opensolaris.org with community support only. How does this relate to: SFW: If proven successful, it would gradually phase out SFW. The idea is that this repository would be more inclusive (i.e. not only supported Solaris packages) and easier to contribute to than SFW. CCD: Again, if proven successful, supersedes it. One big difference is that the CCD installs to /opt, while this repository would install to /usr. SFE: We have 200+ spec files written by various Sun and non-Sun opensolaris community members here: http://pkgbuild.svn.sf.net/viewvc/pkgbuild/spec-files-extra/trunk/ Those that satisfy the /usr/gnu criterion of being listed in the FSF/UNESCO free software directory can be moved into the new repository (after some clean-up and testing). I'm puzzled why it wouldn't be appropriate to just adjust SFW to take either classic-SFW or pkgbuild spec files as part of its build process. There's a project, a C-team with knowledge about freeware dependencies (that I'm sure would be happy to take on members), and an ongoing effort to change its processes. That is, why not just merge CCD, SFE, and SFW into a freeware consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? (Just, please, don't tell me you wanted to avoid discussions that might involve compromise...) - Stephen In other words, adjust the opensolaris.org sfwnv project to be a repository that implements multiple build systems, and that feeds into the the Nevada SFW and JDS consolidations and the Solaris 10 Companion CD. That does seem to make more sense. I really don't think roping the entirety of JDS into this is a good idea (it's huge, for one, it's very different for two). The bits they provide that are actually more general, perhaps, if you can figure out the ARC contracts that would be needed, but... -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Laszlo (Laca) Peter wrote: On Fri, 2007-02-23 at 14:23 -0600, Eric Boutilier wrote: Help, I must be missing something: SFW make-built components can't currently be dependent on components outside the SFW make system? I guess I thought they could... You can't build a sandwich of SFW - spec - SFW - spec without potentially breaking something. For example samba (in SFW) linked against gnutls (in JDS) by mistake and when JDS updated gnutls, it broke samba. If they were built together, this would not have happened. That sounds far more like an ARC contract that should have been there but wasn't (or wasn't honoured), than a technical issue. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] What keeps 6414874 Revive le(7D) driver frombeing done?
Joerg Schilling wrote: Roland Mainz [EMAIL PROTECTED] wrote: At least I and many other students would care since Ultra1 machines are still very widespread and they've become quite cheap (at least we have around 50-60 rotting in the cellar and I guess most german universities have similar stockpiles around). Problem is that OpenSolaris no longer supports this kind of machine which more or less ruines this opportunity to get more developers to work with OpenSolaris on SPARC machines... ;-( The first question for me was whether this driver: ftp://ftp.berlios.de/pub/schillix/ae-0.0.1.tar.gz would do it for le... Next question: AFAIK, the le U-1 machines use sbus, is this true? Yes, as is the U1/E and the U2 Do ne need a s-Bus nexus driver? We already have one. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project Proposal -- Honeycomb Information and dev tools
Stephen Hahn wrote: * Darren J Moffat [EMAIL PROTECTED] [2007-02-06 09:40]: Stephen Lau wrote: Darren J Moffat wrote: Eric Boutilier wrote: Some people have asserted or implied that although support for this proposal is not easily discernable, nevertheless it is there, and therefore the proposal passes per current policy. I agree and think we should move it along, which means that the next step is a post (by me, as usual) acknowledging that the proposal has been seconded, followed by initiating the project web space. Any objections? given that there were objections and suggestions for using an existing community how do we deal with that ? I think what you are saying is that as long as there is one +1 it cancels all -1's, that just isn't fair. But that's the current project approval policy, for better or for worse. Personally I see that there is no point in the approval policy as it stands because it doesn't count anything but positive comments if the original submitter sticks to their proposal and Ben Rockwood and I have been bouncing back ideas for a new project approval policy.. I'll try to send it out today. Great. A simple sum would do the trick for me as an improvement over what we have, ie if there are more +1's than -1's the pluses win. I'm sure there could be some further improvement though that gave some better weight based on input from community leaders where the project would line up with (if any existed). I'm not trying to put up barriers to projects but if there is no way an objection can be raised that has an impact we might as well change direction and not have any seconding procedure at all and have project creation completely automatic. Which might be a good thing. The initial project proposal process was written to generally allow projects that had more than one interested individual, and was appropriate when we didn't know what a project should be; I think Ben and Steve's idea to refine it, now that we're further along, is a good one. Certainly your idea of requiring a majority would be something for them to consider. At times, I know Ben supported the idea that a project actually garner an initial sponsoring community group. There's conflicting goals here. It's important that projects are fairly easy to acquire, but it's also important that they don't just appear, do nothing in public related to the project, and sit dormant (I say, while looking firmly at devname again). I certainly have no interest in pushing people away just because, I'd just like to see the resources actually used appropriately, if granted. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: multiple trees (was Community participation, was GPLv3 ravings)
Mike Kupfer wrote: RL == Richard Lowe [EMAIL PROTECTED] writes: MK So I suppose someone could propose a project which just takes other MK stuff and integrates it for people to play with. RL Projects are projects, I don't immediately think I have any specific RL problem with a *project* that pulls in code from various other RL projects, or the like. But I'm strongly opposed to the *gate* being RL a mishmash of such things. What's a gate, other than a workspace that's run a certain way? I was saying The not A. Intending to suggest The main MarketingRelease gates. Prior to OpenSolaris, there have been ON projects that kept a workspace containing their project plus at least one other large project that was going on at the same time. (For example, IIRC, you could get BFU archives with pre-integration DTrace bits plus pre-integration something else.) What I'm thinking of is a generalization of that approach. I've hand-waved on some important decisions, like how to decide what to take and what to leave out. But those decisions belong to whoever is running the project. Exactly, I think that could be fine run as a project, but parts of this thread seemed to suggest substantially lowering the standards required for putback to the MR gates, and following this idea with the primary gates. RL At various points in these threads people have suggested that RL lowering standards would be helpful, or even would be necessary. I RL disagree with that entirely. I think there needs to be space for stuff that's solid enough to be useful, but maybe not as polished as we'd like for final integration (e.g., not fully internationalized). It's an opportunity for projects to get testing and feedback, earlier, when they're in a better position to take advantage of it. Of course, projects could also get that feedback without a beta integration workspace. But I'm expecting they'll get wider exposure if there's a single download, so that users don't have to pick and choose from multiple project web pages. From what I can tell, you're agreeing with what I intended to say, but using far more precise wording. :) I think space for this stuff before it's ready for final integration is a fine idea, and most likely a good idea. I'm saying that accelerating the final integration is bad. The interesting question then is how does code get from this beta workspace to the production-ready gate. Our experience with merges is that project team does a better job than third parties when it comes to merging their changes into another workspace. So I'm not enthusiastic about the cherry picking model. I would hope the same as now, the project team does the merge(s) and puts it back when appropriate. To be more precise about it. I think I like the idea of the beta workspace you're talking about here, I don't feel it's a substitute for the primary gate (or the gate a substitute for it), nor another path through the workflow. The project team should be responsible for their integration to both, they should only integrate into the main gate under the same conditions they would now. Does that make more sense than my first attempt at saying it? (and yes, there's a whole lot of how would this work without doubling the amount of effort required? handwaving going on on my part, too). -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: multiple trees (was Community participation, was GPLv3 ravings)
James Carlson wrote: Richard Lowe writes: The interesting question then is how does code get from this beta workspace to the production-ready gate. Our experience with merges is that project team does a better job than third parties when it comes to merging their changes into another workspace. So I'm not enthusiastic about the cherry picking model. [...] (and yes, there's a whole lot of how would this work without doubling the amount of effort required? handwaving going on on my part, too). I think the handwaving that bothers me is how would this lower-quality (or 'not yet finished') gate be kept sane? The reason we have the rules around the main gate is to avoid the Quality Death Spiral. Why would the new LQ/NYF gate not succumb to dozens of partially-functional projects that drag the whole thing to its knees? How would anyone use bits produced by this gate? Which is *exactly* why I'm against all suggestions to do this via dropping standards on the main gates. There at least appears to be a number of people who, for reasons I don't entirely understand, prefer broken but shiny to working. If they demand satisfaction, I don't see another way of getting it to them that doesn't force everyone to make that same sacrifice. More importantly, perhaps, how do you deal with overlaps? It's commonly the case that multiple projects must touch the same files; often in non-trivial ways. We handle this today by serializing integrations into the main gate. This is what I was referring to regarding merging. The project teams that want to be involved in this would do the merge. Code that lives in the separate gate will have to deal with differences between this gate and the main gate, both at the time it integrates to this separate gate and (later) when it migrates over to the main gate and some of the changes disappear. The tests done on the previous bits may or may not have anything to do with the final ones. Which was my hand waving regarding doubling of effort. Ultimately, what I think you're actually describing is a separate release train, where what we currently think of as the marketing release is placed on ice and allowed to gel. The new release just has lower quality goals (e.g., not caring about i18n). Which is what I'm desperate to avoid, dropping standards so the people who want broken yet shiny get them, but everyone else does too. Exposing *everyone* to the Death Spiral. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
UNIX admin wrote: Job #2 - Have the foundation create infrastructure, processes and other things for setting up a platform for people to collaborate. (Mailing lists, SCM, Commit process, patch management, reviews, etc.) But that's exactly what's being worked on. What do you think the whole SCM switch from Teamware to Mercurial is? That's only for OpenSolaris - Solaris retains the internal mechanisms. That isn't true. The plan is for everyone to use the same gate, the same SCM. That's a large part of why the work is taking so long. It's not setting up a new system for new people, it's migrating a very large number of existing people and tools to a new (and substantially different) system. It's also worth noting that while people keeping saying that the SCM isn't there, it *IS* there for two consolidations (JDS and the CCD) both of whom have their live, one-and-only, real gate on opensolaris.org, on the outside, visible to all. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: What does OpenSolaris Success look like to you? (was Re: [Fwd: Re: [osol-discuss] GPLv3?])
Stephen Harpster wrote: James Carlson wrote: Stephen Harpster writes: and of those nice interesting things that help do the appliance stuff only get released under GPLv3 and not CDDL it doesn't help them. Which is why contributions back into OpenSolaris (the kernel anyway), will need to be dual-licensed. No, they won't. According to 'whois', it looks like reallyopensolaris.org hasn't been registered yet, and would be an excellent place to set up a rival community. OpenSolaris is a Sun trademark, so don't count on it. ;-) That's nothing but random (semi-humorous I guess) nitpicking, and you know it. So far, in this sub thread. You've somewhat implied that those of us not employed by you are unable to fix problems in the code (for reasons other than process), and matter less both in these decisions, and in general, and then have thrown in random things like the above. What *exactly* are you intending to gain from this argument other than the distrust of anybody both involved in this process and not directly subordinate to you? -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: What does OpenSolaris Success look like to you? (was Re: [Fwd: Re: [osol-discuss] GPLv3?])
Stephen Harpster wrote: Yes, but the same argument holds. This can happen today. CDDL has file boundaries. You can create a fork of ZFS and innovate all you want. If your innovations remain in separate files, you don't have to publish them or contribute them back. The entirety of this discussion has been you saying I don't think it will make anything worse, and people outlining reasons that it could. Other benefits that have been suggested have been largely shown to not actually change anything. I'll ask again (for the 3rd time). What is the benefit that you see coming out of this? Does this all come down to Sun getting good PR? Because a license change for that reason would be, is, and always will be, entirely inappropriate. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: What does OpenSolaris Success look like to you? (was Re: [Fwd: Re: [osol-discuss] GPLv3?])
Stephen Harpster wrote: An increase in developers developing applications for OpenSolaris and an increase in people using an OpenSolaris distribution. It's reaching out to an audience that has been ignoring OpenSolaris. Embracing more people, making more friends, gets more people talking about you, participating, and developing with you. Growing the population. I'm not sure a license change actually does much toward this (though given how vocal people tend to be when it comes to licensing matters, it may seem that way). Making it easier and faster to get the bits, and easier and more productive to work with them would, I think, do far more. In other words, all the missing bits of process and communication that people have been complaining about. I personally doubt that many users consider the specifics of a source license when choosing what to use (though open v. closed most likely play a part, I doubt the specifics after that point do). -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community participation (was GPLv3 ravings)
Mike Kupfer wrote: SD == S Destika S writes: SD It is time to recognize that better alternatives exist - two trees, SD one development controlled by some one independent and driven purely SD by community interests and one Sun's own tree. Let community set SD their standards, do what they care about and let Sun cherry pick SD what they need and what passes their quality bars. Benefit everyone, SD unlike years without progress and only Sun drives and benefits. This seems to assume that 'our' quality bar is lower. I'm not at all sure that's the case. (it also assumes that only Sun is benefiting, and various other things I disagree with, but...) This (or something like it) has been suggested a couple times in the past, even before the public launch. Until now it's been infeasible, because we didn't have any SCM support on opensolaris.org. That stumbling block should go away once we have the Mercurial support in order (next couple weeks?). It's feasible, but as I've said in the restricted builds thread, I don't think it's a good idea to have two distinct 'us' and 'them' gates. (where 'us' and 'them' mean whatever you choose them to). So I suppose someone could propose a project which just takes other stuff and integrates it for people to play with. Projects are projects, I don't immediately think I have any specific problem with a *project* that pulls in code from various other projects, or the like. But I'm strongly opposed to the *gate* being a mishmash of such things. At various points in these threads people have suggested that lowering standards would be helpful, or even would be necessary. I disagree with that entirely. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Community participation
Darren J Moffat wrote: Shawn Walker wrote: I think the barriers to contribution are currently the biggest discouragement. Integration of even the smallest changes can take a very long time. and how is this any different to getting fixes into the one true Linux kernel tar ball ? How many people actually have SCM commit access to that ? Do people really expect to be granted SCM commit access on to do their very first fix integration ? SCM access and the current workflow problems are almost entirely separate, please don't commingle them, it just leads to people believing they're actually the same problem. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Community participation
Stephen Harpster wrote: I'm the first to agree that the transition to Mercurial, getting the source outside Sun's firewall, is going slower than I want. And now there are problems with the automounter. Sigh. It's not that we don't want to fix this. There are just a lot of technical issues. The best thing you can do is to help out. Go check out the Tools community and help! Folks there are working very hard, but more hands won't hurt. I'm sorry, but as I said in my reply to Darren, these are distinct problems. Of the things pointed out below, none of them relate to the SCM implementation, or work on tools that *we* can actually do. The bug system, the RTI system, and more Sun engineers talking on the opensolaris lists seem to be what are hinted toward, nothing that can be done in or by the Tools community can change any of those 3 things. -- Rich S Destika wrote: [b]Do not reply to me, I read the forums - my email address is invalid and I do feel bad I did nothing to fix it. [/b] It was as easy to predict more than a year ago as it is today. In one of my posts I expressed the below (Oct 11, 2005) for which I got flamed more than once - Quote Let Sun create a workable, scalable development model around (Open)Solaris first. I pity the words request sponsor ask above. It's going in the same direction as OpenOffice.org - it's working but only with Sun employees doing the major heavy lifting, community presence is not that big and thus the whole thing doesn't scale upto the point where it should ideally... /Quote I feel sad that more than a year later OpenSolaris development is still closed, bug reports are still vague at the best and for the people to contribute they have to make sure they don't kill their urge and enthusiasm before they can get a change or two in. As a result, people don't feel like caring for OpenSolaris, if they do, Sun makes sure they go away by doing so much red taping, and the closed development model (no design/implementation discussions, no crisp, flaming hot discussions about how some part of code sucks and how it could be made to not suck etc.) means people do not whet their appetite and gather virtually no interest in the internals of OpenSolaris. Classic example of how not to run an open source project. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [Fwd: Re: [osol-discuss] GPLv3?]
Stephen Harpster wrote: Ugh. Here's the de-HTML'ed one Sorry. In the last few months I've seen more and more speculation about the prospect of dual-licensing OpenSolaris under GPLv3. In November Jonathan very publically asked Rich if he would look into it, and everyone knows that we are fully engaged in the GPLv3 process. As Rich has made clear, we're looking into it. No decisions have been made. We've seen discussions in blogs and in the news, but I haven't seen much in the OpenSolaris community itself. I think that we (we being all of you) should be asking ourselves what we think about GPLv3. What would it mean to the community if we dual-licensed? It's now a possibility that we could attach an assembly exception to the GPLv3 which would let us mix GPL and CDDL code. This could open up a world of possibilities. But what are the downsides? What does the community, you, think of the way GPLv3 is taking shape? These are important issues and I urge everyone with an opinion to voice it sooner rather than later. The biggest upside here doesn't appear to be an upside for us at all, but for Sun. A move such as this would generate a lot of good press for you, I'm sure, but it doesn't do much for us, and as such is just marketing crud. What would this bring to us as benefit? a world of possibilities... like what? It would, possibly, ease the integration of GPLv3 licensed software, of which currently none exists, and several large bodies of GPLv2 software appear to have stated their lack of desire to move to the new license (or a new license in general). So as things stand, we're discussing using a license that doesn't exist, to open up a word of possibilities that as best as I can tell also don't yet exist. Discussion of the possible downsides is common in other parts of these threads, but I'm not sure either pro or con can be clear until we actually see what the license ends up being, and can thus give *far* more accurate thought to what this would bring us, as compared to what it would take away. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Community participation
Tom Haynes wrote: Josh Hurst wrote: You could make it a community phenomenon quite like Linux if you would allow people to participate without waiting months to see the submitted patches integrated. It sucks when a five line patch for a very dumb bug is queued and no one cares. It sucks when projects like the ksh93 integration need a year, which is 12 months, 367 days or just a painful long time to integrate. Do you really think this encourages contributors? Come and wait a year to see your code rejected is the current official slogan of Opensolaris.org Which kind of contributor treatment is that? Josh Why do you have to get your patches integrated? Why can't people go to your web-site and get your contributions? ... I can't easily word a response to those questions, but I can only imagine they come from a complete and utter misunderstanding of this conversation, and the purposes of the project in general. The whole point is that people can contribute their changes. The whole point is that those changes go back into a source tree shared by all. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [Fwd: Re: GPLv3?]
John Sonnenschein wrote: On 31-Jan-07, at 10:30 AM, Christopher Mahan wrote: Get rid of the Sun Contributor Agreement. CDDL is OK. I would be better under GPLv2, but I understand if you can't for legal reasons. +1 contributor agreement's gotta go. ... I don't get this. The FSF have such an agreement, as do various other projects. What's wrong with ours? (which as I understand it, is actually nicer than most). -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [Fwd: Re: [osol-discuss] GPLv3?]
Stephen Harpster wrote: John Sonnenschein wrote: I meant more for contributors who want to pull in changes from another gpl3 project, for example... it won't be possible to package that with the CDDL fork of opensolaris, only the gpl3 fork If you pull OpenSolaris under the CDDL, then you can only combine it with other GPLv3 projects in exactly the same way you can today. For example, you can have GPLv3 apps, but you won't be able to add GPL to the kernel. Dual-licensing doesn't help you with this particular example, but it doesn't make things worse either. Perhaps, but as I said elsewhere. There's a whole lot of discussion of what this may or may not make worse. I've seen little discourse regarding what it may *improve* other than vague pieces of speculation. It seems obvious to me that this has been discussed on the inside at various points, and that the idea, quite clearly, has its proponents, I'm obviously missing where the advantages that are seen are being stated. So, to lay it out: What do people believe this would bring to us that would actually be beneficial, (rather than not being actively detrimental)? -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Community participation
Tom Haynes wrote: Richard Lowe wrote: Tom Haynes wrote: Josh Hurst wrote: You could make it a community phenomenon quite like Linux if you would allow people to participate without waiting months to see the submitted patches integrated. It sucks when a five line patch for a very dumb bug is queued and no one cares. It sucks when projects like the ksh93 integration need a year, which is 12 months, 367 days or just a painful long time to integrate. Do you really think this encourages contributors? Come and wait a year to see your code rejected is the current official slogan of Opensolaris.org Which kind of contributor treatment is that? Josh Why do you have to get your patches integrated? Why can't people go to your web-site and get your contributions? ... I can't easily word a response to those questions, but I can only imagine they come from a complete and utter misunderstanding of this conversation, and the purposes of the project in general. The whole point is that people can contribute their changes. The whole point is that those changes go back into a source tree shared by all. -- Rich If someone makes changes to OpenSolaris and Sun decides not to take them, does that invalidate the changes? Look at the Linux kernel debugger work that wasn't being taken back because Linus didn't believe in kernel debuggers. People still found those changes useful. Right now, OpenSolaris implies Sun. It doesn't have to. You could take the latest source code drop and fork it for your development effort. Lets say someone decides to use OpenSolaris to control an appliance. They take the fork and are careful to not take new changes because it will cause their QA cycle to restart. They ship their product and as part of being good open source citizens, they provide their source tree on the install CD and on their website. Perhaps during the development process, they sent patches back to the community. But because they had no desire to pull a new drop, they didn't care whether or not the changes got in right away. Is this an OpenSolaris system or not? My point is do not get too worked up into whether or not Sun pulls your changes back into their gate - that is not what makes your contribution OpenSolaris or not. Modulo the work needed to make this practically true (which is in progress) they are NOT Sun's gates. They are the OpenSolaris gates, and everyone involved with them should be treated as *equal*. Yes, it's possible (trivial even!) to maintain your work outside of the gate, and never integrate it at all, and it would still be valuable work. But it's impossible to deny that the desire to actually *integrate* that work, and get it to the widest possible audience is a large factor. Seeing a response in a thread about making our development process better that seemed, at its heart, to suggest that a person shouldn't care about ever integrating ones work was, and is, frankly disheartening. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Community participation
John Sonnenschein wrote: On 31-Jan-07, at 1:13 PM, Tom Haynes wrote: Right now, OpenSolaris implies Sun. It doesn't have to. You could take the latest source code drop and fork it for your development effort. Not while critical pieces of libc are closed you can't. This very scenario you describe is currently impossible due to Sun's restrictions on parts of libc You could, as long as your work didn't necessitate changes to those specific parts of libc (or any other piece of the closed code, it's not like that specific bit is any more or less a barrier). The closed stuff is problematic, it would be great to see it go away, and any project to make bits of it go away would, I'm sure, be greatly appreciated, but it by no means makes work (in the general sense) impossible. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Making automatic fresh installs easier
Tom Haynes wrote: Stephen Lau wrote: Tom Haynes wrote: Could we get links for the latest SUNWpro, SUNWonbld, and closed binaries added? That way, instead of having to know the date, we could automate pulling down the latest bits from the mecurial repository and also getting the matching bits needed to do a full build. That way, instead of doing something like: wget http://dlc.sun.com/osol/on/downloads/current/on-closed-bins-20070122.sparc.tar.bz2 We could do: wget http://dlc.sun.com/osol/on/downloads/current/on-closed-bins-latest.sparc.tar.bz2 I'll automate the script, I just need someone to add the symlinks on the web server. Thanks, Tom Hi Tom, If you're pulling down bits via the Hg repository, you probably want to grab coordinating closed-bins from the nightly-bins dir: http://dlc.sun.com/osol/on/downloads/nightly-bins The suffix of each filename is the Hg changeset hash that matched what it built from - and -latest is a symlink to the most current one. I'm not sure what SUNWpro is.. ? Fat fingers - that is what it is: SUNWspro While it'd be nice to make handling that somewhat easier, it's stuck on SDLC and has the whole no redistribution problem. (and I'd bet the compilers shipped with SX:DE aren't at the CBE patch level) -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal -- Honeycomb Information and dev tools
Peter Buckingham wrote: Hi All, Honeycomb is a unique archival storage product developed within Sun. It is built upon a clustered system and provides strong reliability guarantees for it's data storage (Write-Once, Read Many) and metadata. We (the development team) would like to start to provide information about the system. The intention is to make it significantly easier for people to start developing applications with Honeycomb in mind and to be able work with people on developing Solaris appliances. The intention is to initially put up the whitepaper and some documentation to be followed by the SDK and Honeycomb emulator. thanks, peter I'd like to see more details first. Sources? continued development and work in the community? I'm not seeing much in the above (though maybe that's me being dense) that seems opensolaris related. We are neither a hosting service, nor a marketing organization... -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Making automatic fresh installs easier
Tom Haynes wrote: Could we get links for the latest SUNWpro, SUNWonbld, and closed binaries added? That way, instead of having to know the date, we could automate pulling down the latest bits from the mecurial repository and also getting the matching bits needed to do a full build. That way, instead of doing something like: wget http://dlc.sun.com/osol/on/downloads/current/on-closed-bins-20070122.sparc.tar.bz2 We could do: wget http://dlc.sun.com/osol/on/downloads/current/on-closed-bins-latest.sparc.tar.bz2 We have nightly closed-bins on http://dlc.sun.com/osol/on/downloads/nightly-bins (complete with a symlink with a strikingly similar name to the one you use above :)). I'm not sure why you'd do that with SUNWonbld though (assuming you're using nightly/bldenv -t, nightly and bldenv are most likely the only things you're running not coming out of your workspace) -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: SXCR Build 55 available
W. Wayne Liauh wrote: Please find the links to SXCR Build 55 at http://www.opensolaris.org/os/downloads/on/. - Derek -- Derek Cicero Program Manager Solaris Kernel Group, Software Division ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org What are the differences b/t Solaris Developers Express and Solaris Express? I have just installed the latter, what are the steps to install the compilers and development tools that are included in the former? Thanks. The former has the compiler bits, the latter doesn't. When you boot the DVD You'll see the default entry is DE, it passes a flag to the installer which should (iirc), tweak it somewhat and also drop the compilers onto the system. The compilers are in DeveloperTools at the root of the DVD and also appear to have a separate installer. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Refined OpenSolaris KDE proposal / Re: [osol-discuss] Proposal to create an OpenSolaris KDE project
Roland Mainz wrote: John Sonnenschein wrote: Following the official proposal guidelines, I'd like to take this opportunity to propose that we collaborate with the KDE e.V. and kde-core-devel in order to integrate KDE as an OpenSolaris project Ok, lets refine this proposal: 1. Deliver KDE3 to /usr/kde3/ and reserve /usr/kde4/ for KDE version 4. No /opt/blabal or /usr/sfw/junkblabla 2. Ship a Sun/Solaris-branded KDE which uses the default SuSE Linux 10 configuration as default (e.g. things like emacs-like input/edtor modes for widgets, enable the klipper clipboard tool by default etc.) to increase interoperability+productivity. What Sun choose or do not choose to deliver with their Solaris product is not something an OpenSolaris product can choose or enforce, and as such is irrelevant here. I would leave the location of your deliverables as something to decide upon later, based on the above. I really don't like the idea of delivering unbundled software into /usr (though if your build were to make it easy to deliver to both /opt/OSOLkde or /usr/blah, that would work, but again, something for the project to decide when more is known). Also, as Darren pointed out, the use of Sun's branding is something that would need to be carefully figured out with Sun (I would assume you can't). 3. The package should be named SUNWkde* (where '*' means the suffix for the packages) and targets delivery into Solaris 11. Again, the choice of what makes up Sun's Solaris product is not yours to make. Given that, it maybe be better to leave the choice of package prefix until such a time as its known whether SUNW is appropriate to use. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] What's the status of virtual consoles?
Alan Coopersmith wrote: Normally I'd suggest checking the vconsole-discuss list instead, but it seems to be mostly spam - much higher than other OpenSolaris lists for some reason (is it not spam filtered or set up with the same admin settings as the rest of us who have to filter spam on our lists?). I do know the team has been working on it a lot, but certainly needs to get more of that work out in the open. There's been a lot of design discussions and discussions on interactions with components such as X, gdm, etc. they've held internally that should be held in the open to be a true part of OpenSolaris. They certainly should have, we don't need another devname. (http://www.opensolaris.org/os/project/devname). The only opensolaris.org project I know of that went back into Nevada without *any* content on opensolaris.org and with a single, spam, post on its list. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Recent putback of PSARC 2006/356 Reliable Datagram Sockets
Cyril Plisko wrote: On 1/4/07, Stephen Lau [EMAIL PROTECTED] wrote: On Thu, Jan 04, 2007 at 08:27:41PM +0200, Cyril Plisko wrote: 57 /* 58 * Sun elects to include this software in Sun product 59 * under the OpenIB BSD license. That last sentence sounds a bit odd to me. While only Sun gets to decide what to include in Sun product, we are talking about OpenSolaris here. And it is not a Sun decision what license to choose. In this specific case I am sure the choice of license is obviously correct. In general, however, comments like that should not, IMHO, appear in the OpenSolaris code base. It is to be decided by community/CAB/OGB what license to use in OpenSolaris code base. So is it a sign of Sun isn't taking it [OpenSolaris] seriously, or a trivial ignorance of most of the Sun' developers ? Hi Cyril, Nice catch :) I suppose this could be done one of two ways: 1) The committer makes the decision. (in this case, since the committer works for Sun and this is being done under Sun's contributor agreement, the wording is Sun elects to include... as opposed to Cyril Plisko elects to include... if you had committed it) Hm, I actually was talking about the second part - the one that says Sun product - OpenSolaris is not a Sun product. True, but I'd expect that to be a 'form letter' kind of statement. Or from another point of view, this is a good thing, since *Sun* may have chosen that, but you, Cyril, can opt otherwise. (If it'd said OpenSolaris, I'd have been annoyed in the same way Steve read your initial mail, since that'd be, from my point of view, overstepping things). That would be equal to Cyril Plisko elects to include ... in his own product wording appearing in the file. In which case I am sure that would be caught before crossing the bridge. In general, I don't think it's particularly necessary to comment it in the source at all, but I ignore legal matters in the hope they ignore me, so... -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] b.o.o comments [Was: Re: Re: Unkillable Processes]
[redirecting to website-discuss] Andrew Pattison wrote: What about creating a public comments field and showing that on b.o.o? The existing comments field would be kept for private stuff, and the new public comments field should be used as the default unless the info you are typing must be kept confidential. That way you keep the old stuff that must be kept closed confidential, but all new stuff that can be shared with the wider community *is* shared. This is effectively what bugs.sun.com does. The Comments there are (I'm told) entirely disconnected from their namesakes in BT2 (which if true, would cause the opposite problem...) This, and many other things have been suggested previously (separate notes, flags per-note indicating confidentiality, etc, etc). The last real discussion of fixing things such as this was in the New Release of B.O.O thread which bounced between both here and website-discuss, and really ended nowhere beyond a We're still thinking about how to fix it kind of summary. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris Bug Tracker - Duplicates (!)
Bill Sommerfeld wrote: On Sat, 2006-12-02 at 08:56 +1030, David Lloyd wrote: There are a number of bugs marked as duplicates, eg: * http://bugs.opensolaris.org/view_bug.do?bug_id=6484330 * http://bugs.opensolaris.org/view_bug.do?bug_id=6414868 However, the bug tracking tool doesn't say what they are duplicates of. This implies that: * The bugs are NOT duplicates; or * The bug tool doesn't allow one to link the Original Bug (tm) to the duplicate You forgot: * b.o.o. still loses a bunch of stuff in translation from the underlying database. the underlying database has a duplicate of field which must be filled in before you can close a bug as a duplicate. Just FTR, 6484330 is a dup of 6489148 6414868 is a dup of 6333181 bugs.opensolaris.org used to show this information, perhaps it got lost during the refresh? (it also included the duplicated bug in Related CRs, so you maybe able to hunt it down that way, for now). I'd say if this information is now missing, that's a bug in the b.o.o refresh and needs to be reported as such. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] New Release of B.O.O!
Roland Mainz wrote: Linda Bernal wrote: First off, I would like to thank the community for being so patient with this release of bugs.opensolaris.org. This project has taken a little longer than anticipated due to some unforeseen obstacles. Please know that we intend to keep making progress on b.o.o in the future. For this particular release, our goal was to have it re-written to be easier to modify in the future and to make some easy fixes. The majority of the present enhancements are informational upgrades. In the future we will try focus on: * RSS feed function. Erm, no. Could we get a mail notification system FIRST, please ? Solaris doesn't even ship with a RSS client for the shell right now[1]. We have a mail notification system. It's just utterly useless. For those who can see it, take a look at CR 6488448. (and Roland, you won't be able to. It got moved to a category we can't see, despite it being me that filed it) And while here, Thunderbird will read RSS. * Add Commit to fix and Introduced_in_release fields on bug view page What about an add comment field if the bug owner allows this for the OpenSolaris account of the current user ? I don't think it should be a matter of whether the RE or whoever else 'allows it', it should work for everyone logged in. * Filtering out old bugs that are not revel ant. What do you mean with old bugs ? Good catch! Any CR maybe relevant, be it old, closed, or whatever else. A method to refine a search to within a date range would be good, hiding all CRs older than a set date would be terrible. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [website-discuss] Re: [osol-discuss] New Release of B.O.O!
Dan Price wrote: On Wed 29 Nov 2006 at 10:35PM, Cyril Plisko wrote: On 11/29/06, Stephen Hahn [EMAIL PROTECTED] wrote: * Cyril Plisko [EMAIL PROTECTED] [2006-11-29 11:59]: On 11/29/06, Dennis Clarke [EMAIL PROTECTED] wrote: * RSS feed function. that's cool Yeah, but where is it ? I cannot find it... It's not there yet--Linda's list was outlining our thoughts for the next batch of changes/improvements. These are starting to settle, but there's still time to change the priorities. I see. The current release added more fields to the reporting, as well as various bug fixes. (Linda may have a list near to hand.) For example, I need to get going on http://bugs.opensolaris.org/view_bug.do?bug_id=6497932 Linda and team, It's REALLY REALLY upsetting that no attempt is made to foil the spambots. For example, in the above link, Stephen's sun email address is clearly visible for the spambots of the world to harvest. Putting my naked email address on the web is something I've tried very hard not to do. I already get 20+ spams (despite Sun's filtering) a day; this will almost certainly make things worse. Can you address this as a P1/S1 issue, please? I'll give the reply here I gave to someone else on IRC just now. Switching it to user at host dot tld would be fine, [EMAIL PROTECTED] would most definitely not be. Please make clear that this information should not once again be entirely hidden or useless. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] New Release of B.O.O!
Roland Mainz wrote: Richard Lowe wrote: Roland Mainz wrote: Linda Bernal wrote: * Add Commit to fix and Introduced_in_release fields on bug view page What about an add comment field if the bug owner allows this for the OpenSolaris account of the current user ? I don't think it should be a matter of whether the RE or whoever else 'allows it', it should work for everyone logged in. I don't agree. There should be some kind of access control to restrict comments to those who are working on the issue or are interested to work on it. Because I don't intend to specifically fix a problem does not mean I don't have information relevant to it. Having to go ask permission before I can share that information just inserts a pointless barrier. Limit it to people who are logged in certainly, or maybe even a subset thereof. But limiting it CR-by-CR is just an unnecessary barrier. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SXCR 51 delayed slightly
James Carlson wrote: Glynn Foster writes: delivered project were accidentally sent to the consolidation, and overwrote the correct packages already there. It results in upgrade failures. Hrm, from one vague message to another. Any chance of being just a little bit more open in sake of creating a better informed open development environment? [1] I gave you the details. Someone -- a gatekeeper -- was integrating packages built for an undelivered project, and accidentally delivered them to the WOS itself rather than to the project's dock. It was an oops moment. A mistake at the keyboard. Do I need to give the person's _name_? Why? I don't think so, No. What exactly are you looking for here? The project name (it's Zulu, if that helps)? Yes, that does help, but only because it's then possible to infer exactly what is being talked about. Just a black box 'something went wrong, somewhere' really tells people nothing... -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Reforming the OpenSolaris project integration process (was:Re: how to make a new project?)
Dale Ghent wrote: Bureaucracy. That's a word teetering on understatement. What's written below, and what (appears to have, I could be wrong) kicked off this conversation don't coincide much. My understanding is that the original mail (which I still haven't received, so I'm only going on quoted text here), is most unhappy about the ARC process. Disclaimer: I'm not a Sun employee, and have never been one. As I see it, there's a few shortcomings with the organization. 1) The CAB. Where /are/ they? Maybe the CAB holds meetings and the minutes of them are posted on some obscure corner of opensolaris.org. Maybe the CAB provides regular guidance or has a way for non-CAB members to address the CAB, but I'm overlooking the link to these items on opensolaris.org's front page. Sure, there's a link to what the CAB /is/, but there's nothing on what it has actually done in the time since it was formed... my point here being that the CAB from my vantage seems non-existent. The OpenSolaris Constitution? Hello? I see many of the CAB members individually post here often, but I never recall seeing regular (or any) correspondence from the CAB as a group. My understanding of the CAB's responsibilities is that the less visible they are, the better things are going. :) 2) Too much Sun is in the way. It seems like you can't do anything with OpenSolaris in terms of contribution without touching SUNW, either by being made to interface through a Sun employee or having to acquiesce to Sun-origined policy or SOP. Take the opensolaris.org site as a simple example. Is there even just one non-Sun person who has a tangible role in maintaining it and giving it direction? How about code comitters? Is there even just one non-SUNW person who can commit code or vote meaningfully on ARC cases? Not as far as I can tell. A lot of this is technical, and there's a lot more to go, too. There's really no indication, in fact, that any of this in specific is *not* technical (though I suppose some of it probably isn't). There is no non-Sun person who can commit, because there is (currently) no SCM for them to putback *to*, and, beyond that, the 'real' onnv-gate is stored in an SCM that *doesn't even support* a commit over the network other than via NFS (which, for these purposes, Doesn't Count). This is changing, obviously, but it takes time. As I understand the process, being able to vote on the ARC requires a certain amount of work, even for those inside Sun, hence the internship process for ARC members. The majority of Sun staff are not ARC members. Participation means more than just giving Joe Random the ability to browse and download previously unavailable source code. Participation means giving a Joe Random the potential to have a say in direction, from the smallest one-line code patch as a reviewer/comitter to deliberating as a voting person on a non-trivial ARC case, and many other areas. Much of this is currently possible, although the interim (and that's an important word) methods of achieving them are not so pleasant. Want a one-line patch to go back? File the SCA, mail it to request-sponsor. Want a say in direction? Look at the majority of the sprawl of projects and communities currently hosted on opensolaris.org. Each and every one of them has a mail alias attached to it. Use them. :) I'm not here to spout FUD or stir up emotions, as I'm a fervent user and advocate of OpenSolaris (the code, the concept). Just trying to give an honest perspective. In all honesty, I can't say that I'm happy with how OpenSolaris (the org) has progressed since April, 2005. In the past I felt ambivalent about the org, but lately I find myself being bugged by the lack of non-SUNW inclusion regarding the inner-workings of the org. This, I feel, is summed together is peoples' minds and it promotes the impression (to the non-SUNW person) that there's a hard-to-penetrate bureaucracy involved, and even perhaps one that's tilted in favor of whatever interests SUNW may have. I don't want in any way disparage the efforts and (in many, many cases, above-and-beyond) attention individual Sun employees have given in terms of technical discourse, guidance and direction, but the Org as an organization entity needs some quick-order work in terms of its inner open(2)-ness. While I don't intend this aggressively, I find it rather funny that this is part of a reply to a discussion that (somehow) started during one of the first handful of entirely open PSARC cases, conducted on opensolaris.org, rather than proxied through to the internal system via a sponsor. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Growing the OpenSolaris Community
Glynn Foster wrote: Hey, Jim Grisanzio wrote: So ... where do we go from here? Depends on how you classify the community and where you feel the most benefit is. As a general statement Listen to what people are asking for, and find ways to do it seems to be the only way to achieve anything, what Glynn said above applies to the order in which things are done though. I think if things are done properly it will just happen, and if things are done badly, no amount of management will fix it. Year one was clearly about getting out there, releasing lots of code, and building infrastructure. What's next? To me, community growth -- in size and diversity -- makes a lot of sense to be discussing, but I'm happy to shut up and sit down if people think this is not a valid area of focus. Keep in mind, when I say community growth what I mean very simply is people. I'm still amazed -- and inspired -- by the fact that a large number of people out there don't we're open. I've always viewed this as an opportunity for growth, though, not as a problem. But are we engaging them properly? Infrastructure, process and people. [snip] I snipped the more specific list, but as a very high level description I agree entirely. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SXCR is now 6 CDs
Alan Coopersmith wrote: Derek Cicero wrote: It appears that StarOffice 7 and the SFW binaries are what pushed the release over 5 CDs. For now, all subsequent releases will be 6 software CDs and an optional lang CD. But StarOffice 7 has been in since s10_67, when there were only 4 CD's, so how was it responsible for making the OS grow more?Did the latest SO7 patch integration grow it that much? In talking about this on IRC, I ended up doing a comparison. From memory, the snv_46 DVD is 90-ish MB larger than snv_41. So while it grew a CD, it didn't grow it by much, at all. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is CDDL illegal? (Fwd: Remove cdrtools)
Josh Hurst wrote: Just a notification: Debian and Ubuntu are going to removal **ALL** CDDL licensed materials from their distribution, stating that the license is non-free and illegal (not GPL compatible). This is a Debian decision, and only vaguely, at best, relates to us. Might I suggest that discussion related to it be taken up with *them* and not left polluting opensolaris aliases as the innumerable prior discussions have. Thanks, -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Lots of error messages when booting a sf15k domain with SAN (EMC) stora
Brett Albertson wrote: Hans, you aren't running OpenSolaris, you are running Solaris. Some comments which may help you. 1. Contact Sun via your service agreement. In the U.S., call 1-800-USA4SUN. 2. Don't worry about the USB errors. AFAIK, F15K's don't have USB ports. 3. The storage seems to be working. I'm not sure if those are Sun Emulex cards or Emulex Emulex cards. 4. ndd shouldn't cause a panic, so that's a bug. However, you shouldn't need to force 100Mbit full duplex. Sun recommends everything be set to auto-negotiate to the highest settings. This works 99.99% of the time. #4 looks a lot like CR 6244642 eri driver panics if ndd command is run with the wrong instance number. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Happy to say I'm posting this from Nexenta!
Joerg Schilling wrote: Alan DuBoff [EMAIL PROTECTED] wrote: On Friday 04 August 2006 02:40 pm, Joerg Schilling wrote: The current problem with Debian is that they disregard their ethics rules and act with arbitrariness. Some people dislike anything but the GPL and apply pressure on authors that use different licenses. There could be something lost in the translation between you and them possibly, I don't know what the problem is. I've always found them to be fairly reasonable. I'm not sure what the problem with CDDL is. I am sure that there is nothing lost in the translation. In former times, Debian indeed has been very reasonable, but this changed in the past 2 years. The problem is that they started disregarding their own rules and started with arbitraryness. What they currently do could be called calumniation. They started a campaign against CDDL programs last autumn. [snip]. Ok, I have to ask. What exactly (beyond, tenuously, the CDDL reference) does this have to do Solaris, OpenSolaris, or any other legitimate purpose of this alias? -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Cdrecord 2.01.01a11 in the latest snv ?
Dennis Clarke wrote: Dennis Clarke [EMAIL PROTECTED] wrote: What would it take to get the code from cdrecord fed directly upstream into the snv tree such that the cdrecord in Solaris Nevada is up to date ? From what I did see until now, it seems that the cdrtools sources have not been integrated into the ON source tree. Is this what you expect? I was hoping for an up to date binary ... so yes. cdrtools is part of SFW. So you won't see it in the ON source tree. I suspect that's the point Joerg was making, too. :) -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Where is the “community” in Solaris Express Community Release?
James Dickens wrote: On 6/17/06, Ben Rockwood [EMAIL PROTECTED] wrote: James Dickens wrote: All 5 current distrobutions are currently handicaped. There are lack the ability of including close bits that are included by Solaris Express. Untill everything is open it has advantages that no other distrobution can have why not include what the community has created. Handycapped how? I'm not sure what it is that you want in a distro that isn't already available in the open. all the distro currently have to hack things like zones and brandz support because sun isn't ready to release all the details I can't speak for brandz, but the issue with zones is purely the reliance on packaging tools and data. Packaging tools are available, and the ability to build packages is coming. also some hardware drivers are not availible for redistrobution outside of a Sun product. There's relatively few of them, however. But yes, this certainly can be annoying. What if Sun isn't the one that does it, but the community as a whole votes on what it wants, will Sun allow us to submit a request to incdude what the Community wants in its special community release By your words, Sun IS the one doing it, the community simply would be applying pressure. well i was hoping it wouldn't be so blunt i'm talking about maybe a dozen community chosen and created packages that would be added to the dvd, to make users experience much nicer and perhaps help Solaris gain more users. There seems to be a fundamental disconnect here regarding what SX:CR *is*. It exists so that developers can gain access to recent Nevada bits without having to wait for the test cycle of Solaris Express. At the top of the download page, there's a paragraph explaining that. We are providing DVD-image binaries for every build of the Solaris OS in order to enable developers in the OpenSolaris project to update their development systems more frequently. The most recent builds will not have the same level of testing and documentation as the standard Solaris Express releases, but will provide a mechanism for developers to keep their systems more closely synchronized with the source releases. Please see http://www.opensolaris.org/ for more information about recommended builds of the Solaris OS and other requirements for building the software. We all want things to go, not just into SX:CR, but into S10 Updates as well. Everyones list is diffrent. Thats where distros really shine, because each caters to a diffrent group of people. Even still, yes, there are some things that aren't open yet, sometimes thats an issue, many times its not. Lord knows I want desprately to make Enlightenment a standard part of the install, I've got my list too. One way to resolve this is to create downloadable Booster Packs; your own CCD if you will. People could download all the things you want and install them on top of the OS without having to integrate through the development procedures. I did such a thing with SIDEkick. so we have to tell our users that they need to download another iso or tarball, lots of users are allready balking at the 5 cd's that make up opensolaris now. That make up SX:CR, OpenSolaris is neither a distribution, nor a binary product. It is the source to various pieces of Nevada. As said previously on IRC (re-said here purely so it's actually in this discussion). SX:CR should not, in any way, diverge from Nevada. Adding some of the things you mentioned to Nevada would be a good thing, placing them in SX:CR but nowhere else would not. -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Commets on build 41
Ian Collins wrote: I've just (live) upgraded from build 36 to build 41 and I have a couple of observations: The nVidia driver in the source BE still gets mucked up. The machine is now a brick. Must be a ZFS change, I see cannot mount '/export/home1': directory is not empty followed by an explanation of the fix followed by svc.startd[7]: system/filesystem/local:default failed fatally: transitioned to maintenance. Not a happy situation I'll try and patch it up from failsafe. This is the result of ZFS and live upgrade not getting along well. Live upgrade will create directories for all mount points, even those under other mount points. ZFS will not mount over a non-empty directory. Removing the spurious directories should take care of that. -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [osol-announce] ON Mercurial changeset bundles
Cyril Plisko wrote: On 5/31/06, Stephen Lau [EMAIL PROTECTED] wrote: Starting with yesterday's nightly delivery, we will be delivery Mercurial (Hg) changeset bundles [1] in addition to the raw source tarball. You should be able to unpack these bundles and have a Mercurial repository of ON dating back to OpenSolaris Launch (2006/06/14). To unpack the bundle: $ hg init hg-onnv $ cd hg-onnv $ hg unbundle -u path_to_bundle.hg The clonable/pullable repo is available at http://svn.genunix.org/hg/on It's worth noting Steve's warning about the layout and structure perhaps changing. Especially the fact that should the repository need to be recreated, you'll end up having to recreate this repository from the new bundle, and recreate all trees cloned from it to continue updating from it. There's an issue currently with files that should not be present in the bundle, yet are, that to fix properly would involve such a re-recreation. -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [website-discuss] Re: [osol-discuss] Download Archives
Dan Price wrote: On Tue 30 May 2006 at 12:59PM, Richard Lowe wrote: Dan Price wrote: On Tue 30 May 2006 at 03:36AM, Roland Mainz wrote: Derek Cicero wrote: We need to do little housecleaning on the download server, so going forward our plan is to provide the following archival downloads: + For numbered builds we will keep the last 6 months. Is it possible to extend that to 12 months, please ? Some of the larger projects may have to wait longer for their inclusion into OS/Net and IMO it may be bad if the original B[1-9][1-9] build tools, sources etc. go away shortly before the putback just because they're slightly over the six-month barrier... [I agree with Casper: project gates should stay in sync...] In the interest of historical curiousity, it seems like we might want to something more phased: - All builds for the past 6 months will be preserved - Every 5th build for the past two years will be preserved. - The first and last build of any given release will be preserved in perpetuity. Would that work? That would mean that someone would always have the means to make a meaningful comparison between say, build 1 and build 70. When an SCM arrives, this becomes largely academic, you'd be able to get at any specific build (or individual putback) via the SCM. You can recreate the tools from that specific tree. The only thing that *may* pose a barrier would be the closed-bins, where applicable. I don't think it's unreasonable for anyone wanting access to historic moment-in-time trees to do so via the SCM, rather than a cycling set of archived builds, and a few perpetually present builds. It's somewhere between infeasible and you'd-rather-kill-yourself-instead painful to do this with teamware as we use it today, so perhaps that's my teamware-centric view of the world showing through. With Mercurial: hg up revision or tag # to bring your existing workspace 'back in time' hg clone -r revision or tag onnv-clone onnv-somebuild # to clone a fresh, but historic workspace. But I think it'd also be nice to keep the BFU archives, etc. around according to some policy. I hadn't considered the archives (I don't tend to use them), but I do agree they could come in useful for pinpointing when a problem was introduced, and similar things. -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: B37 fails to build with Text relocation remains against symbol unknown in /usr/lib/64/values-xpg6.o
Roland Mainz [EMAIL PROTECTED] writes: Hi! Trying to build B37 on i386 with Sun Studio 10+all recommended compiler patches fails like this: Recommended how? http://www.opensolaris.org/os/community/tools/sun_studio_tools/ Is the compiler you want to be using. While I'm not sure whether that's the problem or not, I've certainly built b37 and variations on i386 several times with them. Is this a known problem ? Build sequence was make closedbins ; make setup ; make ... It really is much easier to use nightly(1)... -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: onnv and SXCR delivery status
Rich Teer [EMAIL PROTECTED] writes: On Tue, 9 May 2006, Dennis Clarke wrote: I ask this because Stephen Lau released 20060508 a few hours ago and I just went through a build/BFU/ACR reboot cycle and all looks swell. Am I looking at doing this again on Friday or can I sit here happy ? My guess woould be the former. My understanding is that build n is a moving target, until that build is declared done (roughly speaking). So 20060508 is what will become build 39 in a few days time. An incomplete snapshot, so to speak. But I could also be way off base here. :-) http://www.opensolaris.org/os/community/onnv/onnv_schedule.txt The 2006-05-08 drop is a snapshot from the date the gate closed on b40. -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Project Proposal: iSCSI Target
Rick McNeal [EMAIL PROTECTED] writes: I would like to propose the creation of a new project page for the iSCSI Target work. This would enable the community to gain early access to this project before integration into Solaris Nevada is complete. The project currently consists of: RFC3720 - iSCSI protocol SAM-3 -- SCSI architecture module SPC-3 -- SCSI Primary Commands SBC-2 -- SCSI Block Commands SSC-3 -- SCSI Streaming Commands The tape support is very limited at this point. Media changer support is really really needed before it's very useful. There's also a pass through mode with very limited interpretation. Initial team: Rick McNeal +1 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Jonathan Schwartz and OpenSolaris GPLv3
Joerg Schilling wrote: [EMAIL PROTECTED] wrote: While this may sound nice, it would open the new problem that contributors may license new stuff for OpenSolaris under the GPLv3 only making it impossible for Sun to include the stuff in Sun Solaris. But isn't it the case that GPLv3 has far fewer restrictions (is more CDDL like) than GPLv2? It has fewer restrictions, but it still does not explicitly allow to merge code that is under another OSI aproved license. And even iff, one important reason for creating the CDDL was to allow to merge with CSS code as Sun did tell us this was needed in order to be able to create Sun Solaris. The page in question specifically states 'dual licensed', with one of them being the CDDL. -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: CIFS group creation request.
Mark Sweeney wrote: Thanks Stephen and Eric. My intent is to produce a community. The development effort will be in-house, then released as open source once it is completed. I'm not sure if this is just confusion stemming from the wording, or if there are other issues involved. But taken at face value, I think that's exactly the wrong thing to do. Developing things In house and the releasing them when complete is something I suspect most (all?) of us have been hoping wouldn't happen. If this *is* the intent, could I ask why that's the case? -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Please update 4113420 (request for ksh93 integration)
Felix Schulte wrote: [snip] And you do not have to think through - somewhere one or more of your engineers have Roland Mainz's ksh88-to-ksh93 migration plan which is pretty much straightforward and handled most of the issues. However, the rest of us on this alias don't. Perhaps you could post it here so we can all see it? -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: NetBSD's pkgsrc on OpenSolaris
Joerg Schilling wrote: Darren J Moffat [EMAIL PROTECTED] wrote: On Wed, 2006-01-04 at 13:34, Joerg Schilling wrote: We would need a few simple extensions to pkgadd to increase the usability. Which are ? It can already download packages over http or https (with support for proxies specified in the environment or as arguments) , it seems a lot of people don't know this. There are more (I curently don't remember the other ones) but the most important would be to make pkgadd able to autmatically install a list of packages in the right order, BTW: I see a http proxy option but no hint on how to use pkgadd via the network. Specify a URL in place of the normal filename. You're right though, it doesn't appear to be documented in pkgadd(1M), or anywhere else I can find. -- Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] i nstalling opersolaris
Joerg Schilling wrote: thomas rinehart [EMAIL PROTECTED] wrote: i have a p3 750 with 384 mb a 20 gig hd with win98,ubuntu5.10 and debian sarge all installed and working fine however when i try to install opensolaris the schllix distro it tells me i dont have enough memory im new to solaris and could use some help I don't see any reason why schillix should have problems to run on 384 MB. The default boot selection needs 128 MB (and states to need 256MB). It may be that you have problems with your BIOS and the BIOS does not tell grub the complete memory size. You should read the documentation of your motherboard on how to add RAM. It's also possible that grub's module loading doesn't get along well with Memory hole at 15-16MB type BIOS options being enabled, but that's nothing more than suspicion. I've been trying to track down why a friend's machine fails to boot Nevada in a similar way, and that's currently my best (and only) guess. - Rich. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to create /var/sadm/* info for OpenSolaris
Darren J Moffat wrote: On Wed, 2005-11-23 at 12:39, Joerg Schilling wrote: Hi, if I like to create a SchilliX that is able to deal with Blastwave packages, I would need to populate the SUNW* related package database for a SchilliX installation. Is there a simple way to do this without really running pkgadd? Or is there a way to create complete SUNW* packages from the ON sourcetree and then run pkgadd -R root-path for the SchilliX template directory? The -p flag to nightly(1) creates package for everything in the ON gate that is shipped - NOTE what ends up in the proto area and what gets bfu'd on to your machine is a superset of that. The package definition files are in $SRC/pkgdefs, you should be able to run make install in subdirs in there to build specific packages. I haven't tried that in a pure OpenSolaris source tree yet. It doesn't fully work (as is mentioned in the release notes), some packages you can build without changing anything. Several more build if you add: $(ON_CLOSED_BINS)/root_$(MACH) to the list of roots given to the -r option to the pkgmk invocation in $SRC/pkgdefs/Makefile.targ's pkg target to make it pull binaries out of closed-bins. The others left that don't build contain binaries that are neither present in the source or closed binaries. For a pure OpenSolaris system, where those binaries can't be distributed anyway, stripping them out of the package prototypes may work well enough, but I'm not certain. By my (possibly inaccurate) count: of the 317 total packages in $SRC/pkgdefs, 201 build after the change to Makefile.targ. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Can opensolaris support Zones now?
Li Gen wrote: Hello, Does anyone know that whether Zones can run in opensolaris. I have read ReleaseNote, and it said that : Zones are not usable on OpenSolaris, due to missing package support and tools. But I do notice that there really are some codes about Zones in opensolaris kernel. So I confuse that what the missing package support and tools are. Could anyone give me some answer? I'm very appreciate in advance. Best regard, When zones are created, the package tools are used to populate the zone filesystem. Those tools aren't yet open. The source that implements zones is open, and compilable. If you build the source and BFU a Solaris Express, or Solaris Express Community system, zones will function (as far as I'm aware). BeleniX apparently has a method to work around the lack of package tools, and zones work there too. I don't believe they're usable on a SchilliX system, however. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
