+1. (I cheated -- I've seen the case materials ahead of time. :-)
This enhancement (and the need to perform subsequent actions to
decompress the crash dump) probably deserves special mention in the
Release Notes. I'd also add, in retrospect, it seems like perhaps mdb
ought to have its man pag
I am sponsoring this fasttrack for Dave Plauger and Steve Sistare. The
timer is set for next Tuesday August 18, 2009. Requesting Micro/Patch
binding.
The one-pager, project specification and man page diffs are available
in the materials directory.
Sherry Moore
Template Version: @(#)sac_nextcas
Roland Mainz wrote:
> Garrett D'Amore wrote:
>
>> Peter Cudhea wrote:
>>
>>> It would be useful to take a definitive stand on whether or not
>>> operations on two adjacent bool values are atomic with respect to one
>>> another. E.g. back in the days of the DEC Alpha, there existed no
>>> i
Margot:
> Do you guys have the contract for HAL interfaces? I didn't
> see it in case directory. Do you need a contract for volatile
> Dbus interfaces?
Here is the Desktop team's contract with HAL:
http://sac.eng.sun.com/arc/LSARC/2006/462/contracts/PSARC-2005-399-Tamarack.txt
D-Bus is a part
Alan:
> Brian Cameron wrote:
>> 4.1.1 Detail About ConsoleKit Database
>> # Device associated with Xserver running session (if any).
>> x11_display_device=/dev/console
>> 4.1.5 Environment Variables
>>CK_SESSION_X11_DISPLAY_DEVICE - The device associated with the
Garrett D'Amore wrote:
> Darren J Moffat wrote:
>> Garrett D'Amore wrote:
>>> Putting all the certs in one mondo file gives me a few minor
>>> concerns, which might be insignificant, but I want to ask them anyway:
>>>
>>> 1) Do end users have any control over which CAs they do or do not
>>> trust
Garrett D'Amore wrote:
> Putting all the certs in one mondo file gives me a few minor concerns,
> which might be insignificant, but I want to ask them anyway:
>
> 1) Do end users have any control over which CAs they do or do not
> trust? (What if they want all of the CAs except one?)
The end u
Glenn:
>> If configured, GDM can will display "Shutdown" and "Restart" buttons
>> for shutting down and restarting the machine. Refer to section 4.1.9
>> for more information.
> This should not be configured by default if the user is not authenticated.
The "gdm" is not configured to have the sol
Mark Martin wrote:
>>> Instead the discussion should maybe stick to just the question of
>>> what the default HTTPS setting should be, whether Darren's suggestion
>>> of linking this case to shipping a working root CA file is
>>> appropriate, and how to document how to load alternate certs.
>>
>
Alan:
> I don't see a mention in this case of GDM replacing dtlogin as the
> default login screen, and EOL'ing dtlogin - is that going to be
> handled by this case or are you going to bring LSARC 2005/417 back
> again to do that at the same time as this case integrates?
I would prefer to handle
Brian Cameron wrote:
>
> Alan:
>
>> I don't see a mention in this case of GDM replacing dtlogin as the
>> default login screen, and EOL'ing dtlogin - is that going to be
>> handled by this case or are you going to bring LSARC 2005/417 back
>> again to do that at the same time as this case integra
Brian Cameron wrote:
>4.1.1 Detail About ConsoleKit Database
> # Device associated with Xserver running session (if any).
> x11_display_device=/dev/console
>4.1.5 Environment Variables
> CK_SESSION_X11_DISPLAY_DEVICE - The device associated with the Xserver.
As previo
Brian Cameron wrote:
>
> If configured, GDM can will display "Shutdown" and "Restart" buttons
> for shutting down and restarting the machine. Refer to section 4.1.9
> for more information.
>
This should not be configured by default if the user is not authenticated.
>
Brian,
Do you guys have the contract for HAL interfaces? I didn't
see it in case directory. Do you need a contract for volatile
Dbus interfaces?
A nit- man pages should be listed outside the i/f tables.
Thanks
Margot
Brian Cameron wrote:
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
I don't see a mention in this case of GDM replacing dtlogin as the
default login screen, and EOL'ing dtlogin - is that going to be
handled by this case or are you going to bring LSARC 2005/417 back
again to do that at the same time as this case integrates?
--
-Alan Coopersmith-
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
GNOME Display Manager (GDM) Rewrite
1.2. Name of Document Author/Supplier:
Author: Brian Cameron
1.3 Date of
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
ConsoleKit
1.2. Name of Document Author/Supplier:
Author: Brian Cameron
1.3 Date of This Document:
1
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Moovida
1.2. Name of Document Author/Supplier:
Author: Brian Cameron
1.3 Date of This Document:
11 A
In checking with the project and team researching the history of the
API, the API seems to be very stable.
The API is defined in the gs/psi/iapi.h file. From the time the API was
introduced in 2001-03-12, there has
been only one real API change, and that had to do with cleaning up the
interface
It would be useful to take a definitive stand on whether or not
operations on two adjacent bool values are atomic with respect to one
another. E.g. back in the days of the DEC Alpha, there existed no
instructions that could modify the value of one bool in a word without
potentially interfering
To have better HTTPS support for WebKit, I think we have two options:
- Work with the community to fix the bug in libsoup.
- Submit a bug/RFE to add Chrome's network stack as an alternative
network backend for WebKit.
Since libsoup is tightly integrated into GNOME, I'd think option 1 will
be a be
Darren J Moffat wrote:
>>
>> So the tools are responsible for making this check themselves, using
>> OCSP, right? That makes sense -- end users don't have to take any
>> specific action to get the CRL checking.
>
> In general they may use OCSP but not on the CA certs files only on the
> SSL ser
Hugh McIntyre wrote:
> Uros Nedic wrote:
>> [2] Let we extend libsoup with additional interfaces capable
>> to deal with this issue, or to change actual implementation
>> of interface we have conflict with.
>
> If you look at the following libsoup bugs, it looks like
> libsoup is planning to add n
Garrett D'Amore - sun microsystems wrote:
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
>sys/stdbool.h
+1
--
Darren J Moffat
Darren J Moffat wrote:
> Garrett D'Amore wrote:
>> Putting all the certs in one mondo file gives me a few minor
>> concerns, which might be insignificant, but I want to ask them anyway:
>>
>> 1) Do end users have any control over which CAs they do or do not
>> trust? (What if they want all of th
Putting all the certs in one mondo file gives me a few minor concerns,
which might be insignificant, but I want to ask them anyway:
1) Do end users have any control over which CAs they do or do not
trust? (What if they want all of the CAs except one?)
2) How are CRL handled?
3) How will updat
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Default system CA (X.509) Certificates
1.2. Name of Document Author/Supplier:
Author: Darren Moffat
1.3 Date
Peter Cudhea wrote:
> It would be useful to take a definitive stand on whether or not
> operations on two adjacent bool values are atomic with respect to one
> another. E.g. back in the days of the DEC Alpha, there existed no
> instructions that could modify the value of one bool in a word with
Darren J Moffat wrote:
> Hugh McIntyre wrote:
>> Uros Nedic wrote:
>>> [2] Let we extend libsoup with additional interfaces capable
>>> to deal with this issue, or to change actual implementation
>>> of interface we have conflict with.
>>
>> If you look at the following libsoup bugs, it looks like
Hi Uros,
Thanks for the suggestions.
I've sent email to Chrome developers with regards to the HTTPS support
of Chrome on Linux platform. The answer is that "Chrome does not use
libsoup on Linux." Actually they use their own custom network stack on
all platforms: http://src.chromium.org/viewvc/chr
30 matches
Mail list logo
