EOF evolution-jescs [LSARC/2010/027 FastTrack timeout /02/02/2010]
Milan, I just asked our desktop RE (Dave Lin) and he told me currently it is still in the SVR4/IPS transition period, and it is no harm to deliver the ph files. If it is not needed when we do the real remove in B140, we can just ignore that step. Thanks, Harry On Mon, 2010-01-25 at 16:06 +0100, Milan Jurik wrote: > Hi, > > Harry Lu p??e v po 25. 01. 2010 v 22:48 +0800: > > John, > > > > The package history is usually handled by our desktop REs. So yes, > > I think they will create one for this EOF. > > > > Isn't package history only for SVR4 packaging? And this has only minor > binding. > > Best regards, > > Milan > > > Thanks, > > Harry > > > > On 2010/1/25 22:06, John Fischer wrote: > > > Jeff, > > > > > > Will there be package history files for folks upgrading from one > > > build to another? > > > > > > Otherwise, +1. > > > > > > John > > > > > > > > > On 01/24/10 07:33 PM, Qing-Ming Jeff Cai wrote: > > >> > > >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > > >> This information is Copyright 2010 Sun Microsystems > > >> 1. Introduction > > >> 1.1. Project/Component Working Name: > > >> EOF evolution-jescs > > >> 1.2. Name of Document Author/Supplier: > > >> Author: Jedy Wang > > >> 1.3 Date of This Document: > > >> 24 January, 2010 > > >> 4. Technical Description > > >> 1. Introduction > > >> 1.1. Project/Component Working Name: > > >> EOF of evolution-jescs > > >> 1.2. Name of Document Author/Supplier: > > >> Author: Jedy Wang > > >> 1.3 Date of This Document: > > >> 15 January, 2010 > > >> > > >> 4. Technical Description > > >> 1.0 Description: > > >> > > >> EOF of evolution-jescs > > >> > > >>1.1 Project Detail > > >> > > >>This project proposes to remove evolution-jescs in Solaris. > > >> > > >>The evolution-jescs module is the Sun Calendar backend for the > > >>Evolution mail client. It provides Evolution with the ability > > >>to connect with the Sun Calender server. > > >> > > >>Since 2.29.x, the Evolution community has begun to remove the > > >> Bonobo > > >>dependency and has changed the architecture. Since > > >> evolution-jescs has a > > >>strong dependency on Bonobo and the old architecture, it won't > > >> work > > >>moving forward. For these reasons, it will be deprecated. > > >> > > >>The following reasons explain why the removal of > > >> evolution-jescs will > > >>have little impact to the end-user. > > >> > > >>1) The Lightning Thunderbird plugin (LSARC/2007/043) supports > > >> the Sun > > >> Calendar server already and Thunderbird is the default > > >> mailer for > > >> Solaris. > > >> > > >>2) The new Sun Calendar server (v7) released in 2009 uses a > > >> new protocol > > >> called CalDAV and the support for the old protocol will be > > >> limited to > > >> and tailored for the Convergence client and Outlook > > >> connector support. > > >> > > >>3) Both Lightning and Evolution support CalDAV, so both of > > >> them can > > >> support the new calendar server. > > >> > > >>4) After the removal of evolution-jescs, users who want to > > >> continue to > > >> use the old Sun Calendar Server need only to setup a new > > >> Sun Calendar > > >> server account in thundbird to migrate from Evolution to > > >> Thunderbird > > >> which is fairly simple. > > >> > > >>1.2 Packaging and Release Binding > > >> > > >>SUNWevolution-jescs will be removed in a minor release binding. > > >> > > >>1.3 Documentation > > >> > > >>N/A > > >> > > >>1.4 Dependency > > >> > > >>The removal of this project
Update to GNOME 2.26 media applications [LSARC/2009/202 FastTrack timeout 04/03/2009]
Brian, Since 2009/201 Update to Brasero 2.25.x has been approved, will you please update this case's one-pager and reset the timer? Thanks, Harry On Wed, 2009-04-01 at 12:48 -0500, Brian Cameron wrote: > After doing some research we realized that totem does not link against > libbrasero-burn directly, but instead just calls the "brasero" > application to support CD burning. Therefore, there is no need to > modify the exec_attr(4) file for totem. However, both sound-juicer > and rhythmbox do link directly against libbrasero-burn, so these > libraries still need the change to exec_attr(4). > > I have updated the one-pager for LSARC 2009/202 to reflect this and > you can find it attached as well. > > >> I have been copying all discussion to the 2009/201 case, which I > >> think is more appropriate for this discussion. Can we please > >> continue discussion there? > > > > Done. In the mean time please mark this case as "waiting need spec" and > > note that it depends on the outcome of 2009/201. > > Thanks, I have done this as well. > > Brian -- Harry.Lu at Sun.COM Solaris Desktop Group, Sun Microsystems Tel: +86-10-82618200 ext. 82870/ +86-10-62673870 Fax: +86-10-62780969
Gkrellm for OpenSolaris [LSARC/2008/513 FastTrack timeout 08/19/2008]
> > As I know, we have ACPI in 2008.5, but not APM, need to dig into the > codes to see if all is OK to call it to implement the battery support, > if so, will add.. Thanks... >> Henry, There is a HAL interface used by G-P-M and battery status applet for the battery info. Please talk with Simon and Jeff about that. Harry
DKIOCREADONLY [PSARC/2009/656 FastTrack timeout 12/07/2009]
Will the new interface be used to fix http://defect.opensolaris.org/bz/show_bug.cgi?id=252 ? Thanks, Harry On Tue, 2009-12-01 at 15:20 -0800, Garrett D'Amore - sun microsystems wrote: > The following case is so obvious that it could possibly be scoped as an > automatic case. However, given that it is introducing a new Committed > ioctl, its a fast-track. > > - Garrett > > 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: >DKIOCREADONLY > 1.2. Name of Document Author/Supplier: >Author: Garrett D'Amore > 1.3 Date of This Document: > 01 December, 2009 > 4. Technical Description > > Currently, the "hal" daemon that is responsible for automatically mounting > media is unable to mount read-only SDcard (write protect tab enabled) media, > because it has no way to detect this media needs to be mounted read only. > (hal is implemented with run-time checks for floppy media, and with a hard > coded rule for CDROM media.) > > What is needed is a generic run-time check via an ioctl, that hal can use > to determine if it is appropriate to perform a read-only mount. > > Therefore, we propose a new ioctl code be added to dkio(7I), as follows > (note that this is in the style of the existing man page, which is technically > not quite right): > >DKIOCREADONLY > > The argument to this ioctl() is an integer. After suc- > cessful completion, this ioctl() sets that integer to > a non-zero value if the drive in question has read-only >media. If the media is writable, or not present, the >integer is set to 0. > > (Technically, the argument is *pointer* to an integer, but that's true > for the other ioctls documented in dkio(7D).) > > Note that sd(7D) does not currently implement this, and will return > an errno (ENOTTY, I believe). > > We request "patch" binding for this ioctl (although we have no plans to > backport), and Committed stability level. > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > ___ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org -- Harry.Lu at Sun.COM OpenSolaris Desktop Group, Sun Microsystems Phone ext. 82870
EOF evolution-jescs [LSARC/2010/027 FastTrack timeout /02/02/2010]
John, The package history is usually handled by our desktop REs. So yes, I think they will create one for this EOF. Thanks, Harry On 2010/1/25 22:06, John Fischer wrote: > Jeff, > > Will there be package history files for folks upgrading from one > build to another? > > Otherwise, +1. > > John > > > On 01/24/10 07:33 PM, Qing-Ming Jeff Cai wrote: >> >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2010 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> EOF evolution-jescs >> 1.2. Name of Document Author/Supplier: >> Author: Jedy Wang >> 1.3 Date of This Document: >> 24 January, 2010 >> 4. Technical Description >> 1. Introduction >> 1.1. Project/Component Working Name: >> EOF of evolution-jescs >> 1.2. Name of Document Author/Supplier: >> Author: Jedy Wang >> 1.3 Date of This Document: >> 15 January, 2010 >> >> 4. Technical Description >> 1.0 Description: >> >> EOF of evolution-jescs >> >>1.1 Project Detail >> >>This project proposes to remove evolution-jescs in Solaris. >> >>The evolution-jescs module is the Sun Calendar backend for the >>Evolution mail client. It provides Evolution with the ability >>to connect with the Sun Calender server. >> >>Since 2.29.x, the Evolution community has begun to remove the >> Bonobo >>dependency and has changed the architecture. Since >> evolution-jescs has a >>strong dependency on Bonobo and the old architecture, it won't >> work >>moving forward. For these reasons, it will be deprecated. >> >>The following reasons explain why the removal of >> evolution-jescs will >>have little impact to the end-user. >> >>1) The Lightning Thunderbird plugin (LSARC/2007/043) supports >> the Sun >> Calendar server already and Thunderbird is the default >> mailer for >> Solaris. >> >>2) The new Sun Calendar server (v7) released in 2009 uses a >> new protocol >> called CalDAV and the support for the old protocol will be >> limited to >> and tailored for the Convergence client and Outlook >> connector support. >> >>3) Both Lightning and Evolution support CalDAV, so both of >> them can >> support the new calendar server. >> >>4) After the removal of evolution-jescs, users who want to >> continue to >> use the old Sun Calendar Server need only to setup a new >> Sun Calendar >> server account in thundbird to migrate from Evolution to >> Thunderbird >> which is fairly simple. >> >>1.2 Packaging and Release Binding >> >>SUNWevolution-jescs will be removed in a minor release binding. >> >>1.3 Documentation >> >>N/A >> >>1.4 Dependency >> >>The removal of this project is dependent upon the integration >>of Lightning (LSARC/2007/043) which has been already >> integrated into >>Solaris. >> >> 2.0 Interface Tables >>2.1 Removed Interfaces >> >>Interface StabilityComments >>- --- - >>/usr/lib/evolution/*/evolution-jescs >> Obsolete GUI >>Uncommitted >> >> /usr/lib/evolution-data-server-1.2/camel-providers/libcamelsunone.so >> Obsolete Library >>Project >>Private >>SUNWevolution-jescsObsolete Package >>Uncommitted >> >> >>2.2 Imported Interfaces >>InterfaceStability Comments >>--- -- >>N/A >> >> 3.0 References >> >> LSARC 2007/043 Lightning 0.3 >> LSARC 2003/298 Sun Evolution >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> Desktop >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> ___ >> opensolaris-arc mailing list >> opensolaris-arc at opensolaris.org > ___ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org
W3M [LSARC/2008/346 FastTrack timeout 06/03/2008]
???Including the project team in this thread. Harry On Wed, 2008-05-28 at 23:28 -0500, Brian Cameron wrote: > Could you explain why W3M is needed on Solaris. The FastTrack doesn't > seem to indicate what need it fills. Dan has suggested elinks is a > better text-based web browser. Did we consider elinks? What made us > want to integrate w3m instead of other alternatives? > > Brian > > > Shi-Ying Irene Huang wrote: > > Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI > > This information is Copyright 2008 Sun Microsystems > > 1. Introduction > > 1.1. Project/Component Working Name: > > W3M > > 1.2. Name of Document Author/Supplier: > > Author: Rick Ju > > 1.3 Date of This Document: > > 27 May, 2008 > > 4. Technical Description > > 1. Introduction > >1.1. Project/Component Working Name: > > > > w3m a text-based WWW browser > > > >1.2. Name of Document Author/Supplier: > > > > Author: Rick Ju > > Sponser:Irene Huang > > > >1.3. Date of This Document: > > > > 05/11/2008 > > > > 2. Technical Description: > > 2.1. Details: > > > > w3m is a text-based web browser as well as a pager like `more' or > > `less'. > > With w3m you can browse web pages through a terminal emulator window > > (xterm, rxvt or something like that). Moreover, w3m can be used as a > > text formatting tool which typesets HTML into plain text. > > > > w3m has support for tables, frames, SSL connections, color and even > > inline > > images on suitable terminals. Generally, it renders pages in a form as > > true > > to their original layout as possible. And W3m is small. Its stripped > > binary for Sparc is only 260kbyte. > > > > w3m locally run cgi scripts to test html output (requires *no* > > webserver). > > w3m keystroke compatible with lynx and support the keybindings > > customize. > > w3m support SSL through the openssl library. And w3m could support > > cookies. > > > > Table rendering algorithm in w3m > > > > HTML table rendering is difficult. Tabular environment of LaTeX is not > > very > > difficult, which makes the width of a column either a specified value > > or > > the maximum width to put items into it. On the other hand, HTML table > > renderer has to decide the width of a column so that the entire table > > can > > fit into the display appropriately, and fold the contents of the table > > according to the column width. Inappropriate column width decision > > makes > > the table ugly. Moreover, table can be nested, which makes the > > algorithm > > more complicated. > > > > 1. First, calculate the maximum and minimum width of each column. The > > maximum width is the width required to display the column without > > folding the contents. Generally, it is the length of paragraph > > delimited by or . The minimum width is the lower limit > > to display the contents. If the column contains the word > > `internationalization', the minimum width will be 20. If the column > > contains .., the maximum width of the preformatted > > text will be the minimum width of the column. 2. If the width of > > the column is specified by WIDTH attribute, fix the column > > width using that value. If the specified width is smaller than the > > minimum width of the column, fix the column width to the minimum > > width. > > > > 3. Calculate the sum of the maximum width (or fixed width) of each > > column > > and check if the sum exceeds the screen width. If it is smaller than > > screen width, these values are used for width of each column. > > > > 4. If the sum is larger than the screen width, determine the widths of > > each column according to the following steps. > > 1. Let W be the screen width subtracted by the sum of widths of > > fixed-width columns. > > 2. Distribute W into the columns whose width are not decided, in > > proportion to the logarithm of the maximum width of each column. > > 3. If the distributed width of a column is smaller than the minimum > > width, then fix the width of the column to the minimum width, > > and do the distribution again. > > > > In this process, distributed width is proportion to logarithm of > > maximum width. > > > > The algorithm above assumes that the screen width is known. But it is > > not > > true for nested table. According the algorithm above, the column width > > of > > the outer table have to be known to render the inner table, while the > > total > > width of the inner table have to be known to determine the column width > > of > > the outer table. If WIDTH attribute exists there are no problems. > > Otherwise, w3m ass
