Bart Smaalders wrote:
> If you want auditing and RBAC, figure out a way to do so that doesn't
> place so heavy a tax on every project that wants to deliver on Solaris.
> Rewriting or adding commands to every project is not acceptable -
> and is pointless so long as we don't even fund command line i
Hi,
It was the problem with the usb 2.0 itself, when i just disabled it and tried
,booting,solaris worked flawlessly!
Thanks a lot for your help... :-)
This message posted from opensolaris.org
Garrett D'Amore wrote:
> Nicolas Williams wrote:
>> IMO not all configuration files can have admin CLIs/APIs/GUIs without
>> enormous expense, and maybe some can't really have any that are all that
>> great (think pam.conf(4)[*]).
>>
>> ZFS audit SACLs ought to take care of the auditing issue (thou
Danek Duvall wrote:
> On Fri, Apr 04, 2008 at 07:39:47PM +0100, Darren J Moffat wrote:
>
>> I have no issue with the removal per say. Even though I personally do use
>> hgmerge - though I use a modified version of it in ~/bin/hgmerge (modified
>> to run twmerge or gpyfm).
>
> That'll continue
Danek Duvall wrote:
> I'm sponsoring this case for myself; the release binding is Minor.
>
>
> As part of "Mercurial integration" (PSARC/2006/417), hgmerge(1) was
> documented as Committed.
>
> This project specifies the removal of that utility. No version of Solaris
> has shipped yet with that
Scott Rotondo wrote:
> Joseph Kowalski wrote:
>>
>> Behind in my mail,...
>>> Because let's face it, without wine(1) I think this case is woefully
>>> incomplete. And make sure to include the --red, --white, --ros?,
>>> --varietal=VARIETAL, and other important options. This being FOSS we'll
>>> j
Case is approved.
-Artem
On Fri, Apr 04, 2008 at 12:33:13PM -1000, Joseph Kowalski wrote:
> Let's make sure this change is widely advertised.
Indeed. I don't expect anything that hasn't dug into undocumented API to
fail, but if it does, I (and the hg developers) will want to hear about it.
Please feel free to send me (p
On Fri, Apr 04, 2008 at 10:50:11PM +0100, Jeremy Harris wrote:
> Bart Smaalders wrote:
> >If you want auditing and RBAC, figure out a way to do so that doesn't
> >place so heavy a tax on every project that wants to deliver on Solaris.
> >Rewriting or adding commands to every project is not acceptab
arc/attachments/20080404/43bd7d75/attachment.txt>
On Fri, 2008-04-04 at 12:03 -0700, Danek Duvall wrote:
> I know of no other incompatible change, and the rest of the
> change includes new modules (which wasn't something I'd exported in the
> original case), and a few new options to existing commands.
new options are often arc-worthy, especially
I am sponsoring the following case on behalf of Eunice Moon
as a fast-track with timeout set to 04/14/2008.
The project requests minor binding.
Libvirt for LDoms (Logical Domains) support
===
ARC Exposure: open
1. Background
The Libvirt for LDoms softw
On Fri, Apr 04, 2008 at 08:19:31PM +0100, Darren J Moffat wrote:
> > This project introduces additional configuration *beyond* pam.conf.
>
> and there is precedence in other cases where PAM modules have config
> files that are text and not in SMF. Those other cases are not even that
> old (and p
Name: libpqxx - Provide C++ API to PostgreSQL for Solaris
Submitter: Geir Green
Owner: James Gates
Interest:
Status: closed approved fast-track 04/04/2008
Exposure: open
Comment:
IMO not all configuration files can have admin CLIs/APIs/GUIs without
enormous expense, and maybe some can't really have any that are all that
great (think pam.conf(4)[*]).
ZFS audit SACLs ought to take care of the auditing issue (though, of
course, turning on file auditing will take care of it no
> On Thu, Apr 03, 2008 at 08:45:53PM -0700, Bart Smaalders wrote:
> > John Zolnowsky x69422/408-404-5064 wrote:
> >
> > >The general nature of mmapfd() mapping represents a possible solution
> > >to a concern being discussed in 2008/195. The issue is that
> > >interpreters other than rtld often h
On Fri, Apr 04, 2008 at 03:31:55PM -0400, Bill Sommerfeld wrote:
> new options are often arc-worthy, especially if scripts would benefit
> from using them.
The original case plopped all the options under a single umbrella without
enumerating them. I claim that the new ones follow suit, and also
Darren J Moffat wrote:
> Either way this case can proceed as is, I'd just like to know so of
> the sync issues since I'm a heavy mercurial user at the moment.
As are most Sun JavaSE developers. Worse yet, these poor people are all
hg novices (me too!) who will have trouble understanding any unex
Nicolas Williams wrote:
> IMO not all configuration files can have admin CLIs/APIs/GUIs without
> enormous expense, and maybe some can't really have any that are all that
> great (think pam.conf(4)[*]).
>
> ZFS audit SACLs ought to take care of the auditing issue (though, of
> course, turning on fi
On Fri, Apr 04, 2008 at 07:39:47PM +0100, Darren J Moffat wrote:
> I have no issue with the removal per say. Even though I personally do use
> hgmerge - though I use a modified version of it in ~/bin/hgmerge (modified
> to run twmerge or gpyfm).
That'll continue to work, actually. Mercurial w
Bart Smaalders wrote:
>> Add a CLI utility to administer the file contents. Don't rely on
>> "vi" as the only administrative interface.
>
> For simple interfaces, we sort of manage, although we've punted
> on massive amounts of those as well, and I don't see the resources
> dedicated to addressin
Alan Coopersmith wrote:
> Of course, like most big rules & SAC policies, we only apply to new projects,
> and the trivial way to be exempted is to leave the old code untouched and
> not come back to ARC with any enhancements, effectively encouraging
> stagnation.
>
+1
- jek3
On Thu, Apr 03, 2008 at 08:45:53PM -0700, Bart Smaalders wrote:
> John Zolnowsky x69422/408-404-5064 wrote:
>
> >The general nature of mmapfd() mapping represents a possible solution
> >to a concern being discussed in 2008/195. The issue is that
> >interpreters other than rtld often have the equi
On Thu, Apr 03, 2008 at 05:29:50PM -0700, Michael Corcoran wrote:
> Thanks Gary.
>
> Reading through the 1.1 Design doc for validated execution, it's clear
> that there is a bit of interaction between these two projects. At the
> very least mmapfd(2) or more likely mmapobj(2) will need to be adde
Wyllys Ingersoll wrote:
> I disagree. For many weeks now the submitter has answered the
> questions and made all of the corrective actions requested by the ARC on
> this case and now there is talk of derailing it?I don't think any
> architectural issues were found with the project. The do
Garrett D'Amore wrote:
> Bart Smaalders wrote:
>> Garrett D'Amore wrote:
>>
>>
>> Simply stopping the addition of open source software to Solaris
>> in order to meet auditing requirements for /etc files (which we
>> don't meet anyway w/ the stuff we've shipped for years) seems
>> ludicrous.
>
> I
I'm sponsoring this case for myself; the release binding is Minor.
As part of "Mercurial integration" (PSARC/2006/417), hgmerge(1) was
documented as Committed.
This project specifies the removal of that utility. No version of Solaris
has shipped yet with that interface, and the project team ass
Garrett D'Amore wrote:
>> The "auditable administration" question was answered already - there
>> is no auditable interface for any PAM configuration files or any other
>> files that are managed via "vi" (or whatever editor) for that matter.
>
> I didn't see the answer in the mail log. Managing
James C. McPherson wrote:
> No doubt we'd need to have one for duff(1), dufflite(1) and duffzero(1),
> and another one for fosters(1) too, with a See Also that mentions both
> bud(1) and coors(1).
Can these be made compatible? Instead of duplicating the code
needlessly, perhaps we could have a
arc/attachments/20080404/6b04b1cb/attachment.html>
Joseph Kowalski ??:
> So this appropriate ocaml compilers is captured beside the Unison
> sources?
Yes.
Considering that it's not of general purpose usage, it will not be
delivered to end user.
Frank.
Ok, I'm confused.
If the documentation isn't part of the review, and the user experience
isn't really part of the review (by corollary), and the project team
isn't interested in changing anything, then why exactly are we reviewing
this case?
I don't know that I feel TCR strong on much about th
Bart Smaalders wrote:
> Garrett D'Amore wrote:
>
>
> Simply stopping the addition of open source software to Solaris
> in order to meet auditing requirements for /etc files (which we
> don't meet anyway w/ the stuff we've shipped for years) seems
> ludicrous.
I don't think you understand what "der
33 matches
Mail list logo
