From hk67hk89@yahoo.com Sun Feb 3 20:34:04 2002 From: hk67hk89@yahoo.com (hk67hk89@yahoo.com) Date: Sun, 03 Feb 2002 12:34:04 -0800 Subject: . 1198 Message-ID: <0000022a6be4$00001fce$000004ae@>




 
 
YOU SAVE
20% to 50%
ON YOUR
PHONE BILL
EACH MONTH!
  
. . . and we'll donate 5% of your monthly phone bill
to t= he charity of your choice!
  • NO Monthly Service Charge!
  • NO Installation Fees!
  • Billed in 6 Second Increments!
  • O= nly 6.9=FFFFFFA2 Per Minute Interstate 24 Hours / 7 Days a Week!

    SAVE 20% to 50%
    on Your Phone Bill Each Mon= th!

    Click here to view and print form

    <= FONT color=3D#000000 face=3DArial size=3D2>NOTE: After the form loads o= n your screen, simply click the "print" button on your browser, fill out = the form and fax to 1-800-377-2125.

    		•



    1. No monthly service charge and no installation fees (s= avings $3.95 - $8.95 per month)
    2. Charges 6 second increments, not 60 seconds (savings = on average of 27 seconds billing on every call)
    3. Low intrastate rates (saving you money on expensive c= alls within your own state)
    4. Rates are the same every day and every hour - 6.9=FF= FFFFA2! (saving you on expensive day rates of up to 25 cents per minute)=
    5. Add Toll free "800" service to existing lines or cell= phones at no additional installation charge or monthly fees and = only 6.9=FFFFFFA2 per minute interstate.
    6. Calling cards are available (16.5=FFFFFFA2 per minute= , 6-second increment billing) with no NBS surcharges for your calls and no = charge for the card(s).
    Sound too good to be true? Wel= l, it's not . . . it's true!

    The bottom line: AT&T, Sprint, MCI/Worldcom bills will be higher when all the charges are= added. You can easily save $100, $200, or more per year on your lo= ng distance bills, depending on your calling habits.

    Click here to view and print form

    <= FONT color=3D#000000 face=3DArial size=3D2>NOTE: After the form loads o= n your screen, simply click the "print" button on your browser, fill out = the form and fax to 1-800-377-2125. (Federal regulations requir= e your signature.)

    5% of your mont= hly phone bill goes to help and support the following charitable organizations:

    • Make a Wish Foundation
    • St. Judes Children's Hospital
    • The Miracle Network
    • Compassion International
    • or the charity of YOUR choice!


    Ask for your toll free number(s) on the form.
    Get a calling card if you wish.
    Don't wait, just do it today.
    You'll be glad you did!

    If you would like to be removed, please email us back with the = word "Remove" in the subject line. We apologize for any inc= onvenience.
     

    Premier Long Distance Network - A phone company that makes CENTS= !

    From phil@ipal.net Sun Feb 3 13:37:54 2002 From: phil@ipal.net (Phil Howard) Date: Sun, 3 Feb 2002 07:37:54 -0600 (CST) Subject: broken links in LSB 1.1.0 Message-ID: <20020203133754.8F7D9250@vega.ipal.net> The following links referenced in the Introduction page: http://developer.intel.com/design/itanium/downloads/24531702 http://developer.intel.com/design/itanium/downloads/24531802 http://developer.intel.com/design/itanium/downloads/24531902 http://developer.intel.com/design/itanium/downloads/24532002 http://developer.intel.com/design/ia-64/downloads/245358.htm do not work. Has Intel re-organized? [please reply direct or cc: me if you want me to see it, as I am not subscribed to the list] -- Phil Howard phil@ipal.net From nick@usenix.org Sun Feb 3 18:48:25 2002 From: nick@usenix.org (Nick Stoughton) Date: Sun, 3 Feb 2002 10:48:25 -0800 Subject: broken links in LSB 1.1.0 References: <20020203133754.8F7D9250@vega.ipal.net> Message-ID: <004901c1ace3$5cdc4e20$6601a8c0@nick.stoughton.name> Yes .. there are two problems here; the first is that the names got truncated, the second is that even then, intel moved them all. The correct links are now in the database (Stuart, can you confirm?), and should be: IA64 SDM Vol1: Itanium Architecture Software Developer's Manual Volume 1: Application Architecture http://developer.intel.com/design/itanium/downloads/24531703s.htm IA64 SDM Vol2: Itanium Architecture Software Developer's Manual Volume 2: System Architecture http://developer.intel.com/design/itanium/downloads/24531803s.htm IA64 SDM Vol3: Itanium Architecture Software Developer's Manual Volume 3: Instruction Set Reference http://developer.intel.com/design/itanium/downloads/24531903s.htm IA64 Processor Reference: Intel Itanium Processor Reference Manual for Software Development http://developer.intel.com/design/itanium/downloads/24532003s.htm IA64 ABI: Intel Itanium Processor-specific Application Binary Interface http://developer.intel.com/design/itanium/downloads/245370.htm IA64 Software Conventions: Itanium Software Conventions and Runtime Architecture Guide http://www.intel.com/design/itanium/downloads/24535803s.htm -- Nick Stoughton ----- Original Message ----- From: "Phil Howard" To: Sent: Sunday, February 03, 2002 5:37 AM Subject: broken links in LSB 1.1.0 > The following links referenced in the Introduction page: > > http://developer.intel.com/design/itanium/downloads/24531702 > http://developer.intel.com/design/itanium/downloads/24531802 > http://developer.intel.com/design/itanium/downloads/24531902 > http://developer.intel.com/design/itanium/downloads/24532002 > http://developer.intel.com/design/ia-64/downloads/245358.htm > > do not work. Has Intel re-organized? > > [please reply direct or cc: me if you want me to see it, as > I am not subscribed to the list] > > -- > Phil Howard > phil@ipal.net > > > -- > To UNSUBSCRIBE, email to lsb-spec-request@lists.linuxbase.org > with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org > From anderson@metrolink.com Sun Feb 3 22:17:38 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Sun, 3 Feb 2002 17:17:38 -0500 (EST) Subject: broken links in LSB 1.1.0 In-Reply-To: <004901c1ace3$5cdc4e20$6601a8c0@nick.stoughton.name> Message-ID: <20020203171656.S457-100000@trantor.sc.metrolink.com> On Sun, 3 Feb 2002, Nick Stoughton wrote: > Yes .. there are two problems here; the first is that the names got > truncated, the second is that even then, intel moved them all. The correct > links are now in the database (Stuart, can you confirm?), and should be: Yes, they should be there (and I'll double check anyway). End of last week, cvs on sourceforge was stuck, so I wasn't able to crank out the new version of the document with these fixed in it. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From cmprn111169@gm20.com Tue Feb 5 07:25:01 2002 From: cmprn111169@gm20.com (marketing@aboutjcmorris.com) Date: Tue, 5 Feb 2002 02:25:01 -0500 (EST) Subject: Company Merger Message-ID: <235773.1012893901005.Kada.Kada1(pc-72)@email2.gm20.com> ------=_Part_194950_6565857.1012893901005 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable YOU ARE RECEIVING THIS EMAIL BECAUSE YOU HAVE EXPRESSED INTEREST IN PRODUCT= S THAT WE CAN SAVE YOU MONEY ON. IF YOU WOULD LIKE TO BE REMOVED FROM OUR = MAILING LIST PLEASE CLICK THE UNSUBSCRIBE LINK AT THE BOTTOM OF THIS EMAIL.= WE CAN ASSURE YOU THAT YOU WILL BE REMOVED IMMEDIATELY. =09=09 IImportant Announcement from J.C. Morris & Company =09=09=09=09=09=09=09=09=09=09=09=09=09=09 For the past few years, our customers have enjoyed the ability to purchase = computers and related products from manufacturers like Sony, Apple, IBM, To= shiba and Compaq at prices below wholesale. Now, J.C. Morris & Company has teamed up with an additional distributor, Al= lied Interactive Micro-Systems, a company that specializes in the world-wid= e distribution of computer hardware, software and electronics, from manufac= turers like Bose, Pioneer and Canon. Here=92s your chance to get to know us, and from now until February 10, 200= 2 if you visit us on-line or in person and make a purchase, we will give yo= u an additional 25% off our current price. This is our way of saying thank= you for taking the time to visit our company. Sincerely, Jim Morris Vice President J.C. Morris & Company http://gm12.com/r.html?c=3D111249&r=3D111169&t=3D17546990&l=3D1&d=3D8169973= &u=3Dhttp://www.aboutjcmorris.com =09=09 Apple iMac $899.95 =09=09 http://gm12.com/r.html?c=3D111249&r=3D111169&t=3D17546990&l=3D1&d=3D8169973= &u=3Dhttp://www.aboutjcmorris.com =09=09 Tower Place Center Suite 1800, 3340 Peachtree Road NE Atlanta, GA 30326 1-800-845-6215 Click here: mailto:cmprn111169@gm20.com?subject=3Dunsubscribe!lsb-spec@list= s.linuxbase.org!17546990 to unsubscribe from our mailing list. Or reply to= this message with the word unsubscribe in the subject line. ------=_Part_194950_6565857.1012893901005 Content-Type: text/html Content-Transfer-Encoding: quoted-printable =09=09=09=09=09=09eNewsletter 2=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09
    For the past few years, our customers have enjoyed the ability to purchase= computers and related products from manufacturers like Sony, Apple, IBM, T= oshiba and Compaq at prices below wholesale.

    Now, J.C. Morris & Comp= any has teamed up with an additional distributor, Allied Interactive Micro-= Systems, a company that specializes in the world-wide distribution of compu= ter hardware, software and electronics, from manufacturers like Bose, Pione= er and Canon.

    Here=92s your chance to get to know us, and from now u= ntil February 10, 2002 if you visit us on-line or in person and make a purc= hase, we will give you an additional 25% off our current price. This is ou= r way of saying thank you for taking the time to visit our company.

    = Sincerely,
    Jim Morris
    Vice President
    J.C. Morris & Company
    Come visit us today!

    =

    =09=09=09=09=09=09=09=09

    =09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09

    YOU ARE RECEIVING THIS EMAIL BECAUSE YOU HAVE EXPRESSED INTEREST IN PRODUC= TS THAT WE CAN SAVE YOU MONEY ON. IF YOU WOULD LIKE TO BE REMOVED FROM OUR= MAILING LIST PLEASE CLICK THE UNSUBSCRIBE LINK AT THE BOTTOM OF THIS EMAIL= . WE CAN ASSURE YOU THAT YOU WILL BE REMOVED IMMEDIATELY.
    <= /font>=09=09
    IImportant Announcement from J.C. Morris & Compa= ny=09=09
    =09=09=09=09
    =09=09=09=093D""= =09=09=09=09
    =09=09=09=09=09=09=09=09

    =09=09=09=09=09=09=09=09
    =09= =09=09=09=09=09=09=09

    =09=09=09=09=09=09=09=09
    =09=09=09=09=09=09=09= =09

    =09=09=09=09=09=09=09=09
    =09=09=09=09=09=09=09=09

    =09=09=09=09= =09=09=09=09
    =09=09=09=09=09=09

    =09=09=09    		=09=09=09=09
    =09=09

    =09= =09=09=09
    =09=09=09=09

    =09=09=09=09


    Apple iMac

    $899.95

    =09=09=09=09=09

    =09=09=09=09
    Visit our Company on-line!=09=09=09=09
    Tower Place Center Suite 1800, 3340 Peach= tree Road NE

    Atlanta, GA 30326

    1-800-845-6215
    =
    =09=09
    =09=09=09=09

    Click here to unsubscribe from our mailing list. = Or reply to this message with the word unsubscribe in the subject line.


    ------=_Part_194950_6565857.1012893901005-- From mats.d.wichmann@intel.com Tue Feb 5 17:58:23 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Tue, 5 Feb 2002 09:58:23 -0800 Subject: CVS problems Message-ID: <39B5C4829263D411AA93009027AE9EBB15A71324@FMSMSX35> I'm having trouble syncing up with the CVS repository for about a week now. I know there's been some stuff committed in that time that I'd like to pick up. The problem is that as the update gets to the IA64/sgmlspec directory it hangs trying to get a lock: cvs server:[..date..] waiting for anoncvs_lsb's lock in /cvsroot/lsb/spec/archLSB/IA64/sgmlspec Anyway to unstick this? Thanks, Mats From anderson@metrolink.com Tue Feb 5 18:06:19 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Tue, 5 Feb 2002 13:06:19 -0500 (EST) Subject: CVS problems In-Reply-To: <39B5C4829263D411AA93009027AE9EBB15A71324@FMSMSX35> Message-ID: <20020205130445.Y457-100000@trantor.sc.metrolink.com> On Tue, 5 Feb 2002, Wichmann, Mats D wrote: > I'm having trouble syncing up with the CVS repository > for about a week now. > > I know there's been some stuff committed in that time > that I'd like to pick up. > > The problem is that as the update gets to the > IA64/sgmlspec directory it hangs trying to get a lock: > > cvs server:[..date..] waiting for anoncvs_lsb's lock in > /cvsroot/lsb/spec/archLSB/IA64/sgmlspec > > > Anyway to unstick this? I went to put in a support request for sourceforge to get this cleared, but I can no longer find the form that goes to them. If anyone knows where to find the support stuff that used to be there, please point it out. As a work-arund, remove the sgmlspec directory from your local tree. We aren't really using it anyway, and that way, this part gets skipped over, as long as you don't use '-d'. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From mats.d.wichmann@intel.com Thu Feb 7 16:37:57 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Thu, 7 Feb 2002 08:37:57 -0800 Subject: Spec: table layout gripe Message-ID: <39B5C4829263D411AA93009027AE9EBB15A71A86@FMSMSX35> I'm finding the library interface tables in the LSB spec terribly hard to read. The main problem is that they're formatted down, rather than accross, and some of the tables are big enough not to fit in a single browser window, nor on the printed page - you have to keep scrolling up and down or flipping pages just to look for a name. Does anyone else agree? If so, is it possible to look into having the tools spitting out the tables formatted across the page instead? Mats From anderson@metrolink.com Thu Feb 7 17:31:10 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Thu, 7 Feb 2002 12:31:10 -0500 (EST) Subject: Spec: table layout gripe In-Reply-To: <39B5C4829263D411AA93009027AE9EBB15A71A86@FMSMSX35> Message-ID: <20020207123047.R444-100000@trantor.sc.metrolink.com> On Thu, 7 Feb 2002, Wichmann, Mats D wrote: > If so, is it possible to look into having the tools spitting out the tables > formatted > across the page instead? Sure, that's possible. I did them vertically since the prior art was also done that way. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From mats.d.wichmann@intel.com Thu Feb 7 20:07:43 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Thu, 7 Feb 2002 12:07:43 -0800 Subject: confused by stdarg.h Message-ID: <39B5C4829263D411AA93009027AE9EBB15A71B94@FMSMSX35> My effort to compile using LSB headers launched me into a relatively thorough review of the headers and to file a bunch of bugs. Review / comment probably wouldn't hurt from some folks other than Stuart. Anyway, I have a question. What should be the spec stance with respect to headers that are provided by gcc. Several lsb headers use va_list, for example. va_list is not defined in any lsb header file, however there is a header that's supplied by gcc in the gcc-lib directory tree. In fact, I got here originally because I was having some conflicting defines where the lsb headers said something slightly different than the gcc-supplied stuff. Should the spec be "self-contained" or is it okay to depend on some things called out in the spec to actually be defined by gcc's own header files? Mats Wichmann From mats.d.wichmann@intel.com Fri Feb 8 18:22:13 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Fri, 8 Feb 2002 10:22:13 -0800 Subject: NSIG Message-ID: <39B5C4829263D411AA93009027AE9EBB15A71E88@FMSMSX35> Is NSIG supposed to be defined? The spec mentions it, in the context of this definition: extern const char *const _sys_siglist[NSIG]; NSIG itself is nowhere defined. Mats From gk4@austin.ibm.com Thu Feb 14 22:32:50 2002 From: gk4@austin.ibm.com (George Kraft IV) Date: Thu, 14 Feb 2002 16:32:50 -0600 Subject: REVIEW: psLSB-IA64 v0.9.9 until Thursday February 28th, 2002 Message-ID: <3C6C3B12.D00BE3FE@austin.ibm.com> The psLSB-IA64 v0.9.9 has been posted for public review. The review period ends in two weeks on Thursday February 28th, 2002. http://www.linuxbase.org/spec/lsbia64review.html PS: In the bugreview.html form, please specify in the text area of the form if the "Specification" is "gLSB", "psLSB-IA32", or "psLSB-IA64". Thanks, -- George Kraft IV gk4@austin.ibm.com Linux Standard Base From lawrencc@debian.org Tue Feb 19 02:42:38 2002 From: lawrencc@debian.org (Chris Lawrence) Date: Mon, 18 Feb 2002 20:42:38 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219022155.GC4806@wiggy.net> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> Message-ID: <20020219024238.GA7649@bellsouth.net> On Feb 19, Wichert Akkerman wrote: > Previously Chris Lawrence wrote: > > Will do. The uid/gid 1 issue is definitely an issue; Debian probably > > can't make that change, and I suspect many other LSB implementations > > would trip over it too if they have any POSIX already. > > We can just drop most of the standard accounts and become compatible > by simply not having an optional account. Most of bin/daemon/sync/etc. > aren't used anyway it seems. Unfortunately, the following accounts are required (per http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/usernames.html): USER GROUP UID GID root root 0 0 bin bin 1 1 daemon daemon X X X = unspecified On Debian: USER GROUP UID GID root root 0 0 bin bin 2 2 daemon daemon 1 1 So, either we need to figure out how to get bin and daemon to swap (or at least move daemon somewhere else and move bin from 2 to 1), or the spec needs to change. Frankly, I can't see any reason why uid/gid 1 should be assumed to be bin, especially since no other UIDs and GIDs are static (except 0, which is embedded in the kernel design...). After all, that's why we have getpwuid()... Chris -- Chris Lawrence - http://www.lordsutch.com/chris/ From andrew@pimlott.ne.mediaone.net Tue Feb 19 05:09:51 2002 From: andrew@pimlott.ne.mediaone.net (Andrew Pimlott) Date: Tue, 19 Feb 2002 00:09:51 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219024238.GA7649@bellsouth.net> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> Message-ID: <20020219050951.GA26563@pimlott.ne.mediaone.net> On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote: > Unfortunately, the following accounts are required (per > http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/usernames.html): > > USER GROUP UID GID > root root 0 0 > bin bin 1 1 > daemon daemon X X > > X = unspecified > > On Debian: > > USER GROUP UID GID > root root 0 0 > bin bin 2 2 > daemon daemon 1 1 > > So, either we need to figure out how to get bin and daemon to swap (or > at least move daemon somewhere else and move bin from 2 to 1), or the > spec needs to change. I would lobby to change the spec not to mention bin, daemon, or any of the optional users/groups, at all. They are not specified in a useful way, so they're at best dead-weight, and at worst an opportunity for conflicting interpretations. I filed a bug to this effect with a subject like "user specification is worse than useless". (The sourceforge page is down, so I can't find a URL now.) Andrew From Martijn van Oosterhout Tue Feb 19 05:54:05 2002 From: Martijn van Oosterhout (Martijn van Oosterhout) Date: Tue, 19 Feb 2002 16:54:05 +1100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219050951.GA26563@pimlott.ne.mediaone.net>; from andrew@pimlott.ne.mediaone.net on Tue, Feb 19, 2002 at 12:09:51AM -0500 References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> Message-ID: <20020219165405.B26966@svana.org> On Tue, Feb 19, 2002 at 12:09:51AM -0500, Andrew Pimlott wrote: > On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote: > I would lobby to change the spec not to mention bin, daemon, or any > of the optional users/groups, at all. They are not specified in a > useful way, so they're at best dead-weight, and at worst an > opportunity for conflicting interpretations. IIRC, I think the reasoning went as follows: - The LSB format is based on RPM which has a CPIO archive - CPIO archives store uid/gids as numbers, not names - Installed programs may want to use the daemon user - Hence the daemon user must have a fixed uid Tar stores names instead of numbers and so doesn't suffer from this problem. Note that once the program is running, it can use getpwent(). We're talking about silliness in cpio itself. I beleive the cpio new archive format fixes but it's not well supported. > I filed a bug to this effect with a subject like "user specification > is worse than useless". (The sourceforge page is down, so I can't > find a URL now.) Kind of funny that we would have to start changing the mappings of uids just because some people decided to use RPM as a standard install format. Ofcourse, I could be making this up... -- Martijn van Oosterhout http://svana.org/kleptog/ > Terrorists can only take my life. Only my government can take my freedom. From kukuk@suse.de Tue Feb 19 06:52:12 2002 From: kukuk@suse.de (Thorsten Kukuk) Date: Tue, 19 Feb 2002 07:52:12 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219165405.B26966@svana.org> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> <20020219165405.B26966@svana.org> Message-ID: <20020219075212.A31788@suse.de> On Tue, Feb 19, Martijn van Oosterhout wrote: > On Tue, Feb 19, 2002 at 12:09:51AM -0500, Andrew Pimlott wrote: > > On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote: > > I would lobby to change the spec not to mention bin, daemon, or any > > of the optional users/groups, at all. They are not specified in a > > useful way, so they're at best dead-weight, and at worst an > > opportunity for conflicting interpretations. > > IIRC, I think the reasoning went as follows: > - The LSB format is based on RPM which has a CPIO archive > - CPIO archives store uid/gids as numbers, not names > - Installed programs may want to use the daemon user > - Hence the daemon user must have a fixed uid Have you ever looked at RPM? I don't know which cpio format the RPM internal cpio is using, but the above is wrong, the demon user must not have a fixed uid. RPM does not depend on fixed uids. > Kind of funny that we would have to start changing the mappings of uids > just because some people decided to use RPM as a standard install format. Which is also wrong. This has nothing to do with the fact that LSB has decide to use the RPMv3 package format for delivering programs. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrenstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B From lawrencc@debian.org Tue Feb 19 07:09:10 2002 From: lawrencc@debian.org (Chris Lawrence) Date: Tue, 19 Feb 2002 01:09:10 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219075212.A31788@suse.de> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> <20020219165405.B26966@svana.org> <20020219075212.A31788@suse.de> Message-ID: <20020219070910.GA8034@bellsouth.net> On Feb 19, Thorsten Kukuk wrote: > On Tue, Feb 19, Martijn van Oosterhout wrote: > > > On Tue, Feb 19, 2002 at 12:09:51AM -0500, Andrew Pimlott wrote: > > > On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote: > > > I would lobby to change the spec not to mention bin, daemon, or any > > > of the optional users/groups, at all. They are not specified in a > > > useful way, so they're at best dead-weight, and at worst an > > > opportunity for conflicting interpretations. > > > > IIRC, I think the reasoning went as follows: > > - The LSB format is based on RPM which has a CPIO archive > > - CPIO archives store uid/gids as numbers, not names > > - Installed programs may want to use the daemon user > > - Hence the daemon user must have a fixed uid > > Have you ever looked at RPM? I don't know which cpio format the RPM > internal cpio is using, but the above is wrong, the demon user must > not have a fixed uid. RPM does not depend on fixed uids. Heh... this discussion was on lsb-discuss, what, 6 months ago. As far as I can figure out, there is no technical reason to require uid and gid 1 to be bin, and it's bad programming practice to assume any uid corresponds to any named user. When this last came up, I don't think anyone came up with a good reason not to drop the specification; indeed, I assumed it was gone until I went back and reread the section closely. Let's put it this way: making uid/gid 1 a requirement means Debian probably will never conform to the spec, because of the problem of breaking existing installs. It also creates problems for people who want to use NIS across multiple systems, as Solaris uses uid/gid 2 for bin (like Debian), or running LSB apps on Solaris/x86, which could be conformant if Sun or a third party wanted to do the work. Chris -- Chris Lawrence - http://www.lordsutch.com/chris/ From chewie@wookimus.net Tue Feb 19 07:37:32 2002 From: chewie@wookimus.net (Chad C. Walstrom) Date: Tue, 19 Feb 2002 01:37:32 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219070910.GA8034@bellsouth.net> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> <20020219165405.B26966@svana.org> <20020219075212.A31788@suse.de> <20020219070910.GA8034@bellsouth.net> Message-ID: <20020219073732.GD16523@wookimus.net> --tEFtbjk+mNEviIIX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2002 at 01:09:10AM -0600, Chris Lawrence wrote: > Let's put it this way: making uid/gid 1 a requirement means Debian > probably will never conform to the spec, because of the problem of > breaking existing installs. =20 Only apply the changes to new installs. Alternatively, create a configlet script for the Sysadmin to use while in single-user mode to change over things. We're not changing root here, just bin and daemon. I don't know any application that runs as daemon that still runs in single user mode. #!/bin/sh # # swap uid/gid btwn bin & daemon users/groups # # DISCLAIMER -- this is a hack intended for sysadmins willing to get # their hands dirty once and a while. # >/etc/nologin groupmod -gid 1 -o bin groupmod -gid 2 -o daemon usermod -uid 1 -gbin bin usermod -uid 2 -gdaemon daemon find / -uid 1 -gid 1 -exec chown 2:1 \{\} \; -print > /tmp/2:1.list find / -uid 2 -gid 2 -exec chown 1:1 \{\} \; # already found the files...chown them again to their final uid:gid cat /tmp/2:1.list | xargs chown 2:2 rm /tmp/2:1.list rm /etc/nologin If we have to, we could create/choose a high, random uid that isn't being used as the swap point. > It also creates problems for people who want to use NIS across > multiple systems, as Solaris uses uid/gid 2 for bin (like Debian), or > running LSB apps on Solaris/x86, which could be conformant if Sun or a > third party wanted to do the work. IMHO, you should not be sharing low uid/gid's over NIS, PERIOD, end of sentance. Your NIS uid/gid should be somewhere abovbe 1500 so that your system and operator accounts don't require full-time network connections to be accessible. How many times has your NFS server died or experienced lag, locking you out of your home directory? How many times have you been unable to login because some system profile script requires a file on an NFS automounted directory. How about NIS dying and no-one being able to login except root? It happens. All the time. Why? Badly configured systems, often inherited from one BOFH to another (It's not my fault! -- Han Solo). The fix? Manual labor, headaches, and lots of coffee. I know this from recent experience (geeze, every day, in fact). Should LSB be pushing us around over small, usually systems management related tasks? Probably not. Should the LSB be a good guideline on setting up a sane system to begin with? Certainly. Should we conform to LSB whenever possible. Absolutely. Does this mean we need to convert every running system over to accomedate a uid/gid change? No. The robust solution to such a switch would have to incorporate more tools than I listed above, such as 'ps' and 'fopen'. Perl or Python may be a nice, one-tool approach, and it sounds like the base Debian system should have at least Perl for the time being. Anyway, it's late, and I'm tired. Night! --=20 Chad Walstrom | a.k.a. ^chewie http://www.wookimus.net/ | s.k.a. gunnarr Get my public key, ICQ#, etc. $(mailx -s 'get info' chewie@wookimus.net) --tEFtbjk+mNEviIIX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8cgC8DMcLGCBsWv0RAt7QAKCA6UpPf97Osxdy4d8QaKJ5z0EdfACbB3Aw 4pxq4tbBXuhZqpzSSBEboWU= =XKXt -----END PGP SIGNATURE----- --tEFtbjk+mNEviIIX-- From alan@lxorguk.ukuu.org.uk Tue Feb 19 09:18:38 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 19 Feb 2002 09:18:38 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219165405.B26966@svana.org> from "Martijn van Oosterhout" at Feb 19, 2002 04:54:05 PM Message-ID: > IIRC, I think the reasoning went as follows: > - The LSB format is based on RPM which has a CPIO archive > - CPIO archives store uid/gids as numbers, not names RPM does not have that limitation > - Hence the daemon user must have a fixed uid RPM does not have that limitation either > Note that once the program is running, it can use getpwent(). We're talking Doesn't help you - the password file is not the first package installed on a typical distro > Ofcourse, I could be making this up... Probably From alan@lxorguk.ukuu.org.uk Tue Feb 19 09:25:22 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 19 Feb 2002 09:25:22 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219024238.GA7649@bellsouth.net> from "Chris Lawrence" at Feb 18, 2002 08:42:38 PM Message-ID: > Frankly, I can't see any reason why uid/gid 1 should be assumed to be > bin, especially since no other UIDs and GIDs are static (except 0, > which is embedded in the kernel design...). After all, that's why we > have getpwuid()... Agreed. The rest of the thread is junk but the basic initial question is a good one - why was bin forced to 1 ? From schilling@fokus.gmd.de Tue Feb 19 11:59:15 2002 From: schilling@fokus.gmd.de (Joerg Schilling) Date: Tue, 19 Feb 2002 12:59:15 +0100 (CET) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <200202191159.g1JBxFwW026893@burner.fokus.gmd.de> >From: Chris Lawrence >On Feb 19, Wichert Akkerman wrote: >> Previously Chris Lawrence wrote: >> > Will do. The uid/gid 1 issue is definitely an issue; Debian probably >> > can't make that change, and I suspect many other LSB implementations >> > would trip over it too if they have any POSIX already. >> >> We can just drop most of the standard accounts and become compatible >> by simply not having an optional account. Most of bin/daemon/sync/etc. >> aren't used anyway it seems. >Unfortunately, the following accounts are required (per >http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/usernames.html): >USER GROUP UID GID >root root 0 0 >bin bin 1 1 >daemon daemon X X >X = unspecified Daemon has always been 1 on all traditional UNIX versions including AT&T and *BSD. The real problem between AT&T and *BSD was that AT&T uses 2 for bin and 3 for sys while *BSD used 3 for bin and 2 for sys. Also note that on SunOS 3.x and 4.x "nonody"/"nogroup" have been 65534 \** while SunOS 5.x and SYSvr4 defines "nonody"/"nogroup" to be 60001 and in addition introduce "noaccess" with 60002. **) BSD seems to have copied over the old SunOS nobody mapping. NOTE: If you ever plan to share e.g. /usr via NFS in order to have e.g discless or dataless clients you need to aggree on a static map for all system relevant IDs. Also note: if you like to use a recent TAR standard format \** for data exchange there is a need to standardize nobody/nogroup for security reasons. If you don't standardize nobody/nogroup, you need at least forbid 65534 & 60001/60002 for regular users. Note that many people run file servers with a passwd file that does not hold uid information for the users on the NFS clients. It you make backups, there then is only numeric ID information. As you must take care people who use outdated TAR implementations (like the "pax" implementaion recommended by Mr. Kukuck from SuSE), keep in mind that those implementations do not support POSIX.1-2001 extended headers like "star" and thus will not understand them. They will only see the 7x3 bit values from the old TAR header. For this reason it is important that in case you are archiving ID values > 2097151 you need to use the value of "nobody" for the small number in the old TAR header. If you don't, you will end up to see the real ID modulo 2097151 which may be a real secority problem in case the files have TSUID or TSGID bit set in the permissions. OK, let me stop here and see if there is the right audience on this group before I probably waste my time while writing mail.... **) It seems that at least Mr. Kukuck from SuSE decided to use a "pax" implementation which only supports the 1990 POSIX standard, so there cannot be Large File support or support for UID/GID > 2097151 on LSB Linux. >On Debian: >USER GROUP UID GID >root root 0 0 >bin bin 2 2 >daemon daemon 1 1 This is funny and not somilar to any traditional UNIX system - why? Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From schilling@fokus.gmd.de Tue Feb 19 13:16:32 2002 From: schilling@fokus.gmd.de (Joerg Schilling) Date: Tue, 19 Feb 2002 14:16:32 +0100 (CET) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <200202191316.g1JDGWLw026966@burner.fokus.gmd.de> >From: Alan Cox >> IIRC, I think the reasoning went as follows: >> - The LSB format is based on RPM which has a CPIO archive >> - CPIO archives store uid/gids as numbers, not names >RPM does not have that limitation >> - Hence the daemon user must have a fixed uid >RPM does not have that limitation either >> Note that once the program is running, it can use getpwent(). We're talking >Doesn't help you - the password file is not the first package installed on >a typical distro So RPM _has_ that limitation.... Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From schilling@fokus.gmd.de Tue Feb 19 13:19:49 2002 From: schilling@fokus.gmd.de (Joerg Schilling) Date: Tue, 19 Feb 2002 14:19:49 +0100 (CET) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <200202191319.g1JDJnDQ026981@burner.fokus.gmd.de> >From: Alan Cox >> Frankly, I can't see any reason why uid/gid 1 should be assumed to be >> bin, especially since no other UIDs and GIDs are static (except 0, >> which is embedded in the kernel design...). After all, that's why we >> have getpwuid()... >Agreed. The rest of the thread is junk but the basic initial question is a >good one - why was bin forced to 1 ? In principle there is no reason to force a specifiv number. However there is a reason to force identical numbers to allow NFS mounting of /usr. If you decide on the numbers it would probably make sense to check the SYSvr4 passwd file because most commercial UNIX versions out use this mapping. root:x:0:1:Super-User:/:/sbin/sh daemon:x:1:1::/: bin:x:2:2::/usr/bin: sys:x:3:3::/: adm:x:4:4:Admin:/var/adm: lp:x:71:8:Line Printer Admin:/usr/spool/lp: uucp:x:5:5:uucp Admin:/usr/lib/uucp: nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico smmsp:x:25:25:SendMail Message Submission Program:/: listen:x:37:4:Network Admin:/usr/net/nls: nobody:x:60001:60001:Nobody:/: noaccess:x:60002:60002:No Access User:/: nobody4:x:65534:65534:SunOS 4.x Nobody:/: and for group: root::0:root other::1: bin::2:root,bin,daemon sys::3:root,bin,sys,adm adm::4:root,adm,daemon uucp::5:root,uucp mail::6:root tty::7:root,adm lp::8:root,lp,adm nuucp::9:root,nuucp staff::10: daemon::12:root,daemon sysadmin::14: smmsp::25:smmsp nobody::60001: noaccess::60002: nogroup::65534: Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From alan@lxorguk.ukuu.org.uk Tue Feb 19 14:19:20 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 19 Feb 2002 14:19:20 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <200202191319.g1JDJnDQ026981@burner.fokus.gmd.de> from "Joerg Schilling" at Feb 19, 2002 02:19:49 PM Message-ID: > >Agreed. The rest of the thread is junk but the basic initial question is a > >good one - why was bin forced to 1 ? > > In principle there is no reason to force a specifiv number. > However there is a reason to force identical numbers to allow NFS mounting of > /usr. No. Thats an argument for not forcing them in fact. If they are not dictated then you can pick an arbitary mapping and use that. Which means whatever legacy setup you have (providing it has no existing clashes) will work. Specifying entries just ensures you screw somebody From alan@lxorguk.ukuu.org.uk Tue Feb 19 14:19:58 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 19 Feb 2002 14:19:58 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <200202191316.g1JDGWLw026966@burner.fokus.gmd.de> from "Joerg Schilling" at Feb 19, 2002 02:16:32 PM Message-ID: > >> Note that once the program is running, it can use getpwent(). We're talking > > >Doesn't help you - the password file is not the first package installed on > >a typical distro > > So RPM _has_ that limitation.... With a postinstall trigger - no. From andrew@pimlott.ne.mediaone.net Tue Feb 19 14:47:53 2002 From: andrew@pimlott.ne.mediaone.net (Andrew Pimlott) Date: Tue, 19 Feb 2002 09:47:53 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219165405.B26966@svana.org> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> <20020219165405.B26966@svana.org> Message-ID: <20020219144753.GB31216@pimlott.ne.mediaone.net> On Tue, Feb 19, 2002 at 04:54:05PM +1100, Martijn van Oosterhout wrote: > - Installed programs may want to use the daemon user LSB programs? I don't see what justification they would have for doing so, since the daemon user is specified as "Subprocess special privileges", whatever that means. I think it would be much cleaner to specify that LSB programs should create their own users for daemon processes. (useradd is in LSB, and separate uids is better for security.) Similarly with bin: "Administrative user with some restrictions" doesn't tell me anything about how I, as a packager of an LSB program, would use it. Further, Debian has had user bin forever (probably for the same reason as the LSB: vague tradition), yet AFAICT has found absolutely no use for it. Why can't we end-around this whole issue by dropping these users from the LSB? This is the bug I filed: http://sourceforge.net/tracker/index.php?func=detail&aid=451195&group_id=1107&atid=101107 Andrew From wichert@wiggy.net Tue Feb 19 15:16:28 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Tue, 19 Feb 2002 16:16:28 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219144753.GB31216@pimlott.ne.mediaone.net> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> <20020219165405.B26966@svana.org> <20020219144753.GB31216@pimlott.ne.mediaone.net> Message-ID: <20020219151628.GX4806@wiggy.net> Previously Andrew Pimlott wrote: > Why can't we end-around this whole issue by dropping these users > from the LSB? Very much agreed. We shouldn't have a single user or group in the spec unless we have a very good reason (and example) for them. Vague descriptions and things like `tradition' don't count. Personally I'm not aware of a single use of the daemon, bin or sys accounts and wouldn't mind dropping them. The less users we have the better. (accounts that is, you know what I mean :) Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From schilling@fokus.gmd.de Tue Feb 19 15:30:47 2002 From: schilling@fokus.gmd.de (Joerg Schilling) Date: Tue, 19 Feb 2002 16:30:47 +0100 (CET) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <200202191530.g1JFUlBJ027178@burner.fokus.gmd.de> >From alan@lxorguk.ukuu.org.uk Tue Feb 19 15:05:04 2002 >> >Agreed. The rest of the thread is junk but the basic initial question is a >> >good one - why was bin forced to 1 ? >> >> In principle there is no reason to force a specifiv number. >> However there is a reason to force identical numbers to allow NFS mounting of >> /usr. >No. Thats an argument for not forcing them in fact. If they are not dictated >then you can pick an arbitary mapping and use that. Which means whatever >legacy setup you have (providing it has no existing clashes) will work. If you cannot rely on hardcoded numbers, then it will not work to NFS mount /usr bewteen different distributions. This looks much like you are not taking LSB for serious. Note that neither NFS v1, nor V2 or v3 do contain any precautions to map user ids. Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From wichert@wiggy.net Tue Feb 19 15:38:38 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Tue, 19 Feb 2002 16:38:38 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <200202191530.g1JFUlBJ027178@burner.fokus.gmd.de> References: <200202191530.g1JFUlBJ027178@burner.fokus.gmd.de> Message-ID: <20020219153838.GC4806@wiggy.net> Previously Joerg Schilling wrote: > If you cannot rely on hardcoded numbers, then it will not work to NFS > mount /usr bewteen different distributions. You already can not, as was demonstrated not all Linux distributions use the same uid/gid for these users. Question is: why should you rely on having these users provided by the LSB? They don't serve any purpose (at least not within LSB). If people need them in their environment there is nothing to stop them from (re)creating them with a consistent uid/gid that is consistent throughout their environment. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From alan@lxorguk.ukuu.org.uk Tue Feb 19 16:12:35 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 19 Feb 2002 16:12:35 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <200202191530.g1JFUlBJ027178@burner.fokus.gmd.de> from "Joerg Schilling" at Feb 19, 2002 04:30:47 PM Message-ID: > >No. Thats an argument for not forcing them in fact. If they are not dictated > >then you can pick an arbitary mapping and use that. Which means whatever > >legacy setup you have (providing it has no existing clashes) will work. > > If you cannot rely on hardcoded numbers, then it will not work to NFS mount /usr > bewteen different distributions. You can fix the numbers on any system to match what you want. Thats what not defining numbers means. "I've got 8 legacy sun boxes so I'll use their system uid layout" > Note that neither NFS v1, nor V2 or v3 do contain any precautions to map user > ids. They don't disallow it either. See uuid in the unfsd package From vorlon@netexpress.net Tue Feb 19 17:44:55 2002 From: vorlon@netexpress.net (Steve Langasek) Date: Tue, 19 Feb 2002 11:44:55 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: References: <20020219165405.B26966@svana.org> Message-ID: <20020219174450.GB22260@netexpress.net> --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2002 at 09:18:38AM +0000, Alan Cox wrote: > > Note that once the program is running, it can use getpwent(). We're tal= king > Doesn't help you - the password file is not the first package installed on > a typical distro So the goal of this provision is to allow LSB packages to make use of=20 certain non-root facilities before the system has a password file? I'd think the easy way to avoid that nonsense is to specify that an=20 LSB-compliant system gives meaningful results when calling getpwnam()=20 for certain required usernames (whether it uses /etc/passwd, NIS, LDAP,=20 whatever). That one issue doesn't justify hard-coding of=20 arbitrarily-chosen uids for system users. In Debian, our /etc/passwd is provided by base-passwd, which is an=20 "Essential: yes" package of required priority that's part of the base=20 section of the archive. Anyone trying to install an LSB package on=20 Debian before the *installer* has even been allowed to run is engaged in=20 foot-shooting of Olympic proportions. While I don't know whether Debian would be considered a 'typical'=20 distro, I would expect that other common distros are similarly=20 unaffected by this concern. Steve Langasek postmodern programmer --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8co8SKN6ufymYLloRAlKpAJ4uug2mH1iBalCNNAX6GyXepetQAACdGi89 /xFqP0XugrJDg2EEJ9GFz6o= =jB0i -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From alan@lxorguk.ukuu.org.uk Wed Feb 20 02:08:19 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Wed, 20 Feb 2002 02:08:19 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219174450.GB22260@netexpress.net> from "Steve Langasek" at Feb 19, 2002 11:44:55 AM Message-ID: > > Doesn't help you - the password file is not the first package installed on > > a typical distro > > So the goal of this provision is to allow LSB packages to make use of=20 > certain non-root facilities before the system has a password file? Its not needed for that either. Nothing in an RPM based system that I know of requires bin is uid 1 From cyeoh@samba.org Wed Feb 20 02:53:20 2002 From: cyeoh@samba.org (Christopher Yeoh) Date: Wed, 20 Feb 2002 13:53:20 +1100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: References: <20020219174450.GB22260@netexpress.net> Message-ID: <15475.4000.229353.942995@gargle.gargle.HOWL> At 2002/2/20 02:08+0000 Alan Cox writes: > > > Doesn't help you - the password file is not the first package installed on > > > a typical distro > > > > So the goal of this provision is to allow LSB packages to make use of=20 > > certain non-root facilities before the system has a password file? > > Its not needed for that either. Nothing in an RPM based system that I know > of requires bin is uid 1 So does anyone out there have any objections to removing the requirement that the uid and gid of the bin user be 1? If no one comes up with a good reason in the next week I'll just remove it. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From wichert@wiggy.net Wed Feb 20 09:05:25 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Wed, 20 Feb 2002 10:05:25 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <15475.4000.229353.942995@gargle.gargle.HOWL> References: <20020219174450.GB22260@netexpress.net> <15475.4000.229353.942995@gargle.gargle.HOWL> Message-ID: <20020220090525.GU4806@wiggy.net> Previously Christopher Yeoh wrote: > So does anyone out there have any objections to removing the > requirement that the uid and gid of the bin user be 1? If no one > comes up with a good reason in the next week I'll just remove it. Why keep the bin user at all? I haven't seen a rationale for its existence yet. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From anderson@metrolink.com Wed Feb 20 14:27:14 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 09:27:14 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <15475.4000.229353.942995@gargle.gargle.HOWL> Message-ID: <20020220092211.F429-100000@trantor.sc.metrolink.com> On Wed, 20 Feb 2002, Christopher Yeoh wrote: > So does anyone out there have any objections to removing the > requirement that the uid and gid of the bin user be 1? We put it in there for a reason, and so far, I don't think anyone has correctly recalled the reason. Unfortunately, it was done so long ago that I don't remember all of the details either. I think part of the reason for having added this was that this was an area where divergence was beginning to occur, and those participating at the time felt that we should specify the common practice to prevent further divergence. Before we make a change here, some one should look through the archive, and try to summarize the discussions that let to it being added in the first place. > If no one > comes up with a good reason in the next week I'll just remove it. Unfortunately, we can't just remove it. It has been published as part of the standard. What we can do, however, is to mark that portion as "deprecated" and remove it in a future release. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From aj@azure.humbug.org.au Wed Feb 20 14:57:07 2002 From: aj@azure.humbug.org.au (Anthony Towns) Date: Thu, 21 Feb 2002 00:57:07 +1000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220092211.F429-100000@trantor.sc.metrolink.com> References: <15475.4000.229353.942995@gargle.gargle.HOWL> <20020220092211.F429-100000@trantor.sc.metrolink.com> Message-ID: <20020220145707.GA25873@azure.humbug.org.au> --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 09:27:14AM -0500, Stuart Anderson wrote: > We put it in there for a reason, and so far, I don't think anyone has > correctly recalled the reason. Unfortunately, it was done so long ago that > I don't remember all of the details either. You know, if no one can think of the reason in the months since this was first brought up in response to the "1.0" spec release, it quite simply can't have been a remotely good one. It's already evident that absolutely *none* of the stake holders in the LSB have any particular interest in keeping it, and a number of important stakeholders (Debian, you know, the second or third most popular Linux distribution worldwide, and everyone who wants their LSB compliant packages to run on Debian; not to mention Solaris ("Sun's implementation of Linux", if you'll recall)) have a strong desire to have it removed. > I think part of the reason for having added this was that this was an area > where divergence was beginning to occur, and those participating at the t= ime > felt that we should specify the common practice to prevent further diverg= ence. Preventing divergence is not the LSB's charter. The LSB's charter is to specify a set of APIs that will allow useful third party software to run across a wide variety of systems. Specifying the uid of the bin user does not make it easier to write software for Linux systems, and it limits the number of systems on which LSB-compliant software can run. > Unfortunately, we can't just remove it. It has been published as part > of the standard. What we can do, however, is to mark that portion as > "deprecated" and remove it in a future release. The standard is recognised to be buggy and there is no existing userbase. What better time do you think there'll be to remove it? Of course, I suppose you could argue that if the standard is kept buggy, there probably won't ever be a userbase. Do you really want to? Enough with going around in circles about pointless nonsense. There are a handful of simple changes that are needed right now for the LSB to achieve its goals. It's time to make them. Who has commit access to version 1.2 of the spec? Cheers, aj --=20 Anthony Towns We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each=20 toe individually.'' -- with kudos to Greg Lehey --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHO5QuRRvX9xctrtAQEwhgP9HPtSFZrk/bfhQai/BkpT6qruhktt8/dj T3FT1gic3c9z204etsShXUlGtimjd0IMwUAVmTccP+TYH4uP1akHklbVjVDnmPtG +07CV5x6pc5icdrkbuw9HFwe7bK+gsnoIvy71ruXQFoz5q7Yr8ps+OntKH3WNlra 8mp2dCpNqOM= =wTk7 -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From wichert@wiggy.net Wed Feb 20 14:58:34 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Wed, 20 Feb 2002 15:58:34 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220092211.F429-100000@trantor.sc.metrolink.com> References: <15475.4000.229353.942995@gargle.gargle.HOWL> <20020220092211.F429-100000@trantor.sc.metrolink.com> Message-ID: <20020220145834.GE4806@wiggy.net> Previously Stuart Anderson wrote: > I think part of the reason for having added this was that this was an area > where divergence was beginning to occur, and those participating at the time > felt that we should specify the common practice to prevent further divergence. I don't think divergence is a good reason for putting them into LSB: if we don't spec those users at all it doesn't matter if they diverge since people can't use them without violating the LSB, but more interestingly it will also allow us to remove them completely. > Unfortunately, we can't just remove it. It has been published as part > of the standard. What we can do, however, is to mark that portion as > "deprecated" and remove it in a future release. What I plan to do for Debian is not install those users on new installs but keep them around on existing systems. This will be done after the woody release though so it won't affect anyone for the current forseeable future. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From David.VomLehn@compaq.com Wed Feb 20 15:11:14 2002 From: David.VomLehn@compaq.com (VomLehn, David) Date: Wed, 20 Feb 2002 09:11:14 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <717252EC3E37AE4392E2614EA24E9F2B1ECD7C@txnexc01.americas.cpqcorp.net> I would urge some caution here. If I were to guess at a reason as to why bin has uid/gid of 1, I would suspect that some application installations use 1 as the bin uid/gid instead of looking it up. This may not be good practices, but the LSB work is primarily focused on codifying current practices, good or not. Before this is deprecated, it would probably help to look in distributions of various application packages and/or ask the creators/maintainers of those packages to check for an assumption that bin will have uid/gid equal to 1. And, since we all make mistakes, I'd suggest changing the bin uid/gid on a system in a distribution or two, install the most commonly used applications, and see if they execute properly. -----Original Message----- From: Wichert Akkerman [mailto:wichert@wiggy.net] Sent: Wednesday, February 20, 2002 8:59 AM To: debian-devel@lists.debian.org; lsb-spec@lists.linuxbase.org Subject: Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Previously Stuart Anderson wrote: > I think part of the reason for having added this was that this was an area > where divergence was beginning to occur, and those participating at the time > felt that we should specify the common practice to prevent further divergence. I don't think divergence is a good reason for putting them into LSB: if we don't spec those users at all it doesn't matter if they diverge since people can't use them without violating the LSB, but more interestingly it will also allow us to remove them completely. > Unfortunately, we can't just remove it. It has been published as part > of the standard. What we can do, however, is to mark that portion as > "deprecated" and remove it in a future release. What I plan to do for Debian is not install those users on new installs but keep them around on existing systems. This will be done after the woody release though so it won't affect anyone for the current forseeable future. Wichert. --=20 _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | --=20 To UNSUBSCRIBE, email to lsb-spec-request@lists.linuxbase.org with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org From anderson@metrolink.com Wed Feb 20 15:15:03 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 10:15:03 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220145707.GA25873@azure.humbug.org.au> Message-ID: <20020220100625.G429-100000@trantor.sc.metrolink.com> On Thu, 21 Feb 2002, Anthony Towns wrote: > You know, if no one can think of the reason in the months since this > was first brought up in response to the "1.0" spec release, it quite > simply can't have been a remotely good one. The words in question were written well over a year ago, which is why it is hard to recall the details. > It's already evident that > absolutely *none* of the stake holders in the LSB have any particular > interest in keeping it, and a number of important stakeholders (Debian, > you know, the second or third most popular Linux distribution worldwide, Yes, I am quite familiar with Debian as I use it in several places. > and everyone who wants their LSB compliant packages to run on Debian; not > to mention Solaris ("Sun's implementation of Linux", if you'll recall)) > have a strong desire to have it removed. I don't mind removing it, but I do mind making random, uncontrolled changes to a document that is supposed to be stable and "controlled". My point in this is that we need to follow a proper process in making changes like this. > Preventing divergence is not the LSB's charter. Actually, it is one of the original problems that cuased the LSB to be formed nearly 4 years ago. > The LSB's charter is > to specify a set of APIs that will allow useful third party software > to run across a wide variety of systems. Developing the ABI for Linux was seen as the best route to accomplishing the job. Adding a few things beyond the strict limits of the ABI was also seen as a good thing. > Specifying the uid of the bin > user does not make it easier to write software for Linux systems, and > it limits the number of systems on which LSB-compliant software can run. As I said above, I don't mind removing the uids, I just want to make sure that proper diligence is used when doing so. > The standard is recognised to be buggy and there is no existing userbase. > What better time do you think there'll be to remove it? I'm not resisting the removal of it, just that a proper process be followed. This avoids having to ask the questions "how large does the user base have to be before we can't fix something". > Of course, I suppose you could argue that if the standard is kept buggy, > there probably won't ever be a userbase. Do you really want to? I have never suggested keeping it buggy. > Enough with going around in circles about pointless nonsense. There are > a handful of simple changes that are needed right now for the LSB to > achieve its goals. It's time to make them. > > Who has commit access to version 1.2 of the spec? Myself and a few others, but I have been tasked with ensuring that changes are made in a consistant manner. That's all I am trying to do. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From anderson@metrolink.com Wed Feb 20 15:17:06 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 10:17:06 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220145834.GE4806@wiggy.net> Message-ID: <20020220101538.B429-100000@trantor.sc.metrolink.com> On Wed, 20 Feb 2002, Wichert Akkerman wrote: > I don't think divergence is a good reason for putting them into LSB: > if we don't spec those users at all it doesn't matter if they diverge > since people can't use them without violating the LSB, but more > interestingly it will also allow us to remove them completely. There was some original problem that was caused by the fact they were different on different distributions. I would just like to be able to recall what that problem was, and then we can decide if it still needs fixing or not. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From aj@azure.humbug.org.au Wed Feb 20 15:18:19 2002 From: aj@azure.humbug.org.au (Anthony Towns) Date: Thu, 21 Feb 2002 01:18:19 +1000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <717252EC3E37AE4392E2614EA24E9F2B1ECD7C@txnexc01.americas.cpqcorp.net> References: <717252EC3E37AE4392E2614EA24E9F2B1ECD7C@txnexc01.americas.cpqcorp.net> Message-ID: <20020220151819.GA27175@azure.humbug.org.au> --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 09:11:14AM -0600, VomLehn, David wrote: > I would urge some caution here. If I were to guess at a reason as to why > bin has uid/gid of 1, I would suspect that some application > installations use 1 as the bin uid/gid instead of looking it up. This > may not be good practices, but the LSB work is primarily focused on > codifying current practices, good or not. No, it's not. The LSB is focussed on codifying practices that can be used to install third party software on any distribution of Linux. Assuming the uid of the bin user is 1, is not one of those practices, and it should never have been codified. This change will not make any distribution non-conformant, and since there are absolutely no LSB compliant apps at present, won't break any of them, either. Cheers, aj --=20 Anthony Towns We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each=20 toe individually.'' -- with kudos to Greg Lehey --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHO+OuRRvX9xctrtAQF7rwQAnVhlVBqvF8nBJpIR0O8/3qnm5PumU+Jv ZjhM0SQ24/9LteLowm8rIndenAZzcYWIsAnnYBgwrCQMzamGS/uZNbqpgJcElTVu +HT8YYmB8DZJD1aHjkmbQLwW/7k1pzF43JMBX09UQjTU96DYdQIVT+m3A7fheiaa CmVrntNN6II= =G/KT -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From wichert@wiggy.net Wed Feb 20 15:18:59 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Wed, 20 Feb 2002 16:18:59 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <717252EC3E37AE4392E2614EA24E9F2B1ECD7C@txnexc01.americas.cpqcorp.net> References: <717252EC3E37AE4392E2614EA24E9F2B1ECD7C@txnexc01.americas.cpqcorp.net> Message-ID: <20020220151859.GH4806@wiggy.net> Previously VomLehn, David wrote: > I would urge some caution here. If I were to guess at a reason as to why > bin has uid/gid of 1, I would suspect that some application > installations use 1 as the bin uid/gid instead of looking it up. But this already isn't portable since the uid of bin is not consistent between Linux distributions. > This may not be good practices, but the LSB work is primarily focused > on codifying current practices, good or not. codifying a current broken practice is broken. Also notice that the description if bin and daemon in the LSB are vague at best which suggests that there really is nobody who has any good reason for having those accounts around. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From David.VomLehn@compaq.com Wed Feb 20 15:34:55 2002 From: David.VomLehn@compaq.com (VomLehn, David) Date: Wed, 20 Feb 2002 09:34:55 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <717252EC3E37AE4392E2614EA24E9F2B1ECD7D@txnexc01.americas.cpqcorp.net> Yes, assuming the bin uid/gid are 1 isn't good practice as it is not consistent between Linux distributions. That's not the issue and Debian is not going to comply with LSB 1.0, ever. But note that I am saying nothing about complying with any other version of the LSB. The most difficult question that a standards body codifying existing practice deals with is trying to not break existing software. Since most software should be using good practices and hence using getpwent(), most existing software will work with Debian. When we deprecate a specific item in the LSB, we are giving software providers notice that their software needs to be changed to comply with LSB 1.x, 2.x, etc. When the specification requirement that bin's uid/gid be 1 is obsoleted, software providers will have been given ample time (1-2 yrs.?) to update their software. At that time, Debian, with no changes, will become compliant with the version of the LSB in which the requirement that bin's uid/gid be 1 is dropped. If I were Debian, I would be frustrated at the length of time it takes to obsolete a feature. It's an unfortunate reality that software producers need to have time to change their products, but it is also an unavoidable reality. Lastly, I offer the observation that if it were easy to create and update a Linux interface standard, it would have been done a long time ago. -----Original Message----- From: Wichert Akkerman [mailto:wichert@wiggy.net] Sent: Wednesday, February 20, 2002 9:19 AM To: VomLehn, David Cc: debian-devel@lists.debian.org; lsb-spec@lists.linuxbase.org Subject: Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Previously VomLehn, David wrote: > I would urge some caution here. If I were to guess at a reason as to why > bin has uid/gid of 1, I would suspect that some application > installations use 1 as the bin uid/gid instead of looking it up. But this already isn't portable since the uid of bin is not consistent between Linux distributions. > This may not be good practices, but the LSB work is primarily focused > on codifying current practices, good or not. codifying a current broken practice is broken. Also notice that the description if bin and daemon in the LSB are vague at best which suggests that there really is nobody who has any good reason for having those accounts around. Wichert. --=20 _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From joy@cibalia.gkvk.hr Wed Feb 20 15:47:32 2002 From: joy@cibalia.gkvk.hr (Josip Rodin) Date: Wed, 20 Feb 2002 16:47:32 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220100625.G429-100000@trantor.sc.metrolink.com> References: <20020220145707.GA25873@azure.humbug.org.au> <20020220100625.G429-100000@trantor.sc.metrolink.com> Message-ID: <20020220154732.GE16663@cibalia.gkvk.hr> On Wed, Feb 20, 2002 at 10:15:03AM -0500, Stuart Anderson wrote: > > Preventing divergence is not the LSB's charter. > > Actually, it is one of the original problems that cuased the LSB to be formed > nearly 4 years ago. I think he meant "preventing divergence that doesn't need prevention is no the charter of LSB". > I'm not resisting the removal of it, just that a proper process be followed. > I have been tasked with ensuring that changes are made in a consistant > manner. That's all I am trying to do. Okay, so let's summarize. This rule breaks things as it is. If we change it, other things might break. However, nobody can think of what these other things are. The choice seems pretty clear, now let's start the procedure of changing. :) -- 2. That which causes joy or happiness. From wichert@wiggy.net Wed Feb 20 15:55:59 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Wed, 20 Feb 2002 16:55:59 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <717252EC3E37AE4392E2614EA24E9F2B1ECD7D@txnexc01.americas.cpqcorp.net> References: <717252EC3E37AE4392E2614EA24E9F2B1ECD7D@txnexc01.americas.cpqcorp.net> Message-ID: <20020220155559.GI4806@wiggy.net> Previously VomLehn, David wrote: > That's not the issue and Debian is not going to comply with LSB 1.0, > ever. >From what I see no distribution will be LSB 1.0 complient but will start with 1.1 instead. But that isn't really relevant here. > The most difficult question that a standards body codifying existing > practice deals with is trying to not break existing software. Mostly agreed. > If I were Debian, I would be frustrated at the length of time it takes > to obsolete a feature. That isn't frustrating. Debian has always been in the business of providing seemless upgrades and we've been dealing with numerous multi-year transitions forever so we know how that works. The frustrating bit is that apparently these users were added to the LSB without a clear rationale and we need to clean up the resulting mess now. > It's an unfortunate reality that software producers need to have time > to change their products, but it is also an unavoidable reality. Can we try and investigate if there is a product out there that actually uses these two users? I would be very surprised of one exists. > Lastly, I offer the observation that if it were easy to create and > update a Linux interface standard, it would have been done a long time > ago. That isn't going to stop anyone from complaining though :) Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From anderson@metrolink.com Wed Feb 20 15:57:49 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 10:57:49 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220154732.GE16663@cibalia.gkvk.hr> Message-ID: <20020220105408.I429-100000@trantor.sc.metrolink.com> On Wed, 20 Feb 2002, Josip Rodin wrote: > I think he meant "preventing divergence that doesn't need prevention is no > the charter of LSB". I can agree with that. At the time (over a year ago), those participating in the LSB work felt that is was needed, so it got added. I agree, that it probably isn't needed, and just want to back it out in an appropriate manner. > Okay, so let's summarize. This rule breaks things as it is. If we change it, > other things might break. However, nobody can think of what these other > things are. The choice seems pretty clear, now let's start the procedure of > changing. :) OK 8-). I do feel that part of the proceedure is to understand why it was added in the first place. The only thing worse than having it in there, would be to remove it, and then discover the hard way why it had been put in there to begin with. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From David.VomLehn@compaq.com Wed Feb 20 16:05:34 2002 From: David.VomLehn@compaq.com (VomLehn, David) Date: Wed, 20 Feb 2002 10:05:34 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <717252EC3E37AE4392E2614EA24E9F2B1ECD7E@txnexc01.americas.cpqcorp.net> This is a multi-part message in MIME format. ------_=_NextPart_001_01C1BA28.6D7F2801 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable See below. -----Original Message----- From: Anthony Towns [ mailto:aj@azure.humbug.org.au] Sent: Wednesday, February 20, 2002 9:18 AM To: debian-devel@lists.debian.org; lsb-spec@lists.linuxbase.org Subject: Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package On Wed, Feb 20, 2002 at 09:11:14AM -0600, VomLehn, David wrote: > I would urge some caution here. If I were to guess at a reason as to why > bin has uid/gid of 1, I would suspect that some application > installations use 1 as the bin uid/gid instead of looking it up. This > may not be good practices, but the LSB work is primarily focused on > codifying current practices, good or not. No, it's not. The LSB is focussed on codifying practices that can be used to install third party software on any distribution of Linux. Assuming the uid of the bin user is 1, is not one of those practices, and it should never have been codified. Yes, and I think it's likely we made a mistake. It's now too late to change that for versions 1.0 and 1.1 of the LSB specification and I suggest that we simply understand the current state of affairs, accept it, and implement a reasonable process to fix the mistake. Doing so will take at least a year after the fix process begins to allow any application providers to make the required change. =20 The fix for this follows a well-beaten path--we are not the first standardization body to make a mistake. Assuming there is nobody who can find any reason for the current state of affairs, the very next release of the LSB includes, 1) a statement that the requirement that uid and gid be one is deprecated and will become obsolete in a future release, 2) specify that the plan is to obsolete this requirement in the first approved version of the LSB specification after a particular date, and 3) deliver on item 2. This change will not make any distribution non-conformant, and since there are absolutely no LSB compliant apps at present, won't break any of them, either. Yes, and it's great when we can move forward without breaking anything. The fact that there are no LSB compliant applications at present does not mean that there are no applications which completely meet the LSB specification. When a proper validation procedure exists for formally declaring an application compliant with LSB 1.1, the ones which assume that the uid and gid of bin are one will also be compliant. Since I expect the LSB effort to continue into the future, I also expect that some LSB 1.1 compliant applications will not be LSB compliant to a future version of the specification. I think I've made my position clear, so I have nothing further to discuss on this issue in LSB mailing lists. If anyone else wishes to engage me in further dialog, please send email directly to me. If there is a reason to view things differently, I'll publicize it myself. ------_=_NextPart_001_01C1BA28.6D7F2801 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    See below.

    -----Original=20 Message-----
    From: Anthony Towns [mailto:aj@azure.humbug.org.au]=
    Sent:=20 Wednesday, February 20, 2002 9:18 AM
    To: = debian-devel@lists.debian.org;=20 lsb-spec@lists.linuxbase.org
    Subject: Re: Bug#134658: ITP: lsb -- = Linux=20 Standard Base 1.1 core
    support package


    On Wed, Feb 20, = 2002 at=20 09:11:14AM -0600, VomLehn, David wrote:
    > I would urge some = caution here.=20 If I were to guess at a reason as to why
    > bin has uid/gid of 1, I = would=20 suspect that some application
    > installations use 1 as the bin = uid/gid=20 instead of looking it up. This
    > may not be good practices, but = the LSB=20 work is primarily focused on
    > codifying current practices, good = or=20 not.

    No, it's not. The LSB is focussed on codifying practices = that can be=20 used
    to install third party software on any distribution of Linux.=20 Assuming
    the uid of the bin user is 1, is not one of those practices, = and=20 it
    should never have been codified.

    Yes, and I think it's = likely we=20 made a mistake. It's now too late to change that for versions 1.0 and = 1.1 of=20 the LSB specification and I suggest that we simply understand the = current=20 state of affairs, accept it, and implement a reasonable process to fix = the=20 mistake. Doing so will take at least a year after the fix process = begins to=20 allow any application providers to make the required = change.
     
    The fix for this = follows a=20 well-beaten path--we are not the first standardization body to make a = mistake.=20 Assuming there is nobody who can find any reason for the current state = of=20 affairs, the very next release of the LSB includes, 1) a statement = that the=20 requirement that uid and gid be one is deprecated and will become = obsolete in=20 a future release, 2) specify that the plan is to obsolete this = requirement in=20 the first approved version of the LSB specification after a particular = date,=20 and 3) deliver on item 2.

    This change will not make any = distribution=20 non-conformant, and since
    there are absolutely no LSB compliant apps = at=20 present, won't break any
    of them, either.

    Yes, and=20 it's great when we can move forward without breaking anything. The = fact that=20 there are no LSB compliant applications at present does not mean that = there=20 are no applications which completely meet the LSB specification. When = a proper=20 validation procedure exists for formally declaring an application = compliant=20 with LSB 1.1, the ones which assume that the uid and gid of bin are = one will=20 also be compliant. Since I expect the LSB effort to continue into the = future,=20 I also expect that some LSB 1.1 compliant applications will not be LSB = compliant to a future version of the specification.

    I think=20 I've made my position clear, so I have nothing further to discuss on = this=20 issue in LSB mailing lists. If anyone else wishes to engage me in = further=20 dialog, please send email directly to me. If there is a reason to view = things=20 differently, I'll publicize it=20 myself.

     ------_=_NextPart_001_01C1BA28.6D7F2801-- From mats.d.wichmann@intel.com Wed Feb 20 16:13:13 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Wed, 20 Feb 2002 08:13:13 -0800 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA29.7F421FF0 Content-Type: text/plain; charset="iso-8859-1" Note that the LSB is presently engaged in a process (building the certification program) which includes an obsolescence plan as a deliverable. Yes, and I think it's likely we made a mistake. It's now too late to change that for versions 1.0 and 1.1 of the LSB specification and I suggest that we simply understand the current state of affairs, accept it, and implement a reasonable process to fix the mistake. Doing so will take at least a year after the fix process begins to allow any application providers to make the required change. The fix for this follows a well-beaten path--we are not the first standardization body to make a mistake. Assuming there is nobody who can find any reason for the current state of affairs, the very next release of the LSB includes, 1) a statement that the requirement that uid and gid be one is deprecated and will become obsolete in a future release, 2) specify that the plan is to obsolete this requirement in the first approved version of the LSB specification after a particular date, and 3) deliver on item 2. ------_=_NextPart_001_01C1BA29.7F421FF0 Content-Type: text/html; charset="iso-8859-1"
    Note that the LSB is presently engaged in a process (building the
    certification program) which includes an obsolescence plan as
    a deliverable.
    Yes, and I think it's likely we made a mistake. It's now too late to change that for versions 1.0 and 1.1 of the LSB specification and I suggest that we simply understand the current state of affairs, accept it, and implement a reasonable process to fix the mistake. Doing so will take at least a year after the fix process begins to allow any application providers to make the required change.
     
    The fix for this follows a well-beaten path--we are not the first standardization body to make a mistake. Assuming there is nobody who can find any reason for the current state of affairs, the very next release of the LSB includes, 1) a statement that the requirement that uid and gid be one is deprecated and will become obsolete in a future release, 2) specify that the plan is to obsolete this requirement in the first approved version of the LSB specification after a particular date, and 3) deliver on item 2.  
     
    ------_=_NextPart_001_01C1BA29.7F421FF0-- From aj@azure.humbug.org.au Wed Feb 20 16:17:39 2002 From: aj@azure.humbug.org.au (Anthony Towns) Date: Thu, 21 Feb 2002 02:17:39 +1000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220100625.G429-100000@trantor.sc.metrolink.com> References: <20020220145707.GA25873@azure.humbug.org.au> <20020220100625.G429-100000@trantor.sc.metrolink.com> Message-ID: <20020220161739.GB27175@azure.humbug.org.au> --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 10:15:03AM -0500, Stuart Anderson wrote: > On Thu, 21 Feb 2002, Anthony Towns wrote: > > You know, if no one can think of the reason in the months since this > > was first brought up in response to the "1.0" spec release, it quite > > simply can't have been a remotely good one. > The words in question were written well over a year ago, which is why it > is hard to recall the details. Well, it's over half a year since this was first brought up as a problem (4 July 2001, http://lists.debian.org/lsb-spec/2001/lsb-spec-200107/msg00002.html at the very least). > I don't mind removing it, but I do mind making random, uncontrolled chang= es > to a document that is supposed to be stable and "controlled". My point in= this > is that we need to follow a proper process in making changes like this. Well, it'd have been nice if that had happened in the first place, with, say, some reasonable opportunity to comment on things like this *before* they were specified. But since that didn't happen, the LSB simply has to fix it now, however galling that may be. > > Specifying the uid of the bin > > user does not make it easier to write software for Linux systems, and > > it limits the number of systems on which LSB-compliant software can run. > As I said above, I don't mind removing the uids, I just want to make sure= that > proper diligence is used when doing so. What, exactly, is "proper diligence" ? It would seem to me that due diligence would involve contacting key distribution vendors (Red Hat, Debian, Mandrake, SuSE) and ensuring there are no issues with a change. This clearly was *not* done before the bin uid was added to the 1.0 spec (the change wasn't even mentioned on the list before the 1.0 spec was released); and it clearly *has* been done now (there are developers from all of those distributions on the LSB specs, and developers from at least two of them have commented in favour of the change). By contrast, where was the due diligence in response to 496591 ("LSB packages should be named ".lsb")? The only response I've seen to that (and since I raised the issue, I'd assume I'd see what response there is), was the thread beginning at: http://lists.debian.org/lsb-discuss/2001/lsb-discuss-200112/msg00035.html and a "discussed and rejected" response to the sourceforge bug report, and in one of the conference call minutes. If you look back through the thread, you'll see absolutely no consensus or meeting of minds was achieved. There are a host of other issues that I and others have raised which have been dealt with in a similarly haphazard way (hardcoding Red Hat's interpretation of runlevels into the init script spec, the useless "local mounts" and "remote mount" system services, to name a couple of examples). These aren't things that kill the spec (unlike a number of the details in the user/group spec), but they are detrimental. The LSB group is doing a fine job of ignoring them all out of existance, though. > > The standard is recognised to be buggy and there is no existing userbas= e. > > What better time do you think there'll be to remove it? > I'm not resisting the removal of it, just that a proper process be follow= ed. So forgive me if these words ring completely hollow. [0] > > Enough with going around in circles about pointless nonsense. There are > > a handful of simple changes that are needed right now for the LSB to > > achieve its goals. It's time to make them. > > Who has commit access to version 1.2 of the spec? > Myself and a few others, but I have been tasked with ensuring that change= s are > made in a consistant manner. That's all I am trying to do. Well, I'm not sure I can dispute the consistency of the change policy ("Oh, it's from Debian, eh? Ignore it."), but ensuring necessary or useful changes are made quickly and correctly seems like a much more worthy goal. It's not really fun watching a project that seems like it could be fairly important to the Linux community falling into all the usual traps of non-bazaar development [0]. Cheers, aj [0] Process over functionality. Unresponsiveness to comments. Closed channels of communication between the core developers instead of regular use of mailing lists. Worrying more about releasing at LinuxWorld than getting something useful, or at least, not actively harmful, out. --=20 Anthony Towns We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each=20 toe individually.'' -- with kudos to Greg Lehey --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHPMIuRRvX9xctrtAQFyegP+Ni71fIaqhw47jMjEEej+SCzokK8bBl+Y +PYvnsKYlWD773SQ5bmHzMm3STzaM2UZwQ7dTJKmTGk6T7odw6e+Wo22pvp0c5Ou v20dWoWiWGHellNpfUwF+tI53EWargInyphhaXcwSPAZGLQoslYTixBGOGoM67eS 5JNgIcg3aV8= =Ruer -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From aj@azure.humbug.org.au Wed Feb 20 16:26:29 2002 From: aj@azure.humbug.org.au (Anthony Towns) Date: Thu, 21 Feb 2002 02:26:29 +1000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> References: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> Message-ID: <20020220162629.GC27175@azure.humbug.org.au> --hOcCNbCCxyk/YU74 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 08:13:13AM -0800, Wichmann, Mats D wrote: > It's now too late to change > that for versions 1.0 and 1.1 of the LSB specification=20 I know no one's going to actually listen to me here, but it bears repeating: this is quite simply wrong. It's our spec. We can do whatever we like to it. We can declare that packages written by people whose middle name has an odd number of letters were never intended to comply with the specs, and issue updates to both version 1.0 and 1.1 tomorrow to say that. No one is going to stop us. We're not going to be thrown in prison. We're not going to have our editors or our web pages taken away from us. More to the point: we're not even going to annoy anyone. Of the distributors who've started trying to conform to the LSB, *none* of them will have to change anything. Any application developers who've been writing LSB packages will be pleased to have been informed of what they have to do to make sure their programs actually run on Debian. People writing test suites will have one less thing to try to test, so they'll be overjoyed. We could do this tomorrow, and _no one_ would have any cause to complain. Of course, the *real* lesson to learn from this is *NEVER* *EVER* to make an official release without having a thorough round of reviews and actually resolving all the issues that're raised, no matter how long this takes. The uid-of-user-bin issue was raised as soon as we saw the form that section took, which unfortunately was immediately after the 1.0 spec was published, and during the review period for the 1.1 spec. Cheers, aj --=20 Anthony Towns We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each=20 toe individually.'' -- with kudos to Greg Lehey --hOcCNbCCxyk/YU74 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHPONORRvX9xctrtAQFSQwQAlMH0UNp/HiTLYlxMgMIKQFPBR50EEfXv /Ahp9EyvRILIBrhScwqPhNajXx2Xcy/JH6R9ij0Dv0DXoZmPoVyFj+CVqmWoX0/4 AmnaA5t1Xu1vJ+9he0hhBVpKY8408CBsBIKYkxivIR3Enk0hXnZA8NJ4m1IXwJQ3 bFZnxPGf5Ms= =PeW2 -----END PGP SIGNATURE----- --hOcCNbCCxyk/YU74-- From lawrencc@debian.org Wed Feb 20 16:27:13 2002 From: lawrencc@debian.org (Chris Lawrence) Date: Wed, 20 Feb 2002 10:27:13 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <717252EC3E37AE4392E2614EA24E9F2B1ECD7E@txnexc01.americas.cpqcorp.net> References: <717252EC3E37AE4392E2614EA24E9F2B1ECD7E@txnexc01.americas.cpqcorp.net> Message-ID: <20020220162713.GB13253@phy.olemiss.edu> On Feb 20, VomLehn, David wrote: > The fix for this follows a well-beaten path--we are not the first > standardization body to make a mistake. Assuming there is nobody who can > find any reason for the current state of affairs, the very next release > of the LSB includes, 1) a statement that the requirement that uid and > gid be one is deprecated and will become obsolete in a future release, > 2) specify that the plan is to obsolete this requirement in the first > approved version of the LSB specification after a particular date, and > 3) deliver on item 2. Sounds reasonable enough to me, I guess. I think our main concern over on the Debian side of the aisle is that this will be a sticking point for conformance; we want to have LSB support, and we'd like to be as close as possible to full support in woody, and be fully conformant for woody+1. (Not that we officially have any woody+1 release goals beyond contining the pre-FHS symlink phaseout.) Anyway, if people on the lsb-spec list want to see how close we are to conformance (IMHO, of course ;-), the place to start is the start of the thread (lsb-spec got on a few posts in): http://lists.debian.org/debian-devel/2002/debian-devel-200202/msg01335.html and what I have so far (including a few minor fixes) is: http://people.debian.org/~lawrencc/lsb_1.1.0-2.tar.gz Chris -- Chris Lawrence - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765 From mats.d.wichmann@intel.com Wed Feb 20 18:24:23 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Wed, 20 Feb 2002 10:24:23 -0800 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <39B5C4829263D411AA93009027AE9EBB111CA00C@FMSMSX35> > On Wed, Feb 20, 2002 at 08:13:13AM -0800, Wichmann, Mats D wrote: > > It's now too late to change > > that for versions 1.0 and 1.1 of the LSB specification I didn't, actually. That was David. > Of course, the *real* lesson to learn from this is *NEVER* *EVER* to > make an official release without having a thorough round of > reviews Which there was... > and > actually resolving all the issues that're raised, no matter how long > this takes. The participants seemed to agree that there needed to be a process that included a finishing date. That process was followed, and there was plenty of room to comment. Are there going to be "bugs" in the result that are found when it's actually put into use? Of course, like with any product. From andrew@pimlott.ne.mediaone.net Wed Feb 20 18:30:43 2002 From: andrew@pimlott.ne.mediaone.net (Andrew Pimlott) Date: Wed, 20 Feb 2002 13:30:43 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220100625.G429-100000@trantor.sc.metrolink.com> References: <20020220145707.GA25873@azure.humbug.org.au> <20020220100625.G429-100000@trantor.sc.metrolink.com> Message-ID: <20020220183043.GC11521@pimlott.ne.mediaone.net> On Wed, Feb 20, 2002 at 10:15:03AM -0500, Stuart Anderson wrote: > The words in question were written well over a year ago, which is why it > is hard to recall the details. ... > I don't mind removing it, but I do mind making random, uncontrolled changes > to a document that is supposed to be stable and "controlled". My point in this > is that we need to follow a proper process in making changes like this. I guess this will come off as smart, but if it is "controlled", I would have expected someone to write down why this section was written in the first place. It sounds like the early versions were hastily slapped together (this is not the only section that gives me this impression), yet now you expect people to endure a painful process to make obviously needed amendments. Andrew From dtype@dtype.org Wed Feb 20 19:05:05 2002 From: dtype@dtype.org (M. Drew Streib) Date: Wed, 20 Feb 2002 19:05:05 +0000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220183043.GC11521@pimlott.ne.mediaone.net> References: <20020220145707.GA25873@azure.humbug.org.au> <20020220100625.G429-100000@trantor.sc.metrolink.com> <20020220183043.GC11521@pimlott.ne.mediaone.net> Message-ID: <20020220190505.GL10581@dtype.org> --mqHBVT07r4ObqsKY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 01:30:43PM -0500, Andrew Pimlott wrote: > now you expect people to endure a painful process to make obviously > needed amendments. For the sake of forward movement, I'd like to suggest that we're not far from total agreement here: 1) There may not be a good reason for requiring these users, and especially at a particular uid. 2) We should investigate why the decision was made in the first place. This is only due diligence. I would expect any distribution to do the same before making a change that _potentially_ broke expected behavior. 3) If we find that there wasn't a good reason for these users, or=20 that the reasons don't outweigh the 'brokenness' of requiring them, they should be removed via the proper methods for standards revision. Unfortunately, this isn't quite as easy as simply making the change, as the first spec revisions, like it or not, are printed and labeled. This doesn't mean that the change can't be made however. Moving forward, it would seem most productive to simply find the past discussion on this isssue, if any, then counter any decisions made in the past with the discusion from the past couple of days. It seems likely that this will result in a spec change, but=20 not pursuing at least a basic review of the facts (and history of that part of the spec, if any) would be negligent. -drew --=20 M. Drew Streib , Free Standards Group (freestandards.org) co-founder, SourceForge.net | core team, freedb | sysadmin, Linux Intl. creator, keyanalyze report | maintnr, *.us.pgp.net | other freedom/law --mqHBVT07r4ObqsKY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxz82EACgkQg2i7WWb7wYx4iQCgi9VJQTJ+OEgBtZ0yz+0g+hzO /rgAn07BXvIiWTk8TUxAqqf4uUGfeZ1e =YRVi -----END PGP SIGNATURE----- --mqHBVT07r4ObqsKY-- From anderson@metrolink.com Wed Feb 20 19:05:48 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 14:05:48 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220183043.GC11521@pimlott.ne.mediaone.net> Message-ID: <20020220135357.G429-100000@trantor.sc.metrolink.com> On Wed, 20 Feb 2002, Andrew Pimlott wrote: > I guess this will come off as smart, but if it is "controlled", I > would have expected someone to write down why this section was > written in the first place. Good point. In fact, how to maintain a rational as part of the document was discussed. At the time, it didn't seem critical to include the rational in the standards document. (You can have a good debate about wether rational is appropriate for the normative parts of a standards). Anyway, because we all learn from what we do, it now seems that having the rational would be helpful. > It sounds like the early versions were hastily slapped together > (this is not the only section that gives me this impression), There were fewer people contributing back then, so some section probably were hastily written. > yet > now you expect people to endure a painful process to make obviously > needed amendments. It doesn't have to be a painful process. I didn't mean to imply that it should be, or even that is has to be a heavy process, only that some process must be followed. Changing the document simply because write access is available is not an appropriate process. I think we've demonstrated that there is concensus that the change should be made. I agree with that. I do think that before removing or deprecating something we should make sure we understand why it was added in the first place. If the answer is that it was rushed and overlooked in the beginning, then that's fine. If there is some other reason, then we need to be sure that we have considered it. Once this is done, then we can change the wording in the spec to indicate that is is deprecated. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From lawrencc@debian.org Wed Feb 20 19:17:54 2002 From: lawrencc@debian.org (Chris Lawrence) Date: Wed, 20 Feb 2002 13:17:54 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220135357.G429-100000@trantor.sc.metrolink.com> References: <20020220183043.GC11521@pimlott.ne.mediaone.net> <20020220135357.G429-100000@trantor.sc.metrolink.com> Message-ID: <20020220191754.GB16644@phy.olemiss.edu> On Feb 20, Stuart Anderson wrote: > On Wed, 20 Feb 2002, Andrew Pimlott wrote: > > > I guess this will come off as smart, but if it is "controlled", I > > would have expected someone to write down why this section was > > written in the first place. > > Good point. In fact, how to maintain a rational as part of the document > was discussed. At the time, it didn't seem critical to include the rational > in the standards document. (You can have a good debate about wether rational > is appropriate for the normative parts of a standards). Anyway, because we > all learn from what we do, it now seems that having the rational would be > helpful. If nothing else, a rationale would help flesh things out for people doing a clean-room implementation. I for one was mystified about the init runlevel section, and also had trouble figuring out what was supposed to apply just to LSB *applications* and what applies to LSB implementations. (For example, do all init scripts on a system have to comply with LSB's specification, i.e. regarding return codes and arguments, or just the ones provided by LSB conforming applications?) Rationale would clear some of this stuff up. (i.e. "We required the status argument because some distributions have tools that depend on it." versus "We required the status argument because some applications need to learn the state of services started by init.") Chris -- Chris Lawrence - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765 From teg@redhat.com Wed Feb 20 19:31:20 2002 From: teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) Date: 20 Feb 2002 14:31:20 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220162629.GC27175@azure.humbug.org.au> References: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> <20020220162629.GC27175@azure.humbug.org.au> Message-ID: Anthony Towns writes: > On Wed, Feb 20, 2002 at 08:13:13AM -0800, Wichmann, Mats D wrote: > > It's now too late to change > > that for versions 1.0 and 1.1 of the LSB specification > > I know no one's going to actually listen to me here, but it bears > repeating: this is quite simply wrong. > > It's our spec. We can do whatever we like to it. We can declare that > packages written by people whose middle name has an odd number of > letters were never intended to comply with the specs, and issue updates > to both version 1.0 and 1.1 tomorrow to say that. No one is going to stop > us. We're not going to be thrown in prison. We're not going to have our > editors or our web pages taken away from us. > > More to the point: we're not even going to annoy anyone. Of the > distributors who've started trying to conform to the LSB, *none* of them > will have to change anything. Any application developers who've been > writing LSB packages will be pleased to have been informed of what they > have to do to make sure their programs actually run on Debian. They don't care about running on Debian - at least, they shouldn't. If they have written a program using this part of LSB 1.0, it shouldn't matter if it's Debian, Slackware or Caldera they are running on if these distribution claim to implement the standard. If they don't claim to implement it, the program isn't expected to run anyway. Any revision of the standard shouldn't go through overnight, but be in a future revision after being carefully reviewed, and a rationale for the change should be given (as it should have for being in there in the first place). > We could do this tomorrow, and _no one_ would have any cause to > complain. Anyone using it (developers, book printers, etc) would have cause. -- Trond Eivind Glomsrød Red Hat, Inc. From anderson@metrolink.com Wed Feb 20 19:48:16 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 14:48:16 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220161739.GB27175@azure.humbug.org.au> Message-ID: <20020220143012.X429-100000@trantor.sc.metrolink.com> Anthony, First off, I'd like to say that I appreciate your diligence in poking us with these issues. Because we are all human, we can only deal with so many things at once, and as a result stuff falls through the cracks. If it weren't for you and others that continue to champion these issues, we would be stuck with some bad decisions. We thought that we had things in place (such as the bug tracking system on sourceforge) to help us ensure that things didn't fall through the cracks. Apparently, though it has helped tremendously, we still have problems with this. Now, before things get completely ramped up for the next release of the spec, is a good time to examine these kinds of proceedure to see how well they have worked. Since it is obvious that they haven't, I have created and assigned to myself a Task to examing the bug processing proceedure we have used. This proceedure should be more consensus based with a few more checks and balances that we currently have. One of the known issues that we have is the lack of a proper dispute resolution mechanism. This is being worked on in a larger context, but is not yet available. Lacking a proper mechanism for this, if you can provide me the list of bug numbers that you felt were inappropriately closed or rejected, I will re-open them and ensure that they are properly addressed. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From spotter@yucs.org Wed Feb 20 21:04:56 2002 From: spotter@yucs.org (Shaya Potter) Date: 20 Feb 2002 16:04:56 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220135357.G429-100000@trantor.sc.metrolink.com> References: <20020220135357.G429-100000@trantor.sc.metrolink.com> Message-ID: <1014239099.7817.123.camel@zaphod> On Wed, 2002-02-20 at 14:05, Stuart Anderson wrote: > On Wed, 20 Feb 2002, Andrew Pimlott wrote: > > > I guess this will come off as smart, but if it is "controlled", I > > would have expected someone to write down why this section was > > written in the first place. > > Good point. In fact, how to maintain a rational as part of the document > was discussed. At the time, it didn't seem critical to include the rational > in the standards document. (You can have a good debate about wether rational > is appropriate for the normative parts of a standards). Anyway, because we > all learn from what we do, it now seems that having the rational would be > helpful. rational as part of the spec document, would probably make the actuall spec a little "wordy" (not sure of the right term). There should perhaps be 2 documents, 1 would be the actual spec, the other would be the spec + rational. This would also help avoid the traditional disagreement in the meaning of the spec, as the "commentary" on the "bible" (so to speak) would be readily available :) From mats.d.wichmann@intel.com Wed Feb 20 21:52:12 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Wed, 20 Feb 2002 13:52:12 -0800 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <39B5C4829263D411AA93009027AE9EBB111CA00F@FMSMSX35> > rational as part of the spec document, would probably make the actuall > spec a little "wordy" (not sure of the right term). There should > perhaps be 2 documents, 1 would be the actual spec, the other would be > the spec + rational. This would also help avoid the traditional > disagreement in the meaning of the spec, as the "commentary" on the > "bible" (so to speak) would be readily available :) Rationale is often banished to the back of the document in an appendix, or for a large volume, to a separate document. Andrew Josey and others who've been through the mill several times can probably comment more on the reasons for including/excluding rationale. Certainly one con argument is that it makes more work since the rationale also has to have carefully crafted wording, and choices have to be made on what to include. Personally, I would have found a rationale section very useful as I came to this process quite late and the answer to certain questions seemed on occasion to be "it's in the mail archive" - which, as we've just seen from the number of posts on this thread - can mean quite a bit of work to wade through - and may sometimes be buried under a subject name that doesn't seem to relate if the dicussion has evolved. Or to put it shorter, the historical record may be accurate, but it's not necessarily concise or to the point. From aj@azure.humbug.org.au Thu Feb 21 02:36:19 2002 From: aj@azure.humbug.org.au (Anthony Towns) Date: Thu, 21 Feb 2002 12:36:19 +1000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: References: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> <20020220162629.GC27175@azure.humbug.org.au> Message-ID: <20020221023619.GC16395@azure.humbug.org.au> --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 02:31:20PM -0500, Trond Eivind Glomsr?d wrote: > They don't care about running on Debian - at least, they shouldn't.=20 You're confused. ISV's using the LSB obviously care about running on Debian: they care about running on as many platforms as possible to increase their potential market share, either so they can make more money, or so they can be more famous. What they don't want to do is have to special case us. If they follow the LSB 1.0 or 1.1 specs, and make any use of the bin=3Duid 1 clause, then they'll find they *will* have to special case us, and that will annoy them, since the LSB's raison d'etre is to avoid that nonsense. Correcting the spec allows us to avoid annoying them. Not correcting it buys no one anything. > If > they have written a program using this part of LSB 1.0, it shouldn't > matter if it's Debian, Slackware or Caldera they are running on if > these distribution claim to implement the standard. If they don't > claim to implement it, the program isn't expected to run anyway. We're not designing this spec in a vacuum. There are real people out there with real needs that we're trying to satisfy. If we're not satisfying their needs now, we need to change it so we are. Debian is one set of such people, ISVs who want their products to run on both Red Hat and Debian are another. Our aim is to let people say "Sure, my program will run on Linux. Doesn't matter what flavour. Red Hat, SuSE, Debian, Slackware, heck, even BSD or Solaris via the compatability layers." We're not aiming to have people say "It'll run on Red Hat and SuSE. It won't run on Debian, because although that's Linux, it's not *really* Linux". Or at least, the people who I've talked to aren't. > Any revision of the standard shouldn't go through overnight,=20 > but be in a future revision after being carefully reviewed,=20 > and a rationale for > the change should be given (as it should have for being in there in > the first place). Sure. All of these things should happen. But they shouldn't be used as an excuse to delay or block a necessary change for months (like has already happened on this very issue) when the *original spec* had absolutely none of these things. > > We could do this tomorrow, and _no one_ would have any cause to > > complain. > Anyone using it (developers, book printers, etc) would have cause. All those masses of developers shipping LSB 1.0 or 1.1 compliant software? Or the masses of publishers who've already written whole chapters about why uid 1 should be the bin user, even though we can't think of even a sentence to justify it? > Trond Eivind Glomsr?d > Red Hat, Inc. Of course, I suppose Red Hat does have a market incentive to make it as difficult as possible for Debian to comply with the LSB.=20 "Oh, no, your products won't run on Debian, because those hacker wannabes can't manage to comply with simple community developed standards. Better buy Red Hat instead." So I suppose someone does have a cause to complain afterall. My mistake. Cheers, aj, who'd be much less bitter if the last seven months had resulted in pretty much anything other than "Oh, but Debian should suffer for our art too, coz Red Hat did" (Hi, Chris), or "Yes, yes, interesting point. But we must have a careful transition, and working out what that would be like is on our todo list, so please don't bother us now". --=20 Anthony Towns We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each=20 toe individually.'' -- with kudos to Greg Lehey --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHRdI+RRvX9xctrtAQGQOQP/cQgT4uZ1mPTdTwmCFJs79GIfYDj13il8 JyfLumNKqal6roI1UGyCUubRFqD4jGbcbwXzuDwUKBvxwcArifgNqHZWuODDM3+D e+vt2+tZGJgdYIfx8WL1DibFjQsLR4a9eMFl8ESHIzVxYJUS1h39H9a6iEMXRdRm 01AmA6H4on8= =ACGo -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- From shockwave@tlh.com.ar Wed Feb 20 02:48:04 2002 From: shockwave@tlh.com.ar (shockwave) Date: Tue, 19 Feb 2002 23:48:04 -0300 Subject: unsubscribe Message-ID: <003301c1b9b9$809dd440$32c80dd1@a> This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C1B99F.DFD37380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_000D_01C1B99F.DFD37380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
    ------=_NextPart_000_000D_01C1B99F.DFD37380-- From cyeoh@samba.org Thu Feb 21 02:56:25 2002 From: cyeoh@samba.org (Christopher Yeoh) Date: Thu, 21 Feb 2002 13:56:25 +1100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020221023619.GC16395@azure.humbug.org.au> References: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> <20020220162629.GC27175@azure.humbug.org.au> <20020221023619.GC16395@azure.humbug.org.au> Message-ID: <15476.25049.578373.529666@gargle.gargle.HOWL> At 2002/2/21 12:36+1000 Anthony Towns writes: > aj, who'd be much less bitter if the last seven months had resulted in > pretty much anything other than "Oh, but Debian should suffer for > our art too, coz Red Hat did" (Hi, Chris), or "Yes, yes, interesting Er. I never said that, I just pointed out that all the distributions have had to do a fair amount of work to become compliant and Debian is not alone in this regard. Chris. -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From david-downey@codecastle.com Thu Feb 21 03:35:40 2002 From: david-downey@codecastle.com (David D.W. Downey) Date: Wed, 20 Feb 2002 19:35:40 -0800 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <15476.25049.578373.529666@gargle.gargle.HOWL> Message-ID: OK, maybe I'm an idiot here, but I've been following this thread and I have a question. WHY does the LSB even _define_ numeric UID settings? For every distrib I've used, Slackware, SuSe, Mandrake, Red Hat, Debian, Peanut, Stampede, and others, any system user (meaning system related such as bin, adm, wheel, ect ect) were always extrememly low UID numbers. This in turn signifies to the system, as stated in the POSIX standard (don't shoot me if I'm wrong, been a LONG time since I've read it), are reserved specificly for system related accounts. These accounts have the required access privileges set up before any distrib is relased, regardless of maker. So, if X for instances, needs access to the video hardware (using sys or some other system defined account) all one needs to do is set the permissions to that user. Where the API would come in is in defining the test definition for determining the right account to use, not the physical UID number. If I am way off, don't fry me, this was a quick and dirty email for the question as it popped into my head. I'm willing learn a lesson or two if I'm off. David D.W. Downey -----Original Message----- From: Christopher Yeoh [mailto:cyeoh@samba.org] Sent: Wednesday, 20 February, 2002 6:56 PM To: debian-devel@lists.debian.org; lsb-spec@lists.linuxbase.org Subject: Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package At 2002/2/21 12:36+1000 Anthony Towns writes: > aj, who'd be much less bitter if the last seven months had resulted in > pretty much anything other than "Oh, but Debian should suffer for > our art too, coz Red Hat did" (Hi, Chris), or "Yes, yes, interesting Er. I never said that, I just pointed out that all the distributions have had to do a fair amount of work to become compliant and Debian is not alone in this regard. Chris. -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia -- To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org From knghtbrd@bluecherry.net Thu Feb 21 03:40:14 2002 From: knghtbrd@bluecherry.net (Joseph Carter) Date: Wed, 20 Feb 2002 19:40:14 -0800 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220105408.I429-100000@trantor.sc.metrolink.com> References: <20020220154732.GE16663@cibalia.gkvk.hr> <20020220105408.I429-100000@trantor.sc.metrolink.com> Message-ID: <20020221034014.GA3680@bluecherry.net> --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 10:57:49AM -0500, Stuart Anderson wrote: > > Okay, so let's summarize. This rule breaks things as it is. If we chang= e it, > > other things might break. However, nobody can think of what these other > > things are. The choice seems pretty clear, now let's start the procedur= e of > > changing. :) >=20 > OK 8-). I do feel that part of the proceedure is to understand why it was > added in the first place. The only thing worse than having it in there, w= ould > be to remove it, and then discover the hard way why it had been put in th= ere > to begin with. Thank you. It seems plainly obvious that this is necessary and I suspect not many will object to so doing, but I have come to discover that when dealing with groups you actually have to SAY these things now and then. As for how some of the users and groups LSB proposes as standard got there when nobody can seem to remember how or why, I can offer existing practice as a reason. You may recall that two of the things discussed early in the life of LSB were deployment to existing systems wherever practical and NFS shares between LSB compliant systems. The latter, I recall, was shot down for its impracticality when considering the former. They are explanation enough for a number of things I have seen reconsidered by the LSB project over the past few years. ;) I don't have old list archives handy and am currently unable to search to see if my memory happens to coincide neatly with reality yet. I doo seem to remember this very discussion taking place over this very case long ago now, so it is at least possible. =3D) --=20 Joseph Carter Hey, that's MY freak show! =20 mariab - don't think Debian hasn't had some very stupid and obvious bugs before of course, we usually fix ours BEFORE we release =3DD --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: 1024D/DCF9DAB3 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 iEYEARECAAYFAjx0bB4ACgkQj/fXo9z52rMPqACcCRU2gH9GTqdAkqIqli6oVFCI w+gAnjfARLbJW/DVl00QxCay8pCXNn46 =Fz37 -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From sesoft@263.net Thu Feb 21 05:06:15 2002 From: sesoft@263.net (sesoft@263.net) Date: Thu, 21 Feb 2002 13:06:15 +0800 Subject: ¾«µäÓªÏúÈí¼þÍƼö Message-ID: ¡ñËÑÒ׸ßËÙÓÊÖ·ËÑÑ°¼Ò[emailsearcher] ·¢²¼Ö÷Ò³£ºhttp://www.jstrade.com/ ×îа汾£ºV2.3 Èí¼þ´óС£º709KB ÎÞÐè°²×°¼´¿ÉʹÓà Ö÷Õ¾ÏÂÔØ£ºhttp://www.jstrade.com/emailsearcher/emailsearcher.exe Èí¼þÌØÉ«£º ¡ôÓòÃûµçÓÊËÑË÷£¬Ö»ÐèÊäÈëÒ»¸öºó׺Èçhotmail.com/email.com¼´¿ÉËÑË÷µçÓÊ ¡ô¸ßÆ·ÖʶàÏß³Ìģʽ£¬ÑéÖ¤ËÑË÷ËÙ¶È×î¿ì¿É´ïÿСʱ60000¸öÕæʵÓÐЧµçÓÊ ¡ôÊÖ¶¯/×Ô¶¯±£´æ½ø³Ì£¬¿ÉÖжϺó¼ÌÐøËÑË÷£¬¿ÉÍíÉÏÎÞÈËÖµÊØ£¬ÊÊÒË°üÔÂÉÏÍø ¡ô×Ô½¨×ÀÃæSMTP·þÎñÆ÷£¬¿Éµ¥·¢»òȺ·¢Îı¾/ÍøÒ³Ðżþµ½ËÑË÷ºóµÄÓÐЧÓÊÖ· ¡ôÓïÒô²Ù×÷»½ÐÑÌáʾ/×Ô¶¯¹Ò¶ÏÍøÂ磬¿ÉÓÚϵͳÍÐÅÌ´¦ºǫ́¹¤×÷£¬Ê¡Ê±Ê¡Ç® ¡ô¾«ÐıàÖÆ50Íò³£¼ûÓû§Ãû´Çµä£¬²¢ÇÒ¿É×ÔÐÐÀ©³ä£¬×î´óÌá¸ßËÑË÷×¼ÖлúÂÊ ¡ôÔùËÍ2000¸ö¹úÄÚÃâ·Ñ/µçÐÅÊÕ·ÑÓʼþ·þÎñÆ÷ºó׺£¬Èçsohu.com/263.net/µÈ ¡ô¶ÌÆÚÄÚ»ñµÃÊý°ÙÍòÕæʵ¿Í»§ÓªÏú×ÊÔ´£¬ÒÑΪºÜ¶à¹«Ë¾ºÍ¸öÈË׬ȡ·áºñÀûÈó ¡ñËÑÒ××ÀÃæÓʼþ·þÎñÆ÷[emailsender] ·¢²¼Ö÷Ò³£ºhttp://www.jstrade.com/ ×îа汾£ºV2.3 Èí¼þ´óС£º465KB ÎÞÐè°²×°¼´¿ÉʹÓà Ö÷Õ¾ÏÂÔØ£ºhttp://www.jstrade.com/emailsender/emailsender.exe Èí¼þÌØÉ«£º ¡ôÆÕͨµçÄÔ×Ô½¨SMTP·¢ËÍ·þÎñÆ÷£¬ÎÞÐèÔÙΪµçОÖ/ISP·âɱ·¢ÐÅÕʺŷ³ÄÕ ¡ô¸ßÆ·ÖʶàÏ̹߳¤×÷ģʽ£¬ÑéÖ¤·¢ÐÅËÙ¶È×î¿ì¿É´ïÿСʱ50000·âµçÓÊ ¡ôÊÖ¶¯/×Ô¶¯±£´æ½ø³Ì£¬¿ÉÖжϺó¼ÌÐø·¢ËÍ£¬¿ÉÍíÉÏÎÞÈËÖµÊØ£¬ÊÊÒË°üÔÂÉÏÍø ¡ôµ¥·¢/Ⱥ·¢¿ÉÑ¡£¬ÇáËɱà׫Îı¾/ÍøÒ³¸ñʽÐÅÌ壬֧³Ö²»ÏÞÊýÁ¿¸½¼þ·¢ËÍ ¡ôÓïÒô²Ù×÷»½ÐÑÌáʾ/×Ô¶¯¹Ò¶ÏÍøÂ磬¿ÉÓÚϵͳÍÐÅÌ´¦ºǫ́¹¤×÷£¬Ê¡Ê±Ê¡Ç® ¡ô¶ÔÿһÓÊÖ·ÌØ¿ì·¢ÐÅ£¬×Ô¶¯·ÖÀë·¢Ëͳɹ¦/ʧ°ÜµçÓÊ£¬ÇáËÉɸѡÓʼþÁбí¿â ¡ô¹úÄÚ¶à¼ÒÖªÃûµç×ÓÉÌÎñ¹«Ë¾Ñ¡Óã¬ÊÇÍƹãÍøÕ¾ºÍ¿ªÕ¹ÍøÉϹã¸æµÄ¾ø¼Ñ¹¤¾ß From schilling@fokus.gmd.de Thu Feb 21 12:12:03 2002 From: schilling@fokus.gmd.de (Joerg Schilling) Date: Thu, 21 Feb 2002 13:12:03 +0100 (CET) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <200202211212.g1LCC3oM001540@burner.fokus.gmd.de> >From: "David D.W. Downey" >WHY does the LSB even _define_ numeric UID settings? For every distrib I've >used, Slackware, SuSe, Mandrake, Red Hat, Debian, Peanut, Stampede, and >others, any system user (meaning system related such as bin, adm, wheel, ect >ect) were always extrememly low UID numbers. This in turn signifies to the >system, as stated in the POSIX standard (don't shoot me if I'm wrong, been a >LONG time since I've read it), are reserved specificly for system related >accounts. These accounts have the required access privileges set up before >any distrib is relased, regardless of maker. So, if X for instances, needs >access to the video hardware (using sys or some other system defined >account) all one needs to do is set the permissions to that user. Let me do a second try... If you believe that there is no need to garantee people to NFS mount /usr or anything that comes SUID/SGID to one of the system accounts, you don't need to specify numeric id's for anything than root. However, not specifying the numeric ID for "nobody" will introduce a big potential security problem when old (outdated) program implementations like gnutar or pax try to unpack TAR archives that conform to POSIX-2001 and hold users with numeric IDs > 2097151 whily unpacking based on numeric IDs (e.g. because the the passwd file is missing the right entries). Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From kukuk@suse.de Thu Feb 21 15:07:41 2002 From: kukuk@suse.de (Thorsten Kukuk) Date: Thu, 21 Feb 2002 16:07:41 +0100 Subject: Bug in spec: tty has tr options Message-ID: <20020221160741.A9975@suse.de> Hi, the LSB 1.1 spec seems to have a bug: The options described for tty are the one for tr. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrenstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B From alan@lxorguk.ukuu.org.uk Thu Feb 21 15:28:02 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Thu, 21 Feb 2002 15:28:02 +0000 (GMT) Subject: Bug in spec: tty has tr options In-Reply-To: <20020221160741.A9975@suse.de> from "Thorsten Kukuk" at Feb 21, 2002 04:07:41 PM Message-ID: > the LSB 1.1 spec seems to have a bug: The options described for tty > are the one for tr. Oops. I guess nobody can be compliant for two years while we obsolete it 8) From teg@redhat.com Thu Feb 21 20:10:57 2002 From: teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) Date: 21 Feb 2002 15:10:57 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020221023619.GC16395@azure.humbug.org.au> References: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> <20020220162629.GC27175@azure.humbug.org.au> <20020221023619.GC16395@azure.humbug.org.au> Message-ID: Anthony Towns writes: > On Wed, Feb 20, 2002 at 02:31:20PM -0500, Trond Eivind Glomsrød wrote: > > They don't care about running on Debian - at least, they shouldn't. > > You're confused. > > ISV's using the LSB obviously care about running on Debian: they care about > running on as many platforms as possible to increase their potential market > share, either so they can make more money, or so they can be more > famous. My point it they shouldn't have to care about distribution specific items, issues coming from Debian or anyone else. One of the main goals of LSB is to isolate the developers from this. > What they don't want to do is have to special case us. If they follow > the LSB 1.0 or 1.1 specs, and make any use of the bin=uid 1 clause, then > they'll find they *will* have to special case us, and that will annoy > them, since the LSB's raison d'etre is to avoid that nonsense. Correcting > the spec allows us to avoid annoying them. Not correcting it buys no > one anything. It's not a bug, it's a "why the ???? did this feature get added?" issue, which also highlights the necessity of documenting _why_ things are put into the standard. A specific release of particular distribution not conforming to the LSB standard is not an LSB bug. > > If they have written a program using this part of LSB 1.0, it > > shouldn't matter if it's Debian, Slackware or Caldera they are > > running on if these distribution claim to implement the > > standard. If they don't claim to implement it, the program isn't > > expected to run anyway. > > We're not designing this spec in a vacuum. There are real people out there > with real needs that we're trying to satisfy. If we're not satisfying > their needs now, we need to change it so we are. Debian is one set of > such people, ISVs who want their products to run on both Red Hat and > Debian are another. Debian not complying with LSB is not much of LSB need, it's a Debian need if they want to comply. > Our aim is to let people say "Sure, my program will run on Linux. Doesn't > matter what flavour. Red Hat, SuSE, Debian, Slackware, heck, even BSD > or Solaris via the compatability layers." We're not aiming to have > people say "It'll run on Red Hat and SuSE. It won't run on Debian, > because although that's Linux, it's not *really* Linux". Or at least, > the people who I've talked to aren't. Then Debian could fix it if they want to comply with the standard. > > Any revision of the standard shouldn't go through overnight, but > > be in a future revision after being carefully reviewed, and a > > rationale for the change should be given (as it should have for > > being in there in the first place). > > Sure. All of these things should happen. But they shouldn't be used as an > excuse to delay or block a necessary change for months (like has already > happened on this very issue) when the *original spec* had absolutely > none of these things. Changes should not get silently and quickly put in, unless they're typos or similar. > > > We could do this tomorrow, and _no one_ would have any cause to > > > complain. Anyone using it (developers, book printers, etc) > > > would have cause. > > All those masses of developers shipping LSB 1.0 or 1.1 compliant software? > Or the masses of publishers who've already written whole chapters about > why uid 1 should be the bin user, even though we can't think of even a > sentence to justify it? Or just printing the standard? One thing is having a 1.0.1 with this removed, but you don't just silently revise a standard. If I pick it up in print, I want 1.0 to be 1.0. Not one of a couple of 1.0s. > > Trond Eivind Glomsrød > > Red Hat, Inc. > > Of course, I suppose Red Hat does have a market incentive to make it > as difficult as possible for Debian to comply with the LSB. > > "Oh, no, your products won't run on Debian, because those hacker wannabes > can't manage to comply with simple community developed standards. Better > buy Red Hat instead." > > So I suppose someone does have a cause to complain afterall. My mistake. That's just stupid. > Cheers, > aj, who'd be much less bitter if the last seven months had resulted in > pretty much anything other than "Oh, but Debian should suffer for > our art too, coz Red Hat did" (Hi, Chris) Minimal suffering for everyone is a good thing. -- Trond Eivind Glomsrød Red Hat, Inc. From gk4@austin.ibm.com Fri Feb 22 16:19:31 2002 From: gk4@austin.ibm.com (George Kraft IV) Date: Fri, 22 Feb 2002 10:19:31 -0600 Subject: LSB Users & Groups References: Message-ID: <3C766F93.1B09F374@austin.ibm.com> Okay, I must take the credit, or blame for the LSB's initial Users & Groups section and its maintenance. :-) In December of 1999 I took the action item to investigate users & groups APIs, commands, user names, group names, uids, & gids. http://lists.debian.org/lsb-spec/2000/lsb-spec-200001/msg00056.html >From that list we sorted out what was to be standardized and what was to be left out. The LSB's ABI and command tables were updated accordingly, then the rest was discussed at workgroup & telephone conference meetings, and via email. We should all agree that root=0, and systems require the "bin" and "daemon" mnemonic user and group names. In retrospect, I guess if few programs/services are hardcoding 1, then they are wrong and specifying bin or daemon equal to 1 would be worse. :-) I agree that our processes need to be more systematic and/or precise. We will fix this ASAP and run "bin=1" and tty(1) through the process. http://www.linuxbase.org/spec/gLSB/gLSB/usernames.html http://www.linuxbase.org/spec/gLSB/gLSB/tty.html I appreciate everyone's constructive participation. Sincerely, George Kraft IV gk4@austin.ibm.com Senior Software Engineer IBM Linux Technology Center Chair of the LSB From wichert@wiggy.net Fri Feb 22 16:39:15 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Fri, 22 Feb 2002 17:39:15 +0100 Subject: LSB Users & Groups In-Reply-To: <3C766F93.1B09F374@austin.ibm.com> References: <3C766F93.1B09F374@austin.ibm.com> Message-ID: <20020222163915.GH6817@wiggy.net> Previously George Kraft IV wrote: > We should all agree that root=0, and systems require the "bin" and "daemon" > mnemonic user and group names. I would still like to see a rationale for requiring bin and daemon, they do not seem to serve any purpose. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From mstone@debian.org Fri Feb 22 16:59:37 2002 From: mstone@debian.org (Michael Stone) Date: Fri, 22 Feb 2002 11:59:37 -0500 Subject: LSB Users & Groups In-Reply-To: <3C766F93.1B09F374@austin.ibm.com>; from gk4@austin.ibm.com on Fri, Feb 22, 2002 at 10:19:31AM -0600 References: <3C766F93.1B09F374@austin.ibm.com> Message-ID: <20020222115937.R14610@justice.loyola.edu> --Fnm8lRGFTVS/3GuM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2002 at 10:19:31AM -0600, George Kraft IV wrote: > http://lists.debian.org/lsb-spec/2000/lsb-spec-200001/msg00056.html >=20 > From that list we sorted out what was to be standardized and what was to = be left > out. The LSB's ABI and command tables were updated accordingly, then the= rest > was discussed at workgroup & telephone conference meetings, and via email. So this debacle was caused by bad data? (bin and daemon are reversed for, at least, D5) > We should all agree that root=3D0, and systems require the "bin" and "dae= mon" > mnemonic user and group names Why? (not the root part ;-) --=20 Mike Stone --Fnm8lRGFTVS/3GuM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHZ4+Q0hVr09l8FJAQFHrAQAxldmvj4eVHW+PR+xCOsx+kgrdpyOuDm2 SRI514V1nG7AHgkunOhKLCNo6efl7vbezY/bHbWLV0bsdil56CrCEEat5168Zoql KIbCo1NaRZAyhhcK8jlw+kqhev2kqSeEUpH/d7IogWULXMpZP1tdqIv28PQzVnmt eNXuW3yGp/E= =3Fub -----END PGP SIGNATURE----- --Fnm8lRGFTVS/3GuM-- From gk4@austin.ibm.com Fri Feb 22 17:22:33 2002 From: gk4@austin.ibm.com (George Kraft IV) Date: Fri, 22 Feb 2002 11:22:33 -0600 Subject: LSB Users & Groups References: <3C766F93.1B09F374@austin.ibm.com> <20020222163915.GH6817@wiggy.net> Message-ID: <3C767E59.B3E923D5@austin.ibm.com> Wichert Akkerman wrote: > > Previously George Kraft IV wrote: > > We should all agree that root=0, and systems require the "bin" and "daemon" > > mnemonic user and group names. > > I would still like to see a rationale for requiring bin and daemon, they > do not seem to serve any purpose. > The thought was that some applications (and/or shell scripts) could/would fail if root.root, bin.bin, and daemon.daemon did not exist on a system; however, the other user and group names in the optional table below are just suggested. http://www.linuxbase.org/spec/gLSB/gLSB/usernames.html In short, the LSB v1.1.0 specification requires: root.root = 0 bin.bin = 1 daemon.daemon However, we've had a long discussion regarding bin = 1, and we will address that. :-) George (gk4) From wichert@wiggy.net Fri Feb 22 17:43:12 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Fri, 22 Feb 2002 18:43:12 +0100 Subject: LSB Users & Groups In-Reply-To: <3C767E59.B3E923D5@austin.ibm.com> References: <3C766F93.1B09F374@austin.ibm.com> <20020222163915.GH6817@wiggy.net> <3C767E59.B3E923D5@austin.ibm.com> Message-ID: <20020222174312.GJ6817@wiggy.net> Previously George Kraft IV wrote: > The thought was that some applications (and/or shell scripts) > could/would fail if root.root, bin.bin, and daemon.daemon did not > exist on a system That doesn't answer my question though. There is no (documented or otherwise) reason for bin and daemon existing. Nobody seems to know what to use them for and I haven't ever seen anything that uses them. Leaving them in LSB can only lead to different possibly conflicting kinds of usage for those accounts which does not help at all. The thought that an application might break also wasn't valid: applications can break due to any difference between LSB and existing systems, so if you follow that argument the LSB would have to document every possible existing Linux system or an application just might break. If an application does need an account for a special reason it can always create a system account for itself and use that. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From frankie@debian.org Fri Feb 22 18:07:14 2002 From: frankie@debian.org (Francesco P. Lovergine) Date: Fri, 22 Feb 2002 19:07:14 +0100 Subject: LSB Users & Groups In-Reply-To: <20020222174312.GJ6817@wiggy.net> References: <3C766F93.1B09F374@austin.ibm.com> <20020222163915.GH6817@wiggy.net> <3C767E59.B3E923D5@austin.ibm.com> <20020222174312.GJ6817@wiggy.net> Message-ID: <20020222180714.GB10351@localhost.localdomain> On Fri, Feb 22, 2002 at 06:43:12PM +0100, Wichert Akkerman wrote: > Previously George Kraft IV wrote: > > The thought was that some applications (and/or shell scripts) > > could/would fail if root.root, bin.bin, and daemon.daemon did not > > exist on a system > > That doesn't answer my question though. There is no (documented or > otherwise) reason for bin and daemon existing. Nobody seems to know > what to use them for and I haven't ever seen anything that uses them. > > Leaving them in LSB can only lead to different possibly conflicting > kinds of usage for those accounts which does not help at all. > > The thought that an application might break also wasn't valid: applications > can break due to any difference between LSB and existing systems, > so if you follow that argument the LSB would have to document every > possible existing Linux system or an application just might break. > > If an application does need an account for a special reason it can > always create a system account for itself and use that. > > Wichert. > Completely agree. Those accounts exist for hystorical reasons in other unices. I see no real rationale to require their existence in debian nowdays. -- Francesco P. Lovergine From Martijn van Oosterhout Fri Feb 22 21:50:54 2002 From: Martijn van Oosterhout (Martijn van Oosterhout) Date: Sat, 23 Feb 2002 08:50:54 +1100 Subject: LSB Users & Groups In-Reply-To: <20020222174312.GJ6817@wiggy.net>; from wichert@wiggy.net on Fri, Feb 22, 2002 at 06:43:12PM +0100 References: <3C766F93.1B09F374@austin.ibm.com> <20020222163915.GH6817@wiggy.net> <3C767E59.B3E923D5@austin.ibm.com> <20020222174312.GJ6817@wiggy.net> Message-ID: <20020223085054.C3466@svana.org> On Fri, Feb 22, 2002 at 06:43:12PM +0100, Wichert Akkerman wrote: > Previously George Kraft IV wrote: > > The thought was that some applications (and/or shell scripts) > > could/would fail if root.root, bin.bin, and daemon.daemon did not > > exist on a system > > That doesn't answer my question though. There is no (documented or > otherwise) reason for bin and daemon existing. Nobody seems to know > what to use them for and I haven't ever seen anything that uses them. Actually, on my debian unstable system here: daemon 111 0.0 0.3 1416 464 ? S 08:21 0:00 /sbin/portmap daemon 290 0.0 0.4 1420 608 ? S 08:21 0:00 /usr/sbin/atd So they are used and we can't summarily remove them. These could be shunted to another user, but which one? They *are* daemons. -- Martijn van Oosterhout http://svana.org/kleptog/ > If the company that invents a cure for AIDS is expected to make their > money back in 17 years, why can't we ask the same of the company that > markets big-titted lip-syncing chicks and goddamn cartoon mice? From wichert@wiggy.net Fri Feb 22 23:13:10 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Sat, 23 Feb 2002 00:13:10 +0100 Subject: LSB Users & Groups In-Reply-To: <20020223085054.C3466@svana.org> References: <3C766F93.1B09F374@austin.ibm.com> <20020222163915.GH6817@wiggy.net> <3C767E59.B3E923D5@austin.ibm.com> <20020222174312.GJ6817@wiggy.net> <20020223085054.C3466@svana.org> Message-ID: <20020222231309.GN6817@wiggy.net> Previously Martijn van Oosterhout wrote: > Actually, on my debian unstable system here: > > daemon 111 0.0 0.3 1416 464 ? S 08:21 0:00 /sbin/portmap > daemon 290 0.0 0.4 1420 608 ? S 08:21 0:00 /usr/sbin/atd That's a bug, they should create their own user and use that instead. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From lawrencc@debian.org Mon Feb 25 04:22:00 2002 From: lawrencc@debian.org (Chris Lawrence) Date: Sun, 24 Feb 2002 22:22:00 -0600 Subject: LSB package for Debian: final(?) release candidate In-Reply-To: <15473.45447.699122.380451@gargle.gargle.HOWL> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> Message-ID: <20020225042200.GA24546@bellsouth.net> FYI: I have a release candidate of the lsb package (version 1.1.0-3) available at: http://people.debian.org/~lawrencc/ Matt Taggart and I had an off-list discussion about what should be in the package, and this is the culmination of that work. Again, we'd like to see an LSB package that uses the init functionality so we can test our implementation. (The apache package *could*, but the prerm and postinst scripts appear to be Red Hat scripts with all the actions commented out.) Chris -- Chris Lawrence - http://www.lordsutch.com/chris/ From news@ccid-mrd.com.cn Tue Feb 26 05:07:39 2002 From: news@ccid-mrd.com.cn (news) Date: Tue, 26 Feb 2002 13:07:39 0800 Subject: 2002 CCID semiconductor industrial & market ANNAL reports Message-ID: <1014700059.40@com.cn> --_========_000000510_========_ Content-Type: text/plain; charset=""; format=flowed WELCOME TO ORDER 2002 CCID semiconductor Reports £¨For more information please visit our website WWW.CCID-MRD.COM.CN£© 1.A Review of 2001 China IC Industry & a Forecast on 2002-2005 2.A Review of 2001 China IC Market and a Forecast on 2002-2005 3.An Analysis of 2001 China IC Imports and Exports & a Forecast on 2002-2005 4. A Review of 2001 China Discrete Devices Industry & A Forecast on 2002-2005 5. An Analysis of 2001 China Export & Import of Discrete Devices & A Forecast on 2002-2005 6.A review of 2001 china¡¯s IC Market (by Catalogue) & a forecast on 2002-2005 7.A Review of China's 2001 Computer IC & a Forecast on 2002-2005 8.A Review of 2001 China Consumer IC & a Forecast on 2002-2005 9.A Review of 2001 China Telecommunication IC & a Forecast on 2002-2005 10.A Review of 2001 China IC Card and a Forecast on 2002-2005 11.A Review of 2001 China Memory and a Forecast on 2002-2005 12.A Review of 2001 China Analog Circuit and a Forecast on 2002-2005 13.A Review of 2001 China Power IC and a Forecast on 2002-2005 14.A Review of 2001 China DSP and a Forecast on 2002-2005 15.A Review of 2001 China MCU and a Forecast on 2002-2005 16.A Review of 2001 China Power IC and a Forecast on 2002-2005 17.A Review of 2001 China AD/DA and a Forecast on 2002-2005 18.MNCs Electronic Corporations In China: Investment, Marketing, And Trends 19.semiconductor MNCs in china: 2002 Edition Chinese only 34.A Survey of 2001 China Semiconductor's distribution market 20.A Review of 2001 China Semiconductor Equipment and Instruments and a Forecast on 2002-2005 22.A Review of 2001 China Electronic products and a Forecast on 2002-2005 23.A Review of 2001 China Semiconductor Industry Special Materials & A Forecast on 2002-2005 24.A Review of 2001 China Semiconductor Packaging materials and a Forecast on 2002-2005 25.A Review of 2001 World Semiconductor and a Forecast on 2002-2005 26.Research on China IC Industry Policy 27.2001 China IC Industry Annual Report£¨2002 Edition£© 31.China Semiconductor Information ( one edition per quarter) 33.2001 China Semiconductor Industry Association (CSIA) Member Directory 21.A Review of 2001 China LCD device and a Forecast on 2002-200529.A Review of 2001 China LED device and a Forecast on 2002-2005 30.A Review of China PCB Industry and market and forecast 32.A Review of China Connector Industry and market and forecast 1. 2001 China SMT Device Industry and Market: A Review & A Forecast 2. 2001 China SMT Equipment Industry and Market: A Review & A Forecast 3. 2001 China UPS Industry: A Review & A Forecast 4. 2001 China Transformer, Inductor and Ballast Industry and Market: A Review & A Forecast 5. 2001 China Primary Battery and Storage Battery Industry and Market: A Review & A Forecast 6. 2001 China Speaker and Headphone Industry and Market: A Review & A Forecast 7. 2001 China Switch, Plug and Outlet Industry and Market: A Review & A Forecast 8. 2001 China Magnetic Head Device Industry and Market: A Review & A Forecast 9. 2001 China Eletromagnet and Permanent Magnet Industry and Market: A Review & A Forecast 10. CCID Semiconductor Information£¨One Edition per three month£© 11. A survey of 2001 China Sparking Plug, Ignition Magnetos and Permanent DC Generator 12. 2001 China Buzzer Industry and Market: A Review & A Forecast 13. 2001 China Electric Relay Industry and Market: A Review & A Forecast 14. 2001 China Cathode Ray Tube Industry and Market: A Review & A Forecast 15. 2001 China insulated wire, cable and optical cable Industry and Market: A Review & A Forecast 16. 2001 China Carbon Electrode and Insulator Industry and Market: A Review & A Forecast 17. 2001 China Film Camera and Projector Industry and Market: A Review & A Forecast 18. 2001 China Electrical Fan, Air Conditioning and Dryer Industry and Market: A Review & A Forecast 19. 2001 China Auto Washing Machine and Clothes Dryer Industry and Market: A Review & A Forecast 20. 2001 China Dishwashing Machine (domestic household) Industry and Market: A Review & A Forecast 21. 2001 China Electrical Scale Industry and Market: A Review & A Forecast 22. 2001 China Embroider machine Industry and Market: A Review & A Forecast 23. 2001 China Calculating Machine Industry and Market: A Review & A Forecast 24. 2001 China Electronic Equipment for Kitchen Industry and Market: A Review & A Forecast 25. 2001 China Electric Razor Industry and Market: A Review & A Forecast 26. 2001 China Water Heater Industry and Market: A Review & A Forecast 27. 2001 China Electrical Hair Dressing Tool Industry and Market: A Review & A Forecast 28. 2001 China Electric Iron Industry and Market: A Review & A Forecast 29. 2001 China Radio Sets, Tape Recorder and Audio Industry and Market: A Review & A Forecast 30. 2001 China VF Megaphone Industry and Market: A Review & A Forecast 31. 2001 China Satellite Ground Station for TV Industry and Market: A Review & A Forecast 32. 2001 China VCD and DVD Industry and Market: A Review & A Forecast 33. 2001 China Set Top Box Industry and Market: A Review & A Forecast 34. 2001 China Telecamera Industry and Market: A Review & A Forecast 35. 2001 China Television Set Industry and Market: A Review & A Forecast 36. 2001 China Camera Industry and Market: A Review & A Forecast 37. 2001 China Audiphone Industry and Market: A Review & A Forecast 38. 2001 China Electric Watch and Timer Industry and Market: A Review & A Forecast 39. 2001 China Musical Instrument Industry and Market: A Review & A Forecast 40. 2001 China Video Game Machine Industry and Market: A Review & A Forecast 41. 2001 China Tape and Record Industry and Market: A Review & A Forecast 42. 2001 China Toys Motor Industry and Market: A Review & A Forecast 43. 2001 China Printer Industry and Market: A Review & A Forecast 44. 2001 China Cash Register and Sales Terminal Register Industry and Market: A Review & A Forecast 45. 2001 China Postage Stamper and Booking Machine Industry and Market: A Review & A Forecast 46. 2001 China Display Industry and Market: A Review & A Forecast 47. 2001 China Scanner Industry and Market: A Review & A Forecast 48. 2001 China Keyboard and Mouse Industry and Market: A Review & A Forecast 49. 2001 China Digital Equipment Industry and Market: A Review & A Forecast 50. 2001 China Storage Block Industry and Market: A Review & A Forecast 51. 2001 China Hardpan, Floppy Disc and Driver Industry and Market: A Review & A Forecast 52. 2001 China Money-Draw Machine Industry and Market: A Review & A Forecast 53. 2001 China Voltage-stabilized Source Industry and Market: A Review & A Forecast 54. 2001 China Disc and Magnetic Card Industry and Market: A Review & A Forecast 55. 2001 China Computer Software Industry and Market: A Review & A Forecast 56. 2001 China Telephone Industry and Market: A Review & A Forecast 57. 2001 China FAX Industry and Market: A Review & A Forecast 58. 2001 China Program-Controlled Exchange Industry and Market: A Review & A Forecast 59. 2001 China Optical Transmission Equipment Industry and Market: A Review & A Forecast 60. 2001 China IP Telephone Signal Converter Industry and Market: A Review & A Forecast 61. 2001 China Concentrator and Indicator Industry and Market: A Review & A Forecast 62. 2001 China Modem Industry and Market: A Review & A Forecast 63. 2001 China Facsimile Signal Sensor Industry and Market: A Review & A Forecast 64. 2001 China Walkie-Talkie Industry and Market: A Review & A Forecast 65. 2001 China Mobile Phone and Beeper Industry and Market: A Review & A Forecast 66. 2001 China Fibre-Optical Communication and Fibre-Optical Property tester Industry and Market: A Review & A Forecast 67. 2001 China Duplicator Industry and Market: A Review & A Forecast 68. 2001 China Mail Processor Industry and Market: A Review & A Forecast 69. 2001 China Paper-cutting Machine Industry and Market: A Review & A Forecast 70. 2001 China Auto Vending Machine Industry and Market: A Review & A Forecast 71. 2001 China Portal Electric Tool Industry and Market: A Review & A Forecast 72. 2001 China Sewing Machine Industry and Market: A Review & A Forecast 73. 2001 China Photo Enlarger and Reduction Printer Industry and Market: A Review & A Forecast 74. 2001 China Slide Projector Industry and Market: A Review & A Forecast 75. 2001 China Plotter Equipment Industry and Market: A Review & A Forecast 76. 2001 China Electric Lighting and Signal Equipment Industry and Market: A Review & A Forecast 77. 2001 China Electric Dry Oven and Heater Industry and Market: A Review & A Forecast 78. 2001 China Boarding Machine Industry and Market: A Review & A Forecast 79. 2001 China Traffic Control Equipment Industry and Market: A Review & A Forecast 80. 2001 China Warning Device Industry and Market: A Review & A Forecast 81. 2001 China Navigation Radio Facilities Industry and Market: A Review & A Forecast 82. 2001 China Metal-Mine detector Industry and Market: A Review & A Forecast 83. 2001 China Precipitator Industry and Market: A Review & A Forecast 84. 2001 China Injection Machine, Plastic Comminutor and Industry and Market: A Review & A Forecast 85. 2001 China Set Microscope Industry and Market: A Review & A Forecast 86. 2001 China Locating Compass Industry and Market: A Review & A Forecast 87. 2001 China rangefinder Industry and Market: A Review & A Forecast 88. 2001 China Barostat and Thermostat Industry and Market: A Review & A Forecast 89. 2001 China Machine Tools Industry and Market: A Review & A Forecast 90. 2001 China Automobile Equipment Industry and Market: A Review & A Forecast 91. 2001 China Medical Equipment Industry and Market: A Review & A Forecast 92. 2001 China Gasmeter, Watermeter and Eletrometer Industry and Market: A Review & A Forecast 93. 2001 China Odometer and Velograph Industry and Market: A Review & A Forecast 94. 2001 China Ammeter,Voltmeter and Multimeter Industry and Market: A Review & A Forecast 95. 2001 China OSC Industry and Market: A Review & A Forecast 96. 2001 China Resistance Tester Industry and Market: A Review & A Forecast Name: China Center of Information Industry Development(CCID) Microelectronics Reserch Department(MRD) Address£ºChina Semiconductor Industry Association.27,Rd.wanshoulu PC£º100846 Website£ºwww.ccid-mrd.com.cn EMAIL: guoyiran@ccid-mrd.com.cn NEWS@ccid-mrd.com.cn TEL: 86-10-68208592, 86-10-68208589 Fax: 86-10-68208590 , 86-10-68208594 Contact:¡¡Guo Yiran (¹ùÒãÈ») , Louisa Lv(ÂÀÕÜ) , Lydie Li(Àî°®»ª) --_========_000000510_========_ Content-Type: application/octet-stream; name="Information of China IC Market by CCID.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Information of China IC Market by CCID.htm" PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIg0K eG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCINCnhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVx dWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9R0IyMzEyIj4NCjxt ZXRhIG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9R2VuZXJh dG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDkiPg0KPG1ldGEgbmFtZT1PcmlnaW5hdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDkiPg0KPGxpbmsgcmVsPUZpbGUtTGlzdA0KaHJlZj0iLi9J bmZvcm1hdGlvbiUyMG9mJTIwQ2hpbmElMjBJQyUyME1hcmtldCUyMGJ5JTIwQ0NJRC5maWxlcy9m aWxlbGlzdC54bWwiPg0KPHRpdGxlPldFTENPTUUgVE8gT1JERVIgMjAwMiBDQ0lEIHNlbWljb25k dWN0b3IgUmVwb3J0czwvdGl0bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpEb2N1 bWVudFByb3BlcnRpZXM+DQogIDxvOkF1dGhvcj56ZW5nemhlbjwvbzpBdXRob3I+DQogIDxvOlRl bXBsYXRlPk5vcm1hbDwvbzpUZW1wbGF0ZT4NCiAgPG86TGFzdEF1dGhvcj5haWh1YTwvbzpMYXN0 QXV0aG9yPg0KICA8bzpSZXZpc2lvbj4yPC9vOlJldmlzaW9uPg0KICA8bzpUb3RhbFRpbWU+Mjwv bzpUb3RhbFRpbWU+DQogIDxvOkNyZWF0ZWQ+MjAwMi0wMi0yNVQwMToyMzowMFo8L286Q3JlYXRl ZD4NCiAgPG86TGFzdFNhdmVkPjIwMDItMDItMjVUMDE6MjM6MDBaPC9vOkxhc3RTYXZlZD4NCiAg PG86UGFnZXM+NTwvbzpQYWdlcz4NCiAgPG86V29yZHM+MTU0ODwvbzpXb3Jkcz4NCiAgPG86Q2hh cmFjdGVycz44ODI2PC9vOkNoYXJhY3RlcnM+DQogIDxvOkNvbXBhbnk+bXJkPC9vOkNvbXBhbnk+ DQogIDxvOkxpbmVzPjczPC9vOkxpbmVzPg0KICA8bzpQYXJhZ3JhcGhzPjE3PC9vOlBhcmFncmFw aHM+DQogIDxvOkNoYXJhY3RlcnNXaXRoU3BhY2VzPjEwODM4PC9vOkNoYXJhY3RlcnNXaXRoU3Bh Y2VzPg0KICA8bzpWZXJzaW9uPjkuMjgxMjwvbzpWZXJzaW9uPg0KIDwvbzpEb2N1bWVudFByb3Bl cnRpZXM+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpX b3JkRG9jdW1lbnQ+DQogIDx3OlB1bmN0dWF0aW9uS2VybmluZy8+DQogIDx3OkRyYXdpbmdHcmlk VmVydGljYWxTcGFjaW5nPjcuOCCw9TwvdzpEcmF3aW5nR3JpZFZlcnRpY2FsU3BhY2luZz4NCiAg PHc6RGlzcGxheUhvcml6b250YWxEcmF3aW5nR3JpZEV2ZXJ5PjA8L3c6RGlzcGxheUhvcml6b250 YWxEcmF3aW5nR3JpZEV2ZXJ5Pg0KICA8dzpEaXNwbGF5VmVydGljYWxEcmF3aW5nR3JpZEV2ZXJ5 PjI8L3c6RGlzcGxheVZlcnRpY2FsRHJhd2luZ0dyaWRFdmVyeT4NCiAgPHc6Q29tcGF0aWJpbGl0 eT4NCiAgIDx3OlNwYWNlRm9yVUwvPg0KICAgPHc6QmFsYW5jZVNpbmdsZUJ5dGVEb3VibGVCeXRl V2lkdGgvPg0KICAgPHc6RG9Ob3RMZWF2ZUJhY2tzbGFzaEFsb25lLz4NCiAgIDx3OlVMVHJhaWxT cGFjZS8+DQogICA8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCiAgIDx3OkFkanVzdExpbmVI ZWlnaHRJblRhYmxlLz4NCiAgIDx3OlVzZUZFTGF5b3V0Lz4NCiAgPC93OkNvbXBhdGliaWxpdHk+ DQogPC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6y87M5TsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWFsdDpTaW1TdW47DQoJ bXNvLWZvbnQtY2hhcnNldDoxMzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCglt c28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MyAxMzUxMzUyMzIg MTYgMCAyNjIxNDUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcMDAwQgwiOw0KCXBh bm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtYWx0OiJUaW1lcyBOZXcgUm9t YW4iOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpyb21h bjsNCgltc28tZm9udC1mb3JtYXQ6b3RoZXI7DQoJbXNvLWZvbnQtcGl0Y2g6YXV0bzsNCgltc28t Zm9udC1zaWduYXR1cmU6MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEDLzszlIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWNoYXJz ZXQ6MTM0Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6 dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjEgMTM1MTM1MjMyIDE2IDAgMjYyMTQ0IDA7 fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTpp bnRlci1pZGVvZ3JhcGg7DQoJbXNvLXBhZ2luYXRpb246bm9uZTsNCglmb250LXNpemU6MTAuNXB0 Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6y87M5TsNCgltc28tZm9udC1rZXJuaW5n OjEuMHB0O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6IzY2MDAwMDsNCglt c28tdGV4dC1hbmltYXRpb246bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZTsNCgl0ZXh0LXVu ZGVybGluZTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lOw0KCXRleHQtbGluZS10aHJvdWdo Om5vbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmds ZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlm eTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCW1zby1wYWdpbmF0aW9uOm5vbmU7 DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseTrLzszlOw0KCW1zby1oYW5zaS1mb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJbXNvLWZvbnQta2VybmluZzoxLjBwdDt9DQpwDQoJe21hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OsvOzOU7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KIC8qIFBhZ2UgRGVmaW5pdGlvbnMgKi8NCkBwYWdlDQoJe21zby1w YWdlLWJvcmRlci1zdXJyb3VuZC1oZWFkZXI6bm87DQoJbXNvLXBhZ2UtYm9yZGVyLXN1cnJvdW5k LWZvb3Rlcjpubzt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCglt YXJnaW46NzIuMHB0IDkwLjk1cHQgNzIuMHB0IDkwLjlwdDsNCgltc28taGVhZGVyLW1hcmdpbjo0 Mi41NXB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjQ5LjZwdDsNCgltc28tcGFwZXItc291cmNlOjA7 DQoJbGF5b3V0LWdyaWQ6MTUuNnB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30N Ci0tPg0KPC9zdHlsZT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1aSC1DTiBsaW5rPSIjNjYwMDAw IiB2bGluaz1wdXJwbGUgc3R5bGU9J3RhYi1pbnRlcnZhbDoyMS4wcHQ7DQp0ZXh0LWp1c3RpZnkt dHJpbTpwdW5jdHVhdGlvbic+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjEgc3R5bGU9J2xheW91dC1n cmlkOjE1LjZwdCc+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFz XT4mbmJzcDs8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGI+PHNwYW4N Cmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEw LjVwdDttc28taGFuc2ktZm9udC1mYW1pbHk6DQrLzszlO2NvbG9yOmJsdWUnPldFTENPTUUgVE8g T1JERVIgMjAwMiBDQ0lEIHNlbWljb25kdWN0b3IgUmVwb3J0czxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQt YWxpZ246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz6j qDxzcGFuIGxhbmc9RU4tVVM+Rm9yIG1vcmUgaW5mb3JtYXRpb24gcGxlYXNlDQp2aXNpdCBvdXIg d2Vic2l0ZSA8aT48c3BhbiBzdHlsZT0nY29sb3I6IzMzNjZGRic+PGENCmhyZWY9Imh0dHA6Ly93 d3cuY2NpZC1tcmQuY29tLmNuLyI+PHNwYW4gc3R5bGU9J2NvbG9yOiMzMzY2RkYnPldXVy5DQ0lE LU1SRC5DT00uQ048L3NwYW4+PC9hPjwvc3Bhbj48L2k+o6k8bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5i c3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4x LkENClJldmlldyBvZiAyMDAxIENoaW5hIElDIEluZHVzdHJ5ICZhbXA7IGEgRm9yZWNhc3Qgb24g MjAwMi0yMDA1PHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Mi5BDQpSZXZpZXcgb2Yg MjAwMSBDaGluYSBJQyBNYXJrZXQgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PHNwYW4NCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+My5Bbg0KQW5hbHlzaXMgb2YgMjAwMSBDaGlu YSBJQyBJbXBvcnRzIGFuZCBFeHBvcnRzICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz40LiBBDQpSZXZpZXcgb2Yg MjAwMSBDaGluYSBEaXNjcmV0ZSBEZXZpY2VzIEluZHVzdHJ5ICZhbXA7IEEgRm9yZWNhc3Qgb24g MjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41LiBB bg0KQW5hbHlzaXMgb2YgMjAwMSBDaGluYSBFeHBvcnQgJmFtcDsgSW1wb3J0IG9mIERpc2NyZXRl IERldmljZXMgJmFtcDsgQSBGb3JlY2FzdA0Kb24gMjAwMi0yMDA1PHNwYW4gc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz42LkENCnJldmlldyBvZiAyMDAxIGNoaW5hoa9zIElDIE1hcmtldCAoYnkg Q2F0YWxvZ3VlKSAmYW1wOyBhIGZvcmVjYXN0IG9uIDIwMDItMjAwNSA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Ny5BDQpSZXZpZXcgb2YgQ2hpbmEncyAyMDAxIENv bXB1dGVyIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21z by1oYW5zaS1mb250LWZhbWlseTrLzszlJz44LkENClJldmlldyBvZiAyMDAxIENoaW5hIENvbnN1 bWVyIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1o YW5zaS1mb250LWZhbWlseTrLzszlJz45LkENClJldmlldyBvZiAyMDAxIENoaW5hIFRlbGVjb21t dW5pY2F0aW9uIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xMC5BDQpSZXZpZXcgb2YgMjAwMSBDaGluYSBJ QyBDYXJkIGFuZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MTEuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hpbmEgTWVtb3J5IGFu ZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz4xMi5BDQpSZXZpZXcgb2YgMjAwMSBDaGluYSBBbmFsb2cgQ2lyY3VpdCBhbmQg YSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+MTMuQSBSZXZpZXcNCm9mIDIwMDEgQ2hpbmEgUG93ZXIgSUMgYW5kIGEgRm9yZWNh c3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjE0LkENClJldmlldyBvZiAyMDAxIENoaW5hIERTUCBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIw MDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTUuQQ0KUmV2aWV3 IG9mIDIwMDEgQ2hpbmEgTUNVIGFuZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xNi5BDQpSZXZpZXcgb2YgMjAwMSBDaGlu YSBQb3dlciBJQyBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28t aGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTcuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hpbmEgQUQvREEg YW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OsvOzOUnPjE4Lk1OQ3MNCkVsZWN0cm9uaWMgQ29ycG9yYXRpb25zIEluIENoaW5hOiBJ bnZlc3RtZW50LCBNYXJrZXRpbmcsIEFuZCBUcmVuZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2kt Zm9udC1mYW1pbHk6y87M5Sc+MTkuc2VtaWNvbmR1Y3Rvcg0KTU5DcyBpbiBjaGluYTogMjAwMiBF ZGl0aW9uIENoaW5lc2Ugb25seSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MzQuQQ0KU3VydmV5PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsg PC9zcGFuPm9mPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4y MDAxIENoaW5hIFNlbWljb25kdWN0b3IncyBkaXN0cmlidXRpb24NCm1hcmtldCA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MjAuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hp bmEgU2VtaWNvbmR1Y3RvciBFcXVpcG1lbnQgYW5kIEluc3RydW1lbnRzIGFuZCBhIEZvcmVjYXN0 IG9uDQoyMDAyLTIwMDUgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjIyLkENClJldmlldyBvZiAyMDAxIENoaW5hIEVsZWN0cm9uaWMgcHJvZHVjdHMgYW5kIGEgRm9y ZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjIzLkENClJldmlldyBvZiAyMDAxIENoaW5hIFNlbWljb25kdWN0b3IgSW5kdXN0cnkgU3Bl Y2lhbDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46DQp5ZXMiPiZuYnNwOyA8L3NwYW4+TWF0ZXJp YWxzICZhbXA7IEEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5z aS1mb250LWZhbWlseTrLzszlJz4yNC5BIFJldmlldw0Kb2YgMjAwMSBDaGluYSBTZW1pY29uZHVj dG9yIFBhY2thZ2luZyBtYXRlcmlhbHMgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI1LkENClJldmlldyBvZiAyMDAx IFdvcmxkIFNlbWljb25kdWN0b3IgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI2LlJlc2VhcmNoDQpvbiBDaGluYSBJ QyBJbmR1c3RyeSBQb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M 5Sc+MjcuMjAwMQ0KQ2hpbmEgSUMgSW5kdXN0cnkgQW5udWFsIFJlcG9ydKOoMjAwMiBFZGl0aW9u o6k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MzEuQ2hpbmENClNl bWljb25kdWN0b3IgSW5mb3JtYXRpb24gKCBvbmUgZWRpdGlvbiBwZXIgcXVhcnRlcik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MzMuMjAwMQ0KQ2hpbmEgU2VtaWNv bmR1Y3RvciBJbmR1c3RyeSBBc3NvY2lhdGlvbiAoQ1NJQSkgTWVtYmVyIERpcmVjdG9yeSA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MjEuQQ0KUmV2aWV3IG9mIDIw MDEgQ2hpbmEgTENEIGRldmljZSBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+PG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNp LWZvbnQtZmFtaWx5OsvOzOUnPjI5LkENClJldmlldyBvZiAyMDAxIENoaW5hIExFRCBkZXZpY2Ug YW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OsvOzOUnPjMwLkENClJldmlldyBvZiBDaGluYSBQQ0IgSW5kdXN0cnkgYW5kIG1hcmtl dCBhbmQgZm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjMyLkENClJldmlldyBvZiBDaGluYSBDb25uZWN0b3IgSW5kdXN0cnkgYW5kIG1hcmtldCBhbmQg Zm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjEuIDIw MDENCkNoaW5hIFNNVCBEZXZpY2UgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsg QSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Mi4g MjAwMQ0KQ2hpbmEgU01UIEVxdWlwbWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz4zLiAyMDAxDQpDaGluYSBVUFMgSW5kdXN0cnk6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3Qg PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjQuIDIwMDENCkNoaW5h IFRyYW5zZm9ybWVyLCBJbmR1Y3RvciBhbmQgQmFsbGFzdCBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+NS4gMjAwMQ0KQ2hpbmEgUHJpbWFyeSBCYXR0ZXJ5IGFuZCBTdG9yYWdlIEJh dHRlcnkgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjYuPHNwYW4NCnN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIFNwZWFrZXIgYW5kIEhl YWRwaG9uZQ0KSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Ny48c3Bhbg0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hpbmEgU3dpdGNoLCBQbHVn IGFuZCBPdXRsZXQNCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjguPHNwYW4NCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIE1hZ25ldGlj IEhlYWQgRGV2aWNlDQpJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45LiAyMDAxDQpD aGluYSBFbGV0cm9tYWduZXQgYW5kIFBlcm1hbmVudCBNYWduZXQgSW5kdXN0cnkgYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZv bnQtZmFtaWx5OsvOzOUnPjEwLg0KQ0NJRCBTZW1pY29uZHVjdG9yIEluZm9ybWF0aW9uo6hPbmUg RWRpdGlvbiBwZXIgdGhyZWUgbW9udGijqSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+MTEuIEENCnN1cnZleSBvZiAyMDAxIENoaW5hIFNwYXJraW5nIFBsdWcsIEln bml0aW9uIE1hZ25ldG9zIGFuZCBQZXJtYW5lbnQgREMNCkdlbmVyYXRvciA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTIuDQoyMDAxIENoaW5hIEJ1enplciBJbmR1 c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xMy4NCjIwMDEgQ2hpbmEgRWxlY3RyaWMgUmVs YXkgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTQuDQoyMDAxIENoaW5hIENhdGhv ZGUgUmF5IFR1YmUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTUuDQoyMDAxIENo aW5hIGluc3VsYXRlZCB3aXJlLCBjYWJsZSBhbmQgb3B0aWNhbCBjYWJsZSBJbmR1c3RyeSBhbmQg TWFya2V0OiBBDQpSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MTYuDQoyMDAxIENoaW5hIENhcmJvbiBFbGVjdHJvZGUgYW5k IEluc3VsYXRvciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTcuDQoyMDAxIENo aW5hIEZpbG0gQ2FtZXJhIGFuZCBQcm9qZWN0b3IgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZp ZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OsvOzOUnPjE4LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L3NwYW4+ MjAwMSBDaGluYSBFbGVjdHJpY2FsIEZhbiwgQWlyDQpDb25kaXRpb25pbmcgYW5kIERyeWVyIElu ZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjE5Lg0KMjAwMSBDaGluYSBBdXRvIFdhc2hp bmcgTWFjaGluZSBhbmQgQ2xvdGhlcyBEcnllciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dw0KJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MjAuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4y MDAxIENoaW5hIERpc2h3YXNoaW5nIE1hY2hpbmUNCihkb21lc3RpYyBob3VzZWhvbGQpIEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjIxLg0KMjAwMSBDaGluYSBFbGVjdHJpY2FsIFNj YWxlIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjIyLg0KMjAwMSBDaGluYSBFbWJy b2lkZXIgbWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4yMy4NCjIwMDEg Q2hpbmEgQ2FsY3VsYXRpbmcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz4yNC4NCjIwMDEgQ2hpbmEgRWxlY3Ryb25pYyBFcXVpcG1lbnQgZm9yIEtpdGNoZW4gSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsNCkEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI1Lg0KMjAwMSBDaGluYSBFbGVjdHJpYyBSYXpv ciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4yNi4NCjIwMDEgQ2hpbmEgV2F0ZXIg SGVhdGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI3Lg0KMjAwMSBDaGluYSBF bGVjdHJpY2FsIEhhaXIgRHJlc3NpbmcgVG9vbCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MjguDQoyMDAxIENoaW5hIEVsZWN0cmljIElyb24gSW5kdXN0cnkgYW5kIE1hcmtldDog QSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+MjkuDQoyMDAxIENoaW5hIFJhZGlvIFNldHMsIFRhcGUgUmVjb3JkZXIgYW5k IEF1ZGlvIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4zMC4NCjIwMDEgQ2hpbmEg VkYgTWVnYXBob25lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjMxLg0KMjAwMSBD aGluYSBTYXRlbGxpdGUgR3JvdW5kIFN0YXRpb24gZm9yIFRWIEluZHVzdHJ5IGFuZCBNYXJrZXQ6 IEEgUmV2aWV3ICZhbXA7DQpBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz4zMi4NCjIwMDEgQ2hpbmEgVkNEIGFuZCBEVkQgSW5kdXN0cnkgYW5kIE1h cmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2kt Zm9udC1mYW1pbHk6y87M5Sc+MzMuDQoyMDAxIENoaW5hIFNldCBUb3AgQm94IEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM0Lg0KMjAwMSBDaGluYSBUZWxlY2FtZXJhIEluZHVzdHJ5 IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNv LWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM1LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyA8L3NwYW4+MjAwMSBDaGluYSBUZWxldmlzaW9uIFNldCBJbmR1c3RyeSBhbmQN Ck1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MzYuDQoyMDAxIENoaW5hIENhbWVyYSBJbmR1c3RyeSBhbmQg TWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5z aS1mb250LWZhbWlseTrLzszlJz4zNy4NCjIwMDEgQ2hpbmEgQXVkaXBob25lIEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM4LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyA8L3NwYW4+MjAwMSBDaGluYSBFbGVjdHJpYyBXYXRjaCBhbmQgVGltZXINCkluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM5Lg0KMjAwMSBDaGluYSBNdXNpY2FsIEluc3Ry dW1lbnQgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NDAuDQoyMDAxIENoaW5hIFZp ZGVvIEdhbWUgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZv cmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz40MS4NCjIw MDEgQ2hpbmEgVGFwZSBhbmQgUmVjb3JkIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZh bXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjQyLg0KMjAwMSBDaGluYSBUb3lzIE1vdG9yIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3 ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjQzLg0KMjAwMSBDaGluYSBQcmludGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3 ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjQ0Lg0KMjAwMSBDaGluYSBDYXNoIFJlZ2lzdGVyIGFuZCBTYWxlcyBUZXJtaW5hbCBSZWdp c3RlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBDQpSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NDUuDQoyMDAxIENoaW5hIFBv c3RhZ2UgU3RhbXBlciBhbmQgQm9va2luZyBNYWNoaW5lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40Ni4NCjIwMDEgQ2hpbmEgRGlzcGxheSBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40Ny4NCjIwMDEgQ2hpbmEgU2Nhbm5lciBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40OC4NCjIwMDEgQ2hpbmEgS2V5Ym9hcmQgYW5kIE1vdXNlIEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjQ5Lg0KMjAwMSBDaGluYSBEaWdpdGFsIEVxdWlwbWVudCBJ bmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41MC4NCjIwMDEgQ2hpbmEgU3RvcmFnZSBC bG9jayBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41MS4NCjIwMDEgQ2hpbmEgSGFy ZHBhbiwgRmxvcHB5IERpc2MgYW5kIERyaXZlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOw0KQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+NTIuDQoyMDAxIENoaW5hIE1vbmV5LURyYXcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFy a2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1m b250LWZhbWlseTrLzszlJz41My4NCjIwMDEgQ2hpbmEgVm9sdGFnZS1zdGFiaWxpemVkIFNvdXJj ZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NTQuDQoyMDAxIENoaW5hIERpc2Mg YW5kIE1hZ25ldGljIENhcmQgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0K Rm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjU1Lg0K MjAwMSBDaGluYSBDb21wdXRlciBTb2Z0d2FyZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrL zszlJz41Ni4NCjIwMDEgQ2hpbmEgVGVsZXBob25lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2 aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OsvOzOUnPjU3Lg0KMjAwMSBDaGluYSBGQVggSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcg JmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M 5Sc+NTguDQoyMDAxIENoaW5hIFByb2dyYW0tQ29udHJvbGxlZCBFeGNoYW5nZSBJbmR1c3RyeSBh bmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28t aGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NTkuDQoyMDAxIENoaW5hIE9wdGljYWwgVHJhbnNtaXNz aW9uIEVxdWlwbWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3Jl Y2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NjAuPHNwYW4N CnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIElQIFRl bGVwaG9uZSBTaWduYWwgQ29udmVydGVyDQpJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz42MS48c3Bhbg0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEg Q2hpbmEgQ29uY2VudHJhdG9yIGFuZCBJbmRpY2F0b3INCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFt aWx5OsvOzOUnPjYyLg0KMjAwMSBDaGluYSBNb2RlbSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWls eTrLzszlJz42My4NCjIwMDEgQ2hpbmEgRmFjc2ltaWxlIFNpZ25hbCBTZW5zb3IgSW5kdXN0cnkg YW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNv LWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY0Lg0KMjAwMSBDaGluYSBXYWxraWUtVGFsa2llIElu ZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY1Lg0KMjAwMSBDaGluYSBNb2JpbGUgUGhv bmUgYW5kIEJlZXBlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3Jl Y2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NjYuDQoyMDAx IENoaW5hIEZpYnJlLU9wdGljYWwgQ29tbXVuaWNhdGlvbiBhbmQgRmlicmUtT3B0aWNhbCBQcm9w ZXJ0eSB0ZXN0ZXINCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY3Lg0KMjAwMSBD aGluYSBEdXBsaWNhdG9yIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY4Lg0KMjAw MSBDaGluYSBNYWlsIFByb2Nlc3NvciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1w OyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz42 OS4NCjIwMDEgQ2hpbmEgUGFwZXItY3V0dGluZyBNYWNoaW5lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6 IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz43MC4NCjIwMDEgQ2hpbmEgQXV0byBWZW5kaW5nIE1hY2hpbmUgSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NzEuDQoyMDAxIENoaW5hIFBvcnRhbCBFbGVjdHJp YyBUb29sIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjcyLg0KMjAwMSBDaGluYSBT ZXdpbmcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz43My48c3Bhbg0K c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hpbmEgUGhvdG8g RW5sYXJnZXIgYW5kIFJlZHVjdGlvbg0KUHJpbnRlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWls eTrLzszlJz43NC4NCjIwMDEgQ2hpbmEgU2xpZGUgUHJvamVjdG9yIEluZHVzdHJ5IGFuZCBNYXJr ZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZv bnQtZmFtaWx5OsvOzOUnPjc1LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L3NwYW4+MjAwMSBDaGluYSBQbG90dGVyIEVxdWlwbWVudCBJbmR1c3RyeQ0KYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9u dC1mYW1pbHk6y87M5Sc+NzYuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 IDwvc3Bhbj4yMDAxIENoaW5hIEVsZWN0cmljIExpZ2h0aW5nIGFuZCBTaWduYWwNCkVxdWlwbWVu dCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz43Ny4NCjIwMDEgQ2hpbmEgRWxlY3Ry aWMgRHJ5IE92ZW4gYW5kIEhlYXRlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1w OyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ NzguDQoyMDAxIENoaW5hIEJvYXJkaW5nIE1hY2hpbmUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBS ZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+NzkuDQoyMDAxIENoaW5hIFRyYWZmaWMgQ29udHJvbCBFcXVpcG1lbnQgSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjgwLg0KMjAwMSBDaGluYSBXYXJuaW5nIERldmlj ZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44MS4NCjIwMDEgQ2hpbmEgTmF2aWdh dGlvbiBSYWRpbyBGYWNpbGl0aWVzIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7 IEENCkZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44 Mi48c3Bhbg0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hp bmEgTWV0YWwtTWluZSBkZXRlY3RvciBJbmR1c3RyeQ0KYW5kIE1hcmtldDogQSBSZXZpZXcgJmFt cDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ ODMuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENo aW5hIFByZWNpcGl0YXRvciBJbmR1c3RyeSBhbmQNCk1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBG b3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODQuDQoy MDAxIENoaW5hIEluamVjdGlvbiBNYWNoaW5lLCBQbGFzdGljIENvbW1pbnV0b3IgYW5kIEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEENClJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44NS4NCjIwMDEgQ2hpbmEgU2V0IE1pY3Jvc2Nv cGUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODYuDQoyMDAxIENoaW5hIExvY2F0 aW5nIENvbXBhc3MgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODcuDQoyMDAxIENo aW5hIHJhbmdlZmluZGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjg4Lg0KMjAw MSBDaGluYSBCYXJvc3RhdCBhbmQgVGhlcm1vc3RhdCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+ODkuDQoyMDAxIENoaW5hIE1hY2hpbmUgVG9vbHMgSW5kdXN0cnkgYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9u dC1mYW1pbHk6y87M5Sc+OTAuDQoyMDAxIENoaW5hIEF1dG9tb2JpbGUgRXF1aXBtZW50IEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjkxLg0KMjAwMSBDaGluYSBNZWRpY2FsIEVxdWlw bWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45Mi4NCjIwMDEgQ2hpbmEgR2Fz bWV0ZXIsIFdhdGVybWV0ZXIgYW5kIEVsZXRyb21ldGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz45My4NCjIwMDEgQ2hpbmEgT2RvbWV0ZXIgYW5kIFZlbG9ncmFwaCBJbmR1c3Ry eSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+OTQuDQoyMDAxIENoaW5hIEFtbWV0ZXIsVm9sdG1l dGVyIGFuZCBNdWx0aW1ldGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6PHNwYW4NCnN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5BIFJldmlldyAmYW1wOyBB IEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45NS4N CjIwMDEgQ2hpbmEgT1NDIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjk2Lg0KMjAw MSBDaGluYSBSZXNpc3RhbmNlIFRlc3RlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8 IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlm XT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tdG9wOjBjbTttYXJn aW4tcmlnaHQ6MzAuMHB0O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0Og0KMTUuMHB0O21h cmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDoxNy4yNXB0O2xpbmUtaGVpZ2h0OjE1MCUn PjxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJc MDAwQgwiO2NvbG9yOm5hdnknPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5k aWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21hcmdpbi10b3A6MGNtO21h cmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6DQoxNS4wcHQ7 bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7bGluZS1oZWlnaHQ6MTUw JSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlwwMDBCDCI7Y29sb3I6bmF2eSc+TmFtZTogQzwvc3Bhbj48c3Bhbg0KbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjpu YXZ5Jz5oaW5hDQpDZW50ZXIgb2YgSW5mb3JtYXRpb24gSW5kdXN0cnkgRGV2ZWxvcG1lbnQoPC9z cGFuPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJcMDAwQgwiO2NvbG9yOm5hdnknPkNDSUQpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBz dHlsZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz48c3Bhbg0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFu DQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvc3Bhbj5NaWNyb2VsZWN0cm9uaWNz IFJlc2VyY2ggRGVwYXJ0bWVudChNUkQpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHls ZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTtt YXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcu MjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5BZGRyZXNzPC9zcGFuPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYXNjaWktZm9udC1mYW1pbHk6IlwwMDBC DCI7bXNvLWhhbnNpLWZvbnQtZmFtaWx5Og0KIlwwMDBCDCI7Y29sb3I6bmF2eSc+o7o8L3NwYW4+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJc MDAwQgwiO2NvbG9yOm5hdnknPkNoaW5hIFNlbWljb25kdWN0b3IgSW5kdXN0cnkNCkFzc29jaWF0 aW9uLjI3LFJkLndhbnNob3VsdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21h cmdpbi10b3A6MGNtO21hcmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2lu LWxlZnQ6DQoxNS4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7 bGluZS1oZWlnaHQ6MTUwJSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2eSc+UEM8L3NwYW4+PHNwYW4NCnN0eWxl PSdmb250LXNpemU6MTAuMHB0O21zby1hc2NpaS1mb250LWZhbWlseToiXDAwMEIMIjttc28taGFu c2ktZm9udC1mYW1pbHk6DQoiXDAwMEIMIjtjb2xvcjpuYXZ5Jz6jujwvc3Bhbj48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29s b3I6bmF2eSc+MTAwODQ2PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2lu LXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVm dDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcuMjVwdDtsaW5l LWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5XZWJzaXRlPC9zcGFuPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdDttc28tYXNjaWktZm9udC1mYW1pbHk6IlwwMDBCDCI7bXNvLWhh bnNpLWZvbnQtZmFtaWx5Og0KIlwwMDBCDCI7Y29sb3I6bmF2eSc+o7o8L3NwYW4+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmNvbG9yOm5hdnknPjxhIGhyZWY9Imh0 dHA6Ly93d3cuY2NpZC1tcmQuY29tLmNuLyI+d3d3LmNjaWQtbXJkLmNvbS5jbjwvYT48L3NwYW4+ PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7Y29sb3I6bmF2eSc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBz dHlsZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5FTUFJTDogPGENCmhy ZWY9Im1haWx0bzpndW95aXJhbkBjY2lkLW1yZC5jb20uY24iPmd1b3lpcmFuQGNjaWQtbXJkLmNv bS5jbjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tdG9wOjBj bTttYXJnaW4tcmlnaHQ6MzAuMHB0O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0Og0KMGNt O21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDoxNTAlJz48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2 eSc+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoNCnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YQ0K aHJlZj0ibWFpbHRvOk5FV1NAY2NpZC1tcmQuY29tLmNuIj5ORVdTQGNjaWQtbXJkLmNvbS5jbjwv YT48L3NwYW4+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OiJcMDAwQgwiO2Nv bG9yOiM2NjMzMDAnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21hcmdpbi10 b3A6MGNtO21hcmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6 DQoxNS4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7bGluZS1o ZWlnaHQ6MTUwJSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2eSc+VEVMOjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyA8L3NwYW4+ODYtMTAtNjgyMDg1OTIsPHNwYW4NCnN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU4OSZuYnNwOzwvc3Bhbj48 c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMw MCc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2luLXRvcDowY207bWFy Z2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDoNCjE1LjBwdDtt YXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAl Jz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi XDAwMEIMIjtjb2xvcjpuYXZ5Jz5GYXg6PHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU5MCAsPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU5NDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVT DQpzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMwMCc+PG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9J3RleHQtaW5kZW50OjMx LjVwdDttc28tY2hhci1pbmRlbnQtY291bnQ6My4wOw0KbXNvLWNoYXItaW5kZW50LXNpemU6MTAu NXB0Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseToiXDAwMEIMIjsNCmNvbG9y OiMzMzY2RkYnPkNvbnRhY3Q6PC9zcGFuPjxzcGFuIHN0eWxlPSdtc28tYXNjaWktZm9udC1mYW1p bHk6IlwwMDBCDCI7DQptc28taGFuc2ktZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzMzNjZG Ric+oaE8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtZmFtaWx5OiJcMDAwQgwi O2NvbG9yOiM2NjMzMDAnPkd1bzxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46DQp5ZXMiPiZuYnNw OyA8L3NwYW4+WWlyYW4gKDwvc3Bhbj48c3BhbiBzdHlsZT0nbXNvLWFzY2lpLWZvbnQtZmFtaWx5 OiJcMDAwQgwiOw0KbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiJcMDAwQgwiO2NvbG9yOiM2NjMzMDAn Prn50uPIuzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBC DCI7Y29sb3I6IzY2MzMwMCc+KSAsPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoNCnllcyI+Jm5i c3A7IDwvc3Bhbj5Mb3Vpc2EgTHYoPC9zcGFuPjxzcGFuIHN0eWxlPSdtc28tYXNjaWktZm9udC1m YW1pbHk6IlwwMDBCDCI7DQptc28taGFuc2ktZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2 MzMwMCc+wsDV3Dwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1mYW1pbHk6Ilww MDBCDCI7Y29sb3I6IzY2MzMwMCc+KSAsIDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0n Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCmNvbG9yOiM2NjMzMDAnPkx5ZGllIExpKDwvc3Bhbj48c3BhbiBzdHlsZT0nbXNv LWFzY2lpLWZvbnQtZmFtaWx5OiJcMDAwQgwiOw0KbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiJcMDAw QgwiO2NvbG9yOiM2NjMzMDAnPsDusK67qjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0n Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMwMCc+KTwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_========_000000510_========_ From msw@redhat.com Tue Feb 26 15:42:00 2002 From: msw@redhat.com (Matt Wilson) Date: Tue, 26 Feb 2002 10:42:00 -0500 Subject: LSB package for Debian: final(?) release candidate In-Reply-To: <20020225042200.GA24546@bellsouth.net>; from lawrencc@debian.org on Sun, Feb 24, 2002 at 10:22:00PM -0600 References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020225042200.GA24546@bellsouth.net> Message-ID: <20020226104200.A12134@devserv.devel.redhat.com> Ditto, we need some LSB package that installs an init script to test our functionality as well. Cheers, Matt On Sun, Feb 24, 2002 at 10:22:00PM -0600, Chris Lawrence wrote: > FYI: I have a release candidate of the lsb package (version 1.1.0-3) > available at: > > http://people.debian.org/~lawrencc/ > > Matt Taggart and I had an off-list discussion about what should be in > the package, and this is the culmination of that work. > > Again, we'd like to see an LSB package that uses the init > functionality so we can test our implementation. (The apache package > *could*, but the prerm and postinst scripts appear to be Red Hat > scripts with all the actions commented out.) > > > Chris > -- > Chris Lawrence - http://www.lordsutch.com/chris/ > > > -- > To UNSUBSCRIBE, email to lsb-spec-request@lists.linuxbase.org > with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org From mats.d.wichmann@intel.com Tue Feb 26 17:51:03 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Tue, 26 Feb 2002 09:51:03 -0800 Subject: LSB package for Debian: final(?) release candidate Message-ID: <39B5C4829263D411AA93009027AE9EBB16677A1E@FMSMSX35> > Ditto, we need some LSB package that installs an init script to test > our functionality as well. Suggest some existing packages that do so and I can take a little bit of time to root around and see if they're compilable as LSB apps. Mats From msw@redhat.com Tue Feb 26 17:52:49 2002 From: msw@redhat.com (Matt Wilson) Date: Tue, 26 Feb 2002 12:52:49 -0500 Subject: LSB package for Debian: final(?) release candidate In-Reply-To: <39B5C4829263D411AA93009027AE9EBB16677A1E@FMSMSX35>; from mats.d.wichmann@intel.com on Tue, Feb 26, 2002 at 09:51:03AM -0800 References: <39B5C4829263D411AA93009027AE9EBB16677A1E@FMSMSX35> Message-ID: <20020226125249.C22926@devserv.devel.redhat.com> Apache is the clear starting point. On Tue, Feb 26, 2002 at 09:51:03AM -0800, Wichmann, Mats D wrote: > > Suggest some existing packages that do so and I can take a little > bit of time to root around and see if they're compilable as LSB > apps. From mats.d.wichmann@intel.com Tue Feb 26 18:01:48 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Tue, 26 Feb 2002 10:01:48 -0800 Subject: LSB package for Debian: final(?) release candidate Message-ID: <39B5C4829263D411AA93009027AE9EBB16677A2D@FMSMSX35> Apache's already in the app battery. Does that mean it got built avoiding the init-script issue? > Apache is the clear starting point. > > On Tue, Feb 26, 2002 at 09:51:03AM -0800, Wichmann, Mats D wrote: > > > > Suggest some existing packages that do so and I can take a little > > bit of time to root around and see if they're compilable as LSB > > apps. > From msw@redhat.com Tue Feb 26 18:06:14 2002 From: msw@redhat.com (Matt Wilson) Date: Tue, 26 Feb 2002 13:06:14 -0500 Subject: LSB package for Debian: final(?) release candidate In-Reply-To: <39B5C4829263D411AA93009027AE9EBB16677A2D@FMSMSX35>; from mats.d.wichmann@intel.com on Tue, Feb 26, 2002 at 10:01:48AM -0800 References: <39B5C4829263D411AA93009027AE9EBB16677A2D@FMSMSX35> Message-ID: <20020226130614.E22926@devserv.devel.redhat.com> On Tue, Feb 26, 2002 at 10:01:48AM -0800, Wichmann, Mats D wrote: > Apache's already in the app battery. Does that mean it got built > avoiding the init-script issue? Or ignoring it. Cheers, Matt From dtype@dtype.org Tue Feb 26 18:31:50 2002 From: dtype@dtype.org (M. Drew Streib) Date: Tue, 26 Feb 2002 18:31:50 +0000 Subject: LSB package for Debian: final(?) release candidate In-Reply-To: <39B5C4829263D411AA93009027AE9EBB16677A2D@FMSMSX35> References: <39B5C4829263D411AA93009027AE9EBB16677A2D@FMSMSX35> Message-ID: <20020226183150.GM10581@dtype.org> --98VPa0byqqIRxGTH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 26, 2002 at 10:01:48AM -0800, Wichmann, Mats D wrote: > Apache's already in the app battery. Does that mean it got built > avoiding the init-script issue? Yes. I didn't have any implementations to work against, so I=20 skipped/avoided it at the time of the build. The source rpm is also on the ftp site, so it should be relatively easy to modify... -drew --=20 M. Drew Streib , Free Standards Group (freestandards.org) co-founder, SourceForge.net | core team, freedb | sysadmin, Linux Intl. creator, keyanalyze report | maintnr, *.us.pgp.net | other freedom/law --98VPa0byqqIRxGTH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjx71JYACgkQg2i7WWb7wYyz0wCfT76xuN/WwSH5AvZnLGKogGDc sGEAnjkdtYpWyybwJdGrl597HVtuzMda =k37Z -----END PGP SIGNATURE----- --98VPa0byqqIRxGTH-- From news@ccid-mrd.com.cn Wed Feb 27 00:41:28 2002 From: news@ccid-mrd.com.cn (news) Date: Wed, 27 Feb 2002 08:41:28 0800 Subject: 2002 CCID semiconductor industrial & market ANNAL reports Message-ID: <1014770488.520@com.cn> --_========_000000182_========_ Content-Type: text/plain; charset=""; format=flowed WELCOME TO ORDER 2002 CCID semiconductor Reports £¨For more information please visit our website WWW.CCID-MRD.COM.CN£© 1.A Review of 2001 China IC Industry & a Forecast on 2002-2005 2.A Review of 2001 China IC Market and a Forecast on 2002-2005 3.An Analysis of 2001 China IC Imports and Exports & a Forecast on 2002-2005 4. A Review of 2001 China Discrete Devices Industry & A Forecast on 2002-2005 5. An Analysis of 2001 China Export & Import of Discrete Devices & A Forecast on 2002-2005 6.A review of 2001 china¡¯s IC Market (by Catalogue) & a forecast on 2002-2005 7.A Review of China's 2001 Computer IC & a Forecast on 2002-2005 8.A Review of 2001 China Consumer IC & a Forecast on 2002-2005 9.A Review of 2001 China Telecommunication IC & a Forecast on 2002-2005 10.A Review of 2001 China IC Card and a Forecast on 2002-2005 11.A Review of 2001 China Memory and a Forecast on 2002-2005 12.A Review of 2001 China Analog Circuit and a Forecast on 2002-2005 13.A Review of 2001 China Power IC and a Forecast on 2002-2005 14.A Review of 2001 China DSP and a Forecast on 2002-2005 15.A Review of 2001 China MCU and a Forecast on 2002-2005 16.A Review of 2001 China Power IC and a Forecast on 2002-2005 17.A Review of 2001 China AD/DA and a Forecast on 2002-2005 18.MNCs Electronic Corporations In China: Investment, Marketing, And Trends 19.semiconductor MNCs in china: 2002 Edition Chinese only 34.A Survey of 2001 China Semiconductor's distribution market 20.A Review of 2001 China Semiconductor Equipment and Instruments and a Forecast on 2002-2005 22.A Review of 2001 China Electronic products and a Forecast on 2002-2005 23.A Review of 2001 China Semiconductor Industry Special Materials & A Forecast on 2002-2005 24.A Review of 2001 China Semiconductor Packaging materials and a Forecast on 2002-2005 25.A Review of 2001 World Semiconductor and a Forecast on 2002-2005 26.Research on China IC Industry Policy 27.2001 China IC Industry Annual Report£¨2002 Edition£© 31.China Semiconductor Information ( one edition per quarter) 33.2001 China Semiconductor Industry Association (CSIA) Member Directory 21.A Review of 2001 China LCD device and a Forecast on 2002-200529.A Review of 2001 China LED device and a Forecast on 2002-2005 30.A Review of China PCB Industry and market and forecast 32.A Review of China Connector Industry and market and forecast 1. 2001 China SMT Device Industry and Market: A Review & A Forecast 2. 2001 China SMT Equipment Industry and Market: A Review & A Forecast 3. 2001 China UPS Industry: A Review & A Forecast 4. 2001 China Transformer, Inductor and Ballast Industry and Market: A Review & A Forecast 5. 2001 China Primary Battery and Storage Battery Industry and Market: A Review & A Forecast 6. 2001 China Speaker and Headphone Industry and Market: A Review & A Forecast 7. 2001 China Switch, Plug and Outlet Industry and Market: A Review & A Forecast 8. 2001 China Magnetic Head Device Industry and Market: A Review & A Forecast 9. 2001 China Eletromagnet and Permanent Magnet Industry and Market: A Review & A Forecast 10. CCID Semiconductor Information£¨One Edition per three month£© 11. A survey of 2001 China Sparking Plug, Ignition Magnetos and Permanent DC Generator 12. 2001 China Buzzer Industry and Market: A Review & A Forecast 13. 2001 China Electric Relay Industry and Market: A Review & A Forecast 14. 2001 China Cathode Ray Tube Industry and Market: A Review & A Forecast 15. 2001 China insulated wire, cable and optical cable Industry and Market: A Review & A Forecast 16. 2001 China Carbon Electrode and Insulator Industry and Market: A Review & A Forecast 17. 2001 China Film Camera and Projector Industry and Market: A Review & A Forecast 18. 2001 China Electrical Fan, Air Conditioning and Dryer Industry and Market: A Review & A Forecast 19. 2001 China Auto Washing Machine and Clothes Dryer Industry and Market: A Review & A Forecast 20. 2001 China Dishwashing Machine (domestic household) Industry and Market: A Review & A Forecast 21. 2001 China Electrical Scale Industry and Market: A Review & A Forecast 22. 2001 China Embroider machine Industry and Market: A Review & A Forecast 23. 2001 China Calculating Machine Industry and Market: A Review & A Forecast 24. 2001 China Electronic Equipment for Kitchen Industry and Market: A Review & A Forecast 25. 2001 China Electric Razor Industry and Market: A Review & A Forecast 26. 2001 China Water Heater Industry and Market: A Review & A Forecast 27. 2001 China Electrical Hair Dressing Tool Industry and Market: A Review & A Forecast 28. 2001 China Electric Iron Industry and Market: A Review & A Forecast 29. 2001 China Radio Sets, Tape Recorder and Audio Industry and Market: A Review & A Forecast 30. 2001 China VF Megaphone Industry and Market: A Review & A Forecast 31. 2001 China Satellite Ground Station for TV Industry and Market: A Review & A Forecast 32. 2001 China VCD and DVD Industry and Market: A Review & A Forecast 33. 2001 China Set Top Box Industry and Market: A Review & A Forecast 34. 2001 China Telecamera Industry and Market: A Review & A Forecast 35. 2001 China Television Set Industry and Market: A Review & A Forecast 36. 2001 China Camera Industry and Market: A Review & A Forecast 37. 2001 China Audiphone Industry and Market: A Review & A Forecast 38. 2001 China Electric Watch and Timer Industry and Market: A Review & A Forecast 39. 2001 China Musical Instrument Industry and Market: A Review & A Forecast 40. 2001 China Video Game Machine Industry and Market: A Review & A Forecast 41. 2001 China Tape and Record Industry and Market: A Review & A Forecast 42. 2001 China Toys Motor Industry and Market: A Review & A Forecast 43. 2001 China Printer Industry and Market: A Review & A Forecast 44. 2001 China Cash Register and Sales Terminal Register Industry and Market: A Review & A Forecast 45. 2001 China Postage Stamper and Booking Machine Industry and Market: A Review & A Forecast 46. 2001 China Display Industry and Market: A Review & A Forecast 47. 2001 China Scanner Industry and Market: A Review & A Forecast 48. 2001 China Keyboard and Mouse Industry and Market: A Review & A Forecast 49. 2001 China Digital Equipment Industry and Market: A Review & A Forecast 50. 2001 China Storage Block Industry and Market: A Review & A Forecast 51. 2001 China Hardpan, Floppy Disc and Driver Industry and Market: A Review & A Forecast 52. 2001 China Money-Draw Machine Industry and Market: A Review & A Forecast 53. 2001 China Voltage-stabilized Source Industry and Market: A Review & A Forecast 54. 2001 China Disc and Magnetic Card Industry and Market: A Review & A Forecast 55. 2001 China Computer Software Industry and Market: A Review & A Forecast 56. 2001 China Telephone Industry and Market: A Review & A Forecast 57. 2001 China FAX Industry and Market: A Review & A Forecast 58. 2001 China Program-Controlled Exchange Industry and Market: A Review & A Forecast 59. 2001 China Optical Transmission Equipment Industry and Market: A Review & A Forecast 60. 2001 China IP Telephone Signal Converter Industry and Market: A Review & A Forecast 61. 2001 China Concentrator and Indicator Industry and Market: A Review & A Forecast 62. 2001 China Modem Industry and Market: A Review & A Forecast 63. 2001 China Facsimile Signal Sensor Industry and Market: A Review & A Forecast 64. 2001 China Walkie-Talkie Industry and Market: A Review & A Forecast 65. 2001 China Mobile Phone and Beeper Industry and Market: A Review & A Forecast 66. 2001 China Fibre-Optical Communication and Fibre-Optical Property tester Industry and Market: A Review & A Forecast 67. 2001 China Duplicator Industry and Market: A Review & A Forecast 68. 2001 China Mail Processor Industry and Market: A Review & A Forecast 69. 2001 China Paper-cutting Machine Industry and Market: A Review & A Forecast 70. 2001 China Auto Vending Machine Industry and Market: A Review & A Forecast 71. 2001 China Portal Electric Tool Industry and Market: A Review & A Forecast 72. 2001 China Sewing Machine Industry and Market: A Review & A Forecast 73. 2001 China Photo Enlarger and Reduction Printer Industry and Market: A Review & A Forecast 74. 2001 China Slide Projector Industry and Market: A Review & A Forecast 75. 2001 China Plotter Equipment Industry and Market: A Review & A Forecast 76. 2001 China Electric Lighting and Signal Equipment Industry and Market: A Review & A Forecast 77. 2001 China Electric Dry Oven and Heater Industry and Market: A Review & A Forecast 78. 2001 China Boarding Machine Industry and Market: A Review & A Forecast 79. 2001 China Traffic Control Equipment Industry and Market: A Review & A Forecast 80. 2001 China Warning Device Industry and Market: A Review & A Forecast 81. 2001 China Navigation Radio Facilities Industry and Market: A Review & A Forecast 82. 2001 China Metal-Mine detector Industry and Market: A Review & A Forecast 83. 2001 China Precipitator Industry and Market: A Review & A Forecast 84. 2001 China Injection Machine, Plastic Comminutor and Industry and Market: A Review & A Forecast 85. 2001 China Set Microscope Industry and Market: A Review & A Forecast 86. 2001 China Locating Compass Industry and Market: A Review & A Forecast 87. 2001 China rangefinder Industry and Market: A Review & A Forecast 88. 2001 China Barostat and Thermostat Industry and Market: A Review & A Forecast 89. 2001 China Machine Tools Industry and Market: A Review & A Forecast 90. 2001 China Automobile Equipment Industry and Market: A Review & A Forecast 91. 2001 China Medical Equipment Industry and Market: A Review & A Forecast 92. 2001 China Gasmeter, Watermeter and Eletrometer Industry and Market: A Review & A Forecast 93. 2001 China Odometer and Velograph Industry and Market: A Review & A Forecast 94. 2001 China Ammeter,Voltmeter and Multimeter Industry and Market: A Review & A Forecast 95. 2001 China OSC Industry and Market: A Review & A Forecast 96. 2001 China Resistance Tester Industry and Market: A Review & A Forecast Name: China Center of Information Industry Development(CCID) Microelectronics Reserch Department(MRD) Address£ºChina Semiconductor Industry Association.27,Rd.wanshoulu PC£º100846 Website£ºwww.ccid-mrd.com.cn EMAIL: guoyiran@ccid-mrd.com.cn NEWS@ccid-mrd.com.cn TEL: 86-10-68208592, 86-10-68208589 Fax: 86-10-68208590 , 86-10-68208594 Contact:¡¡Guo Yiran (¹ùÒãÈ») , Louisa Lv(ÂÀÕÜ) , Lydie Li(Àî°®»ª) --_========_000000182_========_ Content-Type: application/octet-stream; name="Information of China IC Market by CCID.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Information of China IC Market by CCID.htm" PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIg0K eG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCINCnhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVx dWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9R0IyMzEyIj4NCjxt ZXRhIG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9R2VuZXJh dG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDkiPg0KPG1ldGEgbmFtZT1PcmlnaW5hdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDkiPg0KPGxpbmsgcmVsPUZpbGUtTGlzdA0KaHJlZj0iLi9J bmZvcm1hdGlvbiUyMG9mJTIwQ2hpbmElMjBJQyUyME1hcmtldCUyMGJ5JTIwQ0NJRC5maWxlcy9m aWxlbGlzdC54bWwiPg0KPHRpdGxlPldFTENPTUUgVE8gT1JERVIgMjAwMiBDQ0lEIHNlbWljb25k dWN0b3IgUmVwb3J0czwvdGl0bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpEb2N1 bWVudFByb3BlcnRpZXM+DQogIDxvOkF1dGhvcj56ZW5nemhlbjwvbzpBdXRob3I+DQogIDxvOlRl bXBsYXRlPk5vcm1hbDwvbzpUZW1wbGF0ZT4NCiAgPG86TGFzdEF1dGhvcj5haWh1YTwvbzpMYXN0 QXV0aG9yPg0KICA8bzpSZXZpc2lvbj4yPC9vOlJldmlzaW9uPg0KICA8bzpUb3RhbFRpbWU+Mjwv bzpUb3RhbFRpbWU+DQogIDxvOkNyZWF0ZWQ+MjAwMi0wMi0yNVQwMToyMzowMFo8L286Q3JlYXRl ZD4NCiAgPG86TGFzdFNhdmVkPjIwMDItMDItMjVUMDE6MjM6MDBaPC9vOkxhc3RTYXZlZD4NCiAg PG86UGFnZXM+NTwvbzpQYWdlcz4NCiAgPG86V29yZHM+MTU0ODwvbzpXb3Jkcz4NCiAgPG86Q2hh cmFjdGVycz44ODI2PC9vOkNoYXJhY3RlcnM+DQogIDxvOkNvbXBhbnk+bXJkPC9vOkNvbXBhbnk+ DQogIDxvOkxpbmVzPjczPC9vOkxpbmVzPg0KICA8bzpQYXJhZ3JhcGhzPjE3PC9vOlBhcmFncmFw aHM+DQogIDxvOkNoYXJhY3RlcnNXaXRoU3BhY2VzPjEwODM4PC9vOkNoYXJhY3RlcnNXaXRoU3Bh Y2VzPg0KICA8bzpWZXJzaW9uPjkuMjgxMjwvbzpWZXJzaW9uPg0KIDwvbzpEb2N1bWVudFByb3Bl cnRpZXM+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpX b3JkRG9jdW1lbnQ+DQogIDx3OlB1bmN0dWF0aW9uS2VybmluZy8+DQogIDx3OkRyYXdpbmdHcmlk VmVydGljYWxTcGFjaW5nPjcuOCCw9TwvdzpEcmF3aW5nR3JpZFZlcnRpY2FsU3BhY2luZz4NCiAg PHc6RGlzcGxheUhvcml6b250YWxEcmF3aW5nR3JpZEV2ZXJ5PjA8L3c6RGlzcGxheUhvcml6b250 YWxEcmF3aW5nR3JpZEV2ZXJ5Pg0KICA8dzpEaXNwbGF5VmVydGljYWxEcmF3aW5nR3JpZEV2ZXJ5 PjI8L3c6RGlzcGxheVZlcnRpY2FsRHJhd2luZ0dyaWRFdmVyeT4NCiAgPHc6Q29tcGF0aWJpbGl0 eT4NCiAgIDx3OlNwYWNlRm9yVUwvPg0KICAgPHc6QmFsYW5jZVNpbmdsZUJ5dGVEb3VibGVCeXRl V2lkdGgvPg0KICAgPHc6RG9Ob3RMZWF2ZUJhY2tzbGFzaEFsb25lLz4NCiAgIDx3OlVMVHJhaWxT cGFjZS8+DQogICA8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCiAgIDx3OkFkanVzdExpbmVI ZWlnaHRJblRhYmxlLz4NCiAgIDx3OlVzZUZFTGF5b3V0Lz4NCiAgPC93OkNvbXBhdGliaWxpdHk+ DQogPC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6y87M5TsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWFsdDpTaW1TdW47DQoJ bXNvLWZvbnQtY2hhcnNldDoxMzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCglt c28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MyAxMzUxMzUyMzIg MTYgMCAyNjIxNDUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcMDAwQgwiOw0KCXBh bm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtYWx0OiJUaW1lcyBOZXcgUm9t YW4iOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpyb21h bjsNCgltc28tZm9udC1mb3JtYXQ6b3RoZXI7DQoJbXNvLWZvbnQtcGl0Y2g6YXV0bzsNCgltc28t Zm9udC1zaWduYXR1cmU6MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEDLzszlIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWNoYXJz ZXQ6MTM0Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6 dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjEgMTM1MTM1MjMyIDE2IDAgMjYyMTQ0IDA7 fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTpp bnRlci1pZGVvZ3JhcGg7DQoJbXNvLXBhZ2luYXRpb246bm9uZTsNCglmb250LXNpemU6MTAuNXB0 Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6y87M5TsNCgltc28tZm9udC1rZXJuaW5n OjEuMHB0O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6IzY2MDAwMDsNCglt c28tdGV4dC1hbmltYXRpb246bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZTsNCgl0ZXh0LXVu ZGVybGluZTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lOw0KCXRleHQtbGluZS10aHJvdWdo Om5vbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmds ZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlm eTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCW1zby1wYWdpbmF0aW9uOm5vbmU7 DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseTrLzszlOw0KCW1zby1oYW5zaS1mb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJbXNvLWZvbnQta2VybmluZzoxLjBwdDt9DQpwDQoJe21hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OsvOzOU7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KIC8qIFBhZ2UgRGVmaW5pdGlvbnMgKi8NCkBwYWdlDQoJe21zby1w YWdlLWJvcmRlci1zdXJyb3VuZC1oZWFkZXI6bm87DQoJbXNvLXBhZ2UtYm9yZGVyLXN1cnJvdW5k LWZvb3Rlcjpubzt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCglt YXJnaW46NzIuMHB0IDkwLjk1cHQgNzIuMHB0IDkwLjlwdDsNCgltc28taGVhZGVyLW1hcmdpbjo0 Mi41NXB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjQ5LjZwdDsNCgltc28tcGFwZXItc291cmNlOjA7 DQoJbGF5b3V0LWdyaWQ6MTUuNnB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30N Ci0tPg0KPC9zdHlsZT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1aSC1DTiBsaW5rPSIjNjYwMDAw IiB2bGluaz1wdXJwbGUgc3R5bGU9J3RhYi1pbnRlcnZhbDoyMS4wcHQ7DQp0ZXh0LWp1c3RpZnkt dHJpbTpwdW5jdHVhdGlvbic+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjEgc3R5bGU9J2xheW91dC1n cmlkOjE1LjZwdCc+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFz XT4mbmJzcDs8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGI+PHNwYW4N Cmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEw LjVwdDttc28taGFuc2ktZm9udC1mYW1pbHk6DQrLzszlO2NvbG9yOmJsdWUnPldFTENPTUUgVE8g T1JERVIgMjAwMiBDQ0lEIHNlbWljb25kdWN0b3IgUmVwb3J0czxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQt YWxpZ246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz6j qDxzcGFuIGxhbmc9RU4tVVM+Rm9yIG1vcmUgaW5mb3JtYXRpb24gcGxlYXNlDQp2aXNpdCBvdXIg d2Vic2l0ZSA8aT48c3BhbiBzdHlsZT0nY29sb3I6IzMzNjZGRic+PGENCmhyZWY9Imh0dHA6Ly93 d3cuY2NpZC1tcmQuY29tLmNuLyI+PHNwYW4gc3R5bGU9J2NvbG9yOiMzMzY2RkYnPldXVy5DQ0lE LU1SRC5DT00uQ048L3NwYW4+PC9hPjwvc3Bhbj48L2k+o6k8bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5i c3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4x LkENClJldmlldyBvZiAyMDAxIENoaW5hIElDIEluZHVzdHJ5ICZhbXA7IGEgRm9yZWNhc3Qgb24g MjAwMi0yMDA1PHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Mi5BDQpSZXZpZXcgb2Yg MjAwMSBDaGluYSBJQyBNYXJrZXQgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PHNwYW4NCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+My5Bbg0KQW5hbHlzaXMgb2YgMjAwMSBDaGlu YSBJQyBJbXBvcnRzIGFuZCBFeHBvcnRzICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz40LiBBDQpSZXZpZXcgb2Yg MjAwMSBDaGluYSBEaXNjcmV0ZSBEZXZpY2VzIEluZHVzdHJ5ICZhbXA7IEEgRm9yZWNhc3Qgb24g MjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41LiBB bg0KQW5hbHlzaXMgb2YgMjAwMSBDaGluYSBFeHBvcnQgJmFtcDsgSW1wb3J0IG9mIERpc2NyZXRl IERldmljZXMgJmFtcDsgQSBGb3JlY2FzdA0Kb24gMjAwMi0yMDA1PHNwYW4gc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz42LkENCnJldmlldyBvZiAyMDAxIGNoaW5hoa9zIElDIE1hcmtldCAoYnkg Q2F0YWxvZ3VlKSAmYW1wOyBhIGZvcmVjYXN0IG9uIDIwMDItMjAwNSA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Ny5BDQpSZXZpZXcgb2YgQ2hpbmEncyAyMDAxIENv bXB1dGVyIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21z by1oYW5zaS1mb250LWZhbWlseTrLzszlJz44LkENClJldmlldyBvZiAyMDAxIENoaW5hIENvbnN1 bWVyIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1o YW5zaS1mb250LWZhbWlseTrLzszlJz45LkENClJldmlldyBvZiAyMDAxIENoaW5hIFRlbGVjb21t dW5pY2F0aW9uIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xMC5BDQpSZXZpZXcgb2YgMjAwMSBDaGluYSBJ QyBDYXJkIGFuZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MTEuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hpbmEgTWVtb3J5IGFu ZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz4xMi5BDQpSZXZpZXcgb2YgMjAwMSBDaGluYSBBbmFsb2cgQ2lyY3VpdCBhbmQg YSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+MTMuQSBSZXZpZXcNCm9mIDIwMDEgQ2hpbmEgUG93ZXIgSUMgYW5kIGEgRm9yZWNh c3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjE0LkENClJldmlldyBvZiAyMDAxIENoaW5hIERTUCBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIw MDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTUuQQ0KUmV2aWV3 IG9mIDIwMDEgQ2hpbmEgTUNVIGFuZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xNi5BDQpSZXZpZXcgb2YgMjAwMSBDaGlu YSBQb3dlciBJQyBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28t aGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTcuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hpbmEgQUQvREEg YW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OsvOzOUnPjE4Lk1OQ3MNCkVsZWN0cm9uaWMgQ29ycG9yYXRpb25zIEluIENoaW5hOiBJ bnZlc3RtZW50LCBNYXJrZXRpbmcsIEFuZCBUcmVuZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2kt Zm9udC1mYW1pbHk6y87M5Sc+MTkuc2VtaWNvbmR1Y3Rvcg0KTU5DcyBpbiBjaGluYTogMjAwMiBF ZGl0aW9uIENoaW5lc2Ugb25seSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MzQuQQ0KU3VydmV5PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsg PC9zcGFuPm9mPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4y MDAxIENoaW5hIFNlbWljb25kdWN0b3IncyBkaXN0cmlidXRpb24NCm1hcmtldCA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MjAuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hp bmEgU2VtaWNvbmR1Y3RvciBFcXVpcG1lbnQgYW5kIEluc3RydW1lbnRzIGFuZCBhIEZvcmVjYXN0 IG9uDQoyMDAyLTIwMDUgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjIyLkENClJldmlldyBvZiAyMDAxIENoaW5hIEVsZWN0cm9uaWMgcHJvZHVjdHMgYW5kIGEgRm9y ZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjIzLkENClJldmlldyBvZiAyMDAxIENoaW5hIFNlbWljb25kdWN0b3IgSW5kdXN0cnkgU3Bl Y2lhbDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46DQp5ZXMiPiZuYnNwOyA8L3NwYW4+TWF0ZXJp YWxzICZhbXA7IEEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5z aS1mb250LWZhbWlseTrLzszlJz4yNC5BIFJldmlldw0Kb2YgMjAwMSBDaGluYSBTZW1pY29uZHVj dG9yIFBhY2thZ2luZyBtYXRlcmlhbHMgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI1LkENClJldmlldyBvZiAyMDAx IFdvcmxkIFNlbWljb25kdWN0b3IgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI2LlJlc2VhcmNoDQpvbiBDaGluYSBJ QyBJbmR1c3RyeSBQb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M 5Sc+MjcuMjAwMQ0KQ2hpbmEgSUMgSW5kdXN0cnkgQW5udWFsIFJlcG9ydKOoMjAwMiBFZGl0aW9u o6k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MzEuQ2hpbmENClNl bWljb25kdWN0b3IgSW5mb3JtYXRpb24gKCBvbmUgZWRpdGlvbiBwZXIgcXVhcnRlcik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MzMuMjAwMQ0KQ2hpbmEgU2VtaWNv bmR1Y3RvciBJbmR1c3RyeSBBc3NvY2lhdGlvbiAoQ1NJQSkgTWVtYmVyIERpcmVjdG9yeSA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MjEuQQ0KUmV2aWV3IG9mIDIw MDEgQ2hpbmEgTENEIGRldmljZSBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+PG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNp LWZvbnQtZmFtaWx5OsvOzOUnPjI5LkENClJldmlldyBvZiAyMDAxIENoaW5hIExFRCBkZXZpY2Ug YW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OsvOzOUnPjMwLkENClJldmlldyBvZiBDaGluYSBQQ0IgSW5kdXN0cnkgYW5kIG1hcmtl dCBhbmQgZm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjMyLkENClJldmlldyBvZiBDaGluYSBDb25uZWN0b3IgSW5kdXN0cnkgYW5kIG1hcmtldCBhbmQg Zm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjEuIDIw MDENCkNoaW5hIFNNVCBEZXZpY2UgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsg QSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Mi4g MjAwMQ0KQ2hpbmEgU01UIEVxdWlwbWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz4zLiAyMDAxDQpDaGluYSBVUFMgSW5kdXN0cnk6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3Qg PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjQuIDIwMDENCkNoaW5h IFRyYW5zZm9ybWVyLCBJbmR1Y3RvciBhbmQgQmFsbGFzdCBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+NS4gMjAwMQ0KQ2hpbmEgUHJpbWFyeSBCYXR0ZXJ5IGFuZCBTdG9yYWdlIEJh dHRlcnkgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjYuPHNwYW4NCnN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIFNwZWFrZXIgYW5kIEhl YWRwaG9uZQ0KSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Ny48c3Bhbg0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hpbmEgU3dpdGNoLCBQbHVn IGFuZCBPdXRsZXQNCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjguPHNwYW4NCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIE1hZ25ldGlj IEhlYWQgRGV2aWNlDQpJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45LiAyMDAxDQpD aGluYSBFbGV0cm9tYWduZXQgYW5kIFBlcm1hbmVudCBNYWduZXQgSW5kdXN0cnkgYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZv bnQtZmFtaWx5OsvOzOUnPjEwLg0KQ0NJRCBTZW1pY29uZHVjdG9yIEluZm9ybWF0aW9uo6hPbmUg RWRpdGlvbiBwZXIgdGhyZWUgbW9udGijqSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+MTEuIEENCnN1cnZleSBvZiAyMDAxIENoaW5hIFNwYXJraW5nIFBsdWcsIEln bml0aW9uIE1hZ25ldG9zIGFuZCBQZXJtYW5lbnQgREMNCkdlbmVyYXRvciA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTIuDQoyMDAxIENoaW5hIEJ1enplciBJbmR1 c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xMy4NCjIwMDEgQ2hpbmEgRWxlY3RyaWMgUmVs YXkgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTQuDQoyMDAxIENoaW5hIENhdGhv ZGUgUmF5IFR1YmUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTUuDQoyMDAxIENo aW5hIGluc3VsYXRlZCB3aXJlLCBjYWJsZSBhbmQgb3B0aWNhbCBjYWJsZSBJbmR1c3RyeSBhbmQg TWFya2V0OiBBDQpSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MTYuDQoyMDAxIENoaW5hIENhcmJvbiBFbGVjdHJvZGUgYW5k IEluc3VsYXRvciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTcuDQoyMDAxIENo aW5hIEZpbG0gQ2FtZXJhIGFuZCBQcm9qZWN0b3IgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZp ZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OsvOzOUnPjE4LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L3NwYW4+ MjAwMSBDaGluYSBFbGVjdHJpY2FsIEZhbiwgQWlyDQpDb25kaXRpb25pbmcgYW5kIERyeWVyIElu ZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjE5Lg0KMjAwMSBDaGluYSBBdXRvIFdhc2hp bmcgTWFjaGluZSBhbmQgQ2xvdGhlcyBEcnllciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dw0KJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MjAuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4y MDAxIENoaW5hIERpc2h3YXNoaW5nIE1hY2hpbmUNCihkb21lc3RpYyBob3VzZWhvbGQpIEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjIxLg0KMjAwMSBDaGluYSBFbGVjdHJpY2FsIFNj YWxlIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjIyLg0KMjAwMSBDaGluYSBFbWJy b2lkZXIgbWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4yMy4NCjIwMDEg Q2hpbmEgQ2FsY3VsYXRpbmcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz4yNC4NCjIwMDEgQ2hpbmEgRWxlY3Ryb25pYyBFcXVpcG1lbnQgZm9yIEtpdGNoZW4gSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsNCkEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI1Lg0KMjAwMSBDaGluYSBFbGVjdHJpYyBSYXpv ciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4yNi4NCjIwMDEgQ2hpbmEgV2F0ZXIg SGVhdGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI3Lg0KMjAwMSBDaGluYSBF bGVjdHJpY2FsIEhhaXIgRHJlc3NpbmcgVG9vbCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MjguDQoyMDAxIENoaW5hIEVsZWN0cmljIElyb24gSW5kdXN0cnkgYW5kIE1hcmtldDog QSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+MjkuDQoyMDAxIENoaW5hIFJhZGlvIFNldHMsIFRhcGUgUmVjb3JkZXIgYW5k IEF1ZGlvIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4zMC4NCjIwMDEgQ2hpbmEg VkYgTWVnYXBob25lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjMxLg0KMjAwMSBD aGluYSBTYXRlbGxpdGUgR3JvdW5kIFN0YXRpb24gZm9yIFRWIEluZHVzdHJ5IGFuZCBNYXJrZXQ6 IEEgUmV2aWV3ICZhbXA7DQpBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz4zMi4NCjIwMDEgQ2hpbmEgVkNEIGFuZCBEVkQgSW5kdXN0cnkgYW5kIE1h cmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2kt Zm9udC1mYW1pbHk6y87M5Sc+MzMuDQoyMDAxIENoaW5hIFNldCBUb3AgQm94IEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM0Lg0KMjAwMSBDaGluYSBUZWxlY2FtZXJhIEluZHVzdHJ5 IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNv LWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM1LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyA8L3NwYW4+MjAwMSBDaGluYSBUZWxldmlzaW9uIFNldCBJbmR1c3RyeSBhbmQN Ck1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MzYuDQoyMDAxIENoaW5hIENhbWVyYSBJbmR1c3RyeSBhbmQg TWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5z aS1mb250LWZhbWlseTrLzszlJz4zNy4NCjIwMDEgQ2hpbmEgQXVkaXBob25lIEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM4LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyA8L3NwYW4+MjAwMSBDaGluYSBFbGVjdHJpYyBXYXRjaCBhbmQgVGltZXINCkluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM5Lg0KMjAwMSBDaGluYSBNdXNpY2FsIEluc3Ry dW1lbnQgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NDAuDQoyMDAxIENoaW5hIFZp ZGVvIEdhbWUgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZv cmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz40MS4NCjIw MDEgQ2hpbmEgVGFwZSBhbmQgUmVjb3JkIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZh bXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjQyLg0KMjAwMSBDaGluYSBUb3lzIE1vdG9yIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3 ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjQzLg0KMjAwMSBDaGluYSBQcmludGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3 ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjQ0Lg0KMjAwMSBDaGluYSBDYXNoIFJlZ2lzdGVyIGFuZCBTYWxlcyBUZXJtaW5hbCBSZWdp c3RlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBDQpSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NDUuDQoyMDAxIENoaW5hIFBv c3RhZ2UgU3RhbXBlciBhbmQgQm9va2luZyBNYWNoaW5lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40Ni4NCjIwMDEgQ2hpbmEgRGlzcGxheSBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40Ny4NCjIwMDEgQ2hpbmEgU2Nhbm5lciBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40OC4NCjIwMDEgQ2hpbmEgS2V5Ym9hcmQgYW5kIE1vdXNlIEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjQ5Lg0KMjAwMSBDaGluYSBEaWdpdGFsIEVxdWlwbWVudCBJ bmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41MC4NCjIwMDEgQ2hpbmEgU3RvcmFnZSBC bG9jayBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41MS4NCjIwMDEgQ2hpbmEgSGFy ZHBhbiwgRmxvcHB5IERpc2MgYW5kIERyaXZlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOw0KQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+NTIuDQoyMDAxIENoaW5hIE1vbmV5LURyYXcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFy a2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1m b250LWZhbWlseTrLzszlJz41My4NCjIwMDEgQ2hpbmEgVm9sdGFnZS1zdGFiaWxpemVkIFNvdXJj ZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NTQuDQoyMDAxIENoaW5hIERpc2Mg YW5kIE1hZ25ldGljIENhcmQgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0K Rm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjU1Lg0K MjAwMSBDaGluYSBDb21wdXRlciBTb2Z0d2FyZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrL zszlJz41Ni4NCjIwMDEgQ2hpbmEgVGVsZXBob25lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2 aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OsvOzOUnPjU3Lg0KMjAwMSBDaGluYSBGQVggSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcg JmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M 5Sc+NTguDQoyMDAxIENoaW5hIFByb2dyYW0tQ29udHJvbGxlZCBFeGNoYW5nZSBJbmR1c3RyeSBh bmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28t aGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NTkuDQoyMDAxIENoaW5hIE9wdGljYWwgVHJhbnNtaXNz aW9uIEVxdWlwbWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3Jl Y2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NjAuPHNwYW4N CnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIElQIFRl bGVwaG9uZSBTaWduYWwgQ29udmVydGVyDQpJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz42MS48c3Bhbg0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEg Q2hpbmEgQ29uY2VudHJhdG9yIGFuZCBJbmRpY2F0b3INCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFt aWx5OsvOzOUnPjYyLg0KMjAwMSBDaGluYSBNb2RlbSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWls eTrLzszlJz42My4NCjIwMDEgQ2hpbmEgRmFjc2ltaWxlIFNpZ25hbCBTZW5zb3IgSW5kdXN0cnkg YW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNv LWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY0Lg0KMjAwMSBDaGluYSBXYWxraWUtVGFsa2llIElu ZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY1Lg0KMjAwMSBDaGluYSBNb2JpbGUgUGhv bmUgYW5kIEJlZXBlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3Jl Y2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NjYuDQoyMDAx IENoaW5hIEZpYnJlLU9wdGljYWwgQ29tbXVuaWNhdGlvbiBhbmQgRmlicmUtT3B0aWNhbCBQcm9w ZXJ0eSB0ZXN0ZXINCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY3Lg0KMjAwMSBD aGluYSBEdXBsaWNhdG9yIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY4Lg0KMjAw MSBDaGluYSBNYWlsIFByb2Nlc3NvciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1w OyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz42 OS4NCjIwMDEgQ2hpbmEgUGFwZXItY3V0dGluZyBNYWNoaW5lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6 IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz43MC4NCjIwMDEgQ2hpbmEgQXV0byBWZW5kaW5nIE1hY2hpbmUgSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NzEuDQoyMDAxIENoaW5hIFBvcnRhbCBFbGVjdHJp YyBUb29sIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjcyLg0KMjAwMSBDaGluYSBT ZXdpbmcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz43My48c3Bhbg0K c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hpbmEgUGhvdG8g RW5sYXJnZXIgYW5kIFJlZHVjdGlvbg0KUHJpbnRlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWls eTrLzszlJz43NC4NCjIwMDEgQ2hpbmEgU2xpZGUgUHJvamVjdG9yIEluZHVzdHJ5IGFuZCBNYXJr ZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZv bnQtZmFtaWx5OsvOzOUnPjc1LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L3NwYW4+MjAwMSBDaGluYSBQbG90dGVyIEVxdWlwbWVudCBJbmR1c3RyeQ0KYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9u dC1mYW1pbHk6y87M5Sc+NzYuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 IDwvc3Bhbj4yMDAxIENoaW5hIEVsZWN0cmljIExpZ2h0aW5nIGFuZCBTaWduYWwNCkVxdWlwbWVu dCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz43Ny4NCjIwMDEgQ2hpbmEgRWxlY3Ry aWMgRHJ5IE92ZW4gYW5kIEhlYXRlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1w OyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ NzguDQoyMDAxIENoaW5hIEJvYXJkaW5nIE1hY2hpbmUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBS ZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+NzkuDQoyMDAxIENoaW5hIFRyYWZmaWMgQ29udHJvbCBFcXVpcG1lbnQgSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjgwLg0KMjAwMSBDaGluYSBXYXJuaW5nIERldmlj ZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44MS4NCjIwMDEgQ2hpbmEgTmF2aWdh dGlvbiBSYWRpbyBGYWNpbGl0aWVzIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7 IEENCkZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44 Mi48c3Bhbg0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hp bmEgTWV0YWwtTWluZSBkZXRlY3RvciBJbmR1c3RyeQ0KYW5kIE1hcmtldDogQSBSZXZpZXcgJmFt cDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ ODMuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENo aW5hIFByZWNpcGl0YXRvciBJbmR1c3RyeSBhbmQNCk1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBG b3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODQuDQoy MDAxIENoaW5hIEluamVjdGlvbiBNYWNoaW5lLCBQbGFzdGljIENvbW1pbnV0b3IgYW5kIEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEENClJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44NS4NCjIwMDEgQ2hpbmEgU2V0IE1pY3Jvc2Nv cGUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODYuDQoyMDAxIENoaW5hIExvY2F0 aW5nIENvbXBhc3MgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODcuDQoyMDAxIENo aW5hIHJhbmdlZmluZGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjg4Lg0KMjAw MSBDaGluYSBCYXJvc3RhdCBhbmQgVGhlcm1vc3RhdCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+ODkuDQoyMDAxIENoaW5hIE1hY2hpbmUgVG9vbHMgSW5kdXN0cnkgYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9u dC1mYW1pbHk6y87M5Sc+OTAuDQoyMDAxIENoaW5hIEF1dG9tb2JpbGUgRXF1aXBtZW50IEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjkxLg0KMjAwMSBDaGluYSBNZWRpY2FsIEVxdWlw bWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45Mi4NCjIwMDEgQ2hpbmEgR2Fz bWV0ZXIsIFdhdGVybWV0ZXIgYW5kIEVsZXRyb21ldGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz45My4NCjIwMDEgQ2hpbmEgT2RvbWV0ZXIgYW5kIFZlbG9ncmFwaCBJbmR1c3Ry eSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+OTQuDQoyMDAxIENoaW5hIEFtbWV0ZXIsVm9sdG1l dGVyIGFuZCBNdWx0aW1ldGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6PHNwYW4NCnN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5BIFJldmlldyAmYW1wOyBB IEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45NS4N CjIwMDEgQ2hpbmEgT1NDIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjk2Lg0KMjAw MSBDaGluYSBSZXNpc3RhbmNlIFRlc3RlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8 IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlm XT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tdG9wOjBjbTttYXJn aW4tcmlnaHQ6MzAuMHB0O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0Og0KMTUuMHB0O21h cmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDoxNy4yNXB0O2xpbmUtaGVpZ2h0OjE1MCUn PjxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJc MDAwQgwiO2NvbG9yOm5hdnknPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5k aWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21hcmdpbi10b3A6MGNtO21h cmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6DQoxNS4wcHQ7 bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7bGluZS1oZWlnaHQ6MTUw JSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlwwMDBCDCI7Y29sb3I6bmF2eSc+TmFtZTogQzwvc3Bhbj48c3Bhbg0KbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjpu YXZ5Jz5oaW5hDQpDZW50ZXIgb2YgSW5mb3JtYXRpb24gSW5kdXN0cnkgRGV2ZWxvcG1lbnQoPC9z cGFuPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJcMDAwQgwiO2NvbG9yOm5hdnknPkNDSUQpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBz dHlsZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz48c3Bhbg0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFu DQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvc3Bhbj5NaWNyb2VsZWN0cm9uaWNz IFJlc2VyY2ggRGVwYXJ0bWVudChNUkQpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHls ZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTtt YXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcu MjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5BZGRyZXNzPC9zcGFuPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYXNjaWktZm9udC1mYW1pbHk6IlwwMDBC DCI7bXNvLWhhbnNpLWZvbnQtZmFtaWx5Og0KIlwwMDBCDCI7Y29sb3I6bmF2eSc+o7o8L3NwYW4+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJc MDAwQgwiO2NvbG9yOm5hdnknPkNoaW5hIFNlbWljb25kdWN0b3IgSW5kdXN0cnkNCkFzc29jaWF0 aW9uLjI3LFJkLndhbnNob3VsdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21h cmdpbi10b3A6MGNtO21hcmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2lu LWxlZnQ6DQoxNS4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7 bGluZS1oZWlnaHQ6MTUwJSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2eSc+UEM8L3NwYW4+PHNwYW4NCnN0eWxl PSdmb250LXNpemU6MTAuMHB0O21zby1hc2NpaS1mb250LWZhbWlseToiXDAwMEIMIjttc28taGFu c2ktZm9udC1mYW1pbHk6DQoiXDAwMEIMIjtjb2xvcjpuYXZ5Jz6jujwvc3Bhbj48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29s b3I6bmF2eSc+MTAwODQ2PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2lu LXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVm dDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcuMjVwdDtsaW5l LWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5XZWJzaXRlPC9zcGFuPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdDttc28tYXNjaWktZm9udC1mYW1pbHk6IlwwMDBCDCI7bXNvLWhh bnNpLWZvbnQtZmFtaWx5Og0KIlwwMDBCDCI7Y29sb3I6bmF2eSc+o7o8L3NwYW4+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmNvbG9yOm5hdnknPjxhIGhyZWY9Imh0 dHA6Ly93d3cuY2NpZC1tcmQuY29tLmNuLyI+d3d3LmNjaWQtbXJkLmNvbS5jbjwvYT48L3NwYW4+ PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7Y29sb3I6bmF2eSc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBz dHlsZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5FTUFJTDogPGENCmhy ZWY9Im1haWx0bzpndW95aXJhbkBjY2lkLW1yZC5jb20uY24iPmd1b3lpcmFuQGNjaWQtbXJkLmNv bS5jbjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tdG9wOjBj bTttYXJnaW4tcmlnaHQ6MzAuMHB0O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0Og0KMGNt O21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDoxNTAlJz48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2 eSc+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoNCnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YQ0K aHJlZj0ibWFpbHRvOk5FV1NAY2NpZC1tcmQuY29tLmNuIj5ORVdTQGNjaWQtbXJkLmNvbS5jbjwv YT48L3NwYW4+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OiJcMDAwQgwiO2Nv bG9yOiM2NjMzMDAnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21hcmdpbi10 b3A6MGNtO21hcmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6 DQoxNS4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7bGluZS1o ZWlnaHQ6MTUwJSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2eSc+VEVMOjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyA8L3NwYW4+ODYtMTAtNjgyMDg1OTIsPHNwYW4NCnN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU4OSZuYnNwOzwvc3Bhbj48 c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMw MCc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2luLXRvcDowY207bWFy Z2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDoNCjE1LjBwdDtt YXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAl Jz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi XDAwMEIMIjtjb2xvcjpuYXZ5Jz5GYXg6PHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU5MCAsPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU5NDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVT DQpzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMwMCc+PG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9J3RleHQtaW5kZW50OjMx LjVwdDttc28tY2hhci1pbmRlbnQtY291bnQ6My4wOw0KbXNvLWNoYXItaW5kZW50LXNpemU6MTAu NXB0Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseToiXDAwMEIMIjsNCmNvbG9y OiMzMzY2RkYnPkNvbnRhY3Q6PC9zcGFuPjxzcGFuIHN0eWxlPSdtc28tYXNjaWktZm9udC1mYW1p bHk6IlwwMDBCDCI7DQptc28taGFuc2ktZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzMzNjZG Ric+oaE8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtZmFtaWx5OiJcMDAwQgwi O2NvbG9yOiM2NjMzMDAnPkd1bzxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46DQp5ZXMiPiZuYnNw OyA8L3NwYW4+WWlyYW4gKDwvc3Bhbj48c3BhbiBzdHlsZT0nbXNvLWFzY2lpLWZvbnQtZmFtaWx5 OiJcMDAwQgwiOw0KbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiJcMDAwQgwiO2NvbG9yOiM2NjMzMDAn Prn50uPIuzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBC DCI7Y29sb3I6IzY2MzMwMCc+KSAsPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoNCnllcyI+Jm5i c3A7IDwvc3Bhbj5Mb3Vpc2EgTHYoPC9zcGFuPjxzcGFuIHN0eWxlPSdtc28tYXNjaWktZm9udC1m YW1pbHk6IlwwMDBCDCI7DQptc28taGFuc2ktZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2 MzMwMCc+wsDV3Dwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1mYW1pbHk6Ilww MDBCDCI7Y29sb3I6IzY2MzMwMCc+KSAsIDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0n Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCmNvbG9yOiM2NjMzMDAnPkx5ZGllIExpKDwvc3Bhbj48c3BhbiBzdHlsZT0nbXNv LWFzY2lpLWZvbnQtZmFtaWx5OiJcMDAwQgwiOw0KbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiJcMDAw QgwiO2NvbG9yOiM2NjMzMDAnPsDusK67qjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0n Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMwMCc+KTwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_========_000000182_========_ From cyeoh@samba.org Wed Feb 27 05:20:40 2002 From: cyeoh@samba.org (Christopher Yeoh) Date: Wed, 27 Feb 2002 16:20:40 +1100 Subject: Extra symbols required Message-ID: <15484.27816.486875.32816@gargle.gargle.HOWL> The following symbols aren't in the LSB specification, but "bad things" (strange behaviour or segfaults) happen to some binaries if they are not present in the stub libraries (although programs still link ok). If these symbols aren't included in the shared libraries they instead appear in the static portion of the binary as just undefined symbols. Interestingly lsbappchk doesn't pick these up (I'm not sure why yet). _IO_stdin_used __cxa_finalize __deregister_frame_info __register_frame_info So I think we need to add the above to the LSB specification. Regards, Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From pthomas@suse.de Wed Feb 27 11:23:56 2002 From: pthomas@suse.de (Philipp Thomas) Date: Wed, 27 Feb 2002 12:23:56 +0100 Subject: Extra symbols required In-Reply-To: <15484.27816.486875.32816@gargle.gargle.HOWL>; from cyeoh@samba.org on Wed, Feb 27, 2002 at 04:20:40PM +1100 References: <15484.27816.486875.32816@gargle.gargle.HOWL> Message-ID: <20020227122356.F12207@jeffreys.suse.de> * Christopher Yeoh (cyeoh@samba.org) [20020227 06:24]: > __deregister_frame_info > __register_frame_info > > So I think we need to add the above to the LSB specification. These come from libgcc and are needed for exception handling. Current glibc imports them from libgcc and then reexports them again. With the upcoming gcc 3.1 and sufficiently recent binutils, gcc uses the special ELF header PT_GNU_EH_FRAME so no extra functions for registering/deregistering eh frame info are needed anymore. Given the above, I'm not sure if LSB should add them. Philipp -- Philipp Thomas Development, SuSE Linux AG, Deutscherrnstr. 15-19, D-90429 Nuremberg, Germany From cyeoh@samba.org Thu Feb 28 05:00:44 2002 From: cyeoh@samba.org (Christopher Yeoh) Date: Thu, 28 Feb 2002 16:00:44 +1100 Subject: Extra symbols required In-Reply-To: <20020227122356.F12207@jeffreys.suse.de> References: <15484.27816.486875.32816@gargle.gargle.HOWL> <20020227122356.F12207@jeffreys.suse.de> Message-ID: <15485.47484.601965.141668@gargle.gargle.HOWL> At 2002/2/27 12:23+0100 Philipp Thomas writes: > * Christopher Yeoh (cyeoh@samba.org) [20020227 06:24]: > > > __deregister_frame_info > > __register_frame_info > > > > So I think we need to add the above to the LSB specification. > > These come from libgcc and are needed for exception handling. Current glibc > imports them from libgcc and then reexports them again. Are these only needed for C++ exceptions? If so then we can happily drop them since C++ isn't in the spec yet. Regards, Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From shockwave@tlh.com.ar Thu Feb 28 12:20:37 2002 From: shockwave@tlh.com.ar (shockwave) Date: Thu, 28 Feb 2002 04:20:37 -0800 Subject: unsubscribe Message-ID: <023801c1c055$9a5ca300$89b30dd1@hard> This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C1C00F.45D4C920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0049_01C1C00F.45D4C920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
    ------=_NextPart_000_0049_01C1C00F.45D4C920-- From shockwave@tlh.com.ar Thu Feb 28 12:20:42 2002 From: shockwave@tlh.com.ar (shockwave) Date: Thu, 28 Feb 2002 04:20:42 -0800 Subject: No subject Message-ID: <023901c1c055$9ba32cc0$89b30dd1@hard> This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C1C00F.494537C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe ------=_NextPart_000_0051_01C1C00F.494537C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    unsubscribe
     
    ------=_NextPart_000_0051_01C1C00F.494537C0-- From pthomas@suse.de Thu Feb 28 10:14:00 2002 From: pthomas@suse.de (Philipp Thomas) Date: Thu, 28 Feb 2002 11:14:00 +0100 Subject: Extra symbols required In-Reply-To: <15485.47484.601965.141668@gargle.gargle.HOWL>; from cyeoh@samba.org on Thu, Feb 28, 2002 at 04:00:44PM +1100 References: <15484.27816.486875.32816@gargle.gargle.HOWL> <20020227122356.F12207@jeffreys.suse.de> <15485.47484.601965.141668@gargle.gargle.HOWL> Message-ID: <20020228111400.K12207@jeffreys.suse.de> * Christopher Yeoh (cyeoh@samba.org) [20020228 06:45]: > Are these only needed for C++ exceptions? Yes, that's the case. The only reason they're present in C libraries is that these must be compiled with -fexeptions if C++ code wants to throw through C code. Philipp -- Philipp Thomas SuSE Linux AG, Deutscherrnstr. 15-19, D-90429 Nuremberg, Germany From hk67hk89@yahoo.com Sun Feb 3 20:34:04 2002 From: hk67hk89@yahoo.com (hk67hk89@yahoo.com) Date: Sun, 03 Feb 2002 12:34:04 -0800 Subject: . 1198 Message-ID: <0000022a6be4$00001fce$000004ae@>




     
     
    YOU SAVE
    20% to 50%
    ON YOUR
    PHONE BILL
    EACH MONTH!
    		  
    . . . and we'll donate 5% of your monthly phone bill
    to t= he charity of your choice!
  • NO Monthly Service Charge!
  • NO Installation Fees!
  • Billed in 6 Second Increments!
  • O= nly 6.9=FFFFFFA2 Per Minute Interstate 24 Hours / 7 Days a Week!

    SAVE 20% to 50%
    on Your Phone Bill Each Mon= th!

    Click here to view and print form

    <= FONT color=3D#000000 face=3DArial size=3D2>NOTE: After the form loads o= n your screen, simply click the "print" button on your browser, fill out = the form and fax to 1-800-377-2125.

    		•



    1. No monthly service charge and no installation fees (s= avings $3.95 - $8.95 per month)
    2. Charges 6 second increments, not 60 seconds (savings = on average of 27 seconds billing on every call)
    3. Low intrastate rates (saving you money on expensive c= alls within your own state)
    4. Rates are the same every day and every hour - 6.9=FF= FFFFA2! (saving you on expensive day rates of up to 25 cents per minute)=
    5. Add Toll free "800" service to existing lines or cell= phones at no additional installation charge or monthly fees and = only 6.9=FFFFFFA2 per minute interstate.
    6. Calling cards are available (16.5=FFFFFFA2 per minute= , 6-second increment billing) with no NBS surcharges for your calls and no = charge for the card(s).
    Sound too good to be true? Wel= l, it's not . . . it's true!

    The bottom line: AT&T, Sprint, MCI/Worldcom bills will be higher when all the charges are= added. You can easily save $100, $200, or more per year on your lo= ng distance bills, depending on your calling habits.

    Click here to view and print form

    <= FONT color=3D#000000 face=3DArial size=3D2>NOTE: After the form loads o= n your screen, simply click the "print" button on your browser, fill out = the form and fax to 1-800-377-2125. (Federal regulations requir= e your signature.)

    5% of your mont= hly phone bill goes to help and support the following charitable organizations:

    • Make a Wish Foundation
    • St. Judes Children's Hospital
    • The Miracle Network
    • Compassion International
    • or the charity of YOUR choice!


    Ask for your toll free number(s) on the form.
    Get a calling card if you wish.
    Don't wait, just do it today.
    You'll be glad you did!

    If you would like to be removed, please email us back with the = word "Remove" in the subject line. We apologize for any inc= onvenience.
     

    Premier Long Distance Network - A phone company that makes CENTS= !

    From phil@ipal.net Sun Feb 3 13:37:54 2002 From: phil@ipal.net (Phil Howard) Date: Sun, 3 Feb 2002 07:37:54 -0600 (CST) Subject: broken links in LSB 1.1.0 Message-ID: <20020203133754.8F7D9250@vega.ipal.net> The following links referenced in the Introduction page: http://developer.intel.com/design/itanium/downloads/24531702 http://developer.intel.com/design/itanium/downloads/24531802 http://developer.intel.com/design/itanium/downloads/24531902 http://developer.intel.com/design/itanium/downloads/24532002 http://developer.intel.com/design/ia-64/downloads/245358.htm do not work. Has Intel re-organized? [please reply direct or cc: me if you want me to see it, as I am not subscribed to the list] -- Phil Howard phil@ipal.net From nick@usenix.org Sun Feb 3 18:48:25 2002 From: nick@usenix.org (Nick Stoughton) Date: Sun, 3 Feb 2002 10:48:25 -0800 Subject: broken links in LSB 1.1.0 References: <20020203133754.8F7D9250@vega.ipal.net> Message-ID: <004901c1ace3$5cdc4e20$6601a8c0@nick.stoughton.name> Yes .. there are two problems here; the first is that the names got truncated, the second is that even then, intel moved them all. The correct links are now in the database (Stuart, can you confirm?), and should be: IA64 SDM Vol1: Itanium Architecture Software Developer's Manual Volume 1: Application Architecture http://developer.intel.com/design/itanium/downloads/24531703s.htm IA64 SDM Vol2: Itanium Architecture Software Developer's Manual Volume 2: System Architecture http://developer.intel.com/design/itanium/downloads/24531803s.htm IA64 SDM Vol3: Itanium Architecture Software Developer's Manual Volume 3: Instruction Set Reference http://developer.intel.com/design/itanium/downloads/24531903s.htm IA64 Processor Reference: Intel Itanium Processor Reference Manual for Software Development http://developer.intel.com/design/itanium/downloads/24532003s.htm IA64 ABI: Intel Itanium Processor-specific Application Binary Interface http://developer.intel.com/design/itanium/downloads/245370.htm IA64 Software Conventions: Itanium Software Conventions and Runtime Architecture Guide http://www.intel.com/design/itanium/downloads/24535803s.htm -- Nick Stoughton ----- Original Message ----- From: "Phil Howard" To: Sent: Sunday, February 03, 2002 5:37 AM Subject: broken links in LSB 1.1.0 > The following links referenced in the Introduction page: > > http://developer.intel.com/design/itanium/downloads/24531702 > http://developer.intel.com/design/itanium/downloads/24531802 > http://developer.intel.com/design/itanium/downloads/24531902 > http://developer.intel.com/design/itanium/downloads/24532002 > http://developer.intel.com/design/ia-64/downloads/245358.htm > > do not work. Has Intel re-organized? > > [please reply direct or cc: me if you want me to see it, as > I am not subscribed to the list] > > -- > Phil Howard > phil@ipal.net > > > -- > To UNSUBSCRIBE, email to lsb-spec-request@lists.linuxbase.org > with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org > From anderson@metrolink.com Sun Feb 3 22:17:38 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Sun, 3 Feb 2002 17:17:38 -0500 (EST) Subject: broken links in LSB 1.1.0 In-Reply-To: <004901c1ace3$5cdc4e20$6601a8c0@nick.stoughton.name> Message-ID: <20020203171656.S457-100000@trantor.sc.metrolink.com> On Sun, 3 Feb 2002, Nick Stoughton wrote: > Yes .. there are two problems here; the first is that the names got > truncated, the second is that even then, intel moved them all. The correct > links are now in the database (Stuart, can you confirm?), and should be: Yes, they should be there (and I'll double check anyway). End of last week, cvs on sourceforge was stuck, so I wasn't able to crank out the new version of the document with these fixed in it. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From cmprn111169@gm20.com Tue Feb 5 07:25:01 2002 From: cmprn111169@gm20.com (marketing@aboutjcmorris.com) Date: Tue, 5 Feb 2002 02:25:01 -0500 (EST) Subject: Company Merger Message-ID: <235773.1012893901005.Kada.Kada1(pc-72)@email2.gm20.com> ------=_Part_194950_6565857.1012893901005 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable YOU ARE RECEIVING THIS EMAIL BECAUSE YOU HAVE EXPRESSED INTEREST IN PRODUCT= S THAT WE CAN SAVE YOU MONEY ON. IF YOU WOULD LIKE TO BE REMOVED FROM OUR = MAILING LIST PLEASE CLICK THE UNSUBSCRIBE LINK AT THE BOTTOM OF THIS EMAIL.= WE CAN ASSURE YOU THAT YOU WILL BE REMOVED IMMEDIATELY. =09=09 IImportant Announcement from J.C. Morris & Company =09=09=09=09=09=09=09=09=09=09=09=09=09=09 For the past few years, our customers have enjoyed the ability to purchase = computers and related products from manufacturers like Sony, Apple, IBM, To= shiba and Compaq at prices below wholesale. Now, J.C. Morris & Company has teamed up with an additional distributor, Al= lied Interactive Micro-Systems, a company that specializes in the world-wid= e distribution of computer hardware, software and electronics, from manufac= turers like Bose, Pioneer and Canon. Here=92s your chance to get to know us, and from now until February 10, 200= 2 if you visit us on-line or in person and make a purchase, we will give yo= u an additional 25% off our current price. This is our way of saying thank= you for taking the time to visit our company. Sincerely, Jim Morris Vice President J.C. Morris & Company http://gm12.com/r.html?c=3D111249&r=3D111169&t=3D17546990&l=3D1&d=3D8169973= &u=3Dhttp://www.aboutjcmorris.com =09=09 Apple iMac $899.95 =09=09 http://gm12.com/r.html?c=3D111249&r=3D111169&t=3D17546990&l=3D1&d=3D8169973= &u=3Dhttp://www.aboutjcmorris.com =09=09 Tower Place Center Suite 1800, 3340 Peachtree Road NE Atlanta, GA 30326 1-800-845-6215 Click here: mailto:cmprn111169@gm20.com?subject=3Dunsubscribe!lsb-spec@list= s.linuxbase.org!17546990 to unsubscribe from our mailing list. Or reply to= this message with the word unsubscribe in the subject line. ------=_Part_194950_6565857.1012893901005 Content-Type: text/html Content-Transfer-Encoding: quoted-printable =09=09=09=09=09=09eNewsletter 2=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09
    For the past few years, our customers have enjoyed the ability to purchase= computers and related products from manufacturers like Sony, Apple, IBM, T= oshiba and Compaq at prices below wholesale.

    Now, J.C. Morris & Comp= any has teamed up with an additional distributor, Allied Interactive Micro-= Systems, a company that specializes in the world-wide distribution of compu= ter hardware, software and electronics, from manufacturers like Bose, Pione= er and Canon.

    Here=92s your chance to get to know us, and from now u= ntil February 10, 2002 if you visit us on-line or in person and make a purc= hase, we will give you an additional 25% off our current price. This is ou= r way of saying thank you for taking the time to visit our company.

    = Sincerely,
    Jim Morris
    Vice President
    J.C. Morris & Company
    Come visit us today!

    =

    =09=09=09=09=09=09=09=09

    =09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09=09

    YOU ARE RECEIVING THIS EMAIL BECAUSE YOU HAVE EXPRESSED INTEREST IN PRODUC= TS THAT WE CAN SAVE YOU MONEY ON. IF YOU WOULD LIKE TO BE REMOVED FROM OUR= MAILING LIST PLEASE CLICK THE UNSUBSCRIBE LINK AT THE BOTTOM OF THIS EMAIL= . WE CAN ASSURE YOU THAT YOU WILL BE REMOVED IMMEDIATELY.
    <= /font>=09=09
    IImportant Announcement from J.C. Morris & Compa= ny=09=09
    =09=09=09=09
    =09=09=09=093D""= =09=09=09=09
    =09=09=09=09=09=09=09=09

    =09=09=09=09=09=09=09=09
    =09= =09=09=09=09=09=09=09

    =09=09=09=09=09=09=09=09
    =09=09=09=09=09=09=09= =09

    =09=09=09=09=09=09=09=09
    =09=09=09=09=09=09=09=09

    =09=09=09=09= =09=09=09=09
    =09=09=09=09=09=09

    =09=09=09    		=09=09=09=09
    =09=09

    =09= =09=09=09
    =09=09=09=09

    =09=09=09=09


    Apple iMac

    $899.95

    =09=09=09=09=09

    =09=09=09=09
    Visit our Company on-line!=09=09=09=09
    Tower Place Center Suite 1800, 3340 Peach= tree Road NE

    Atlanta, GA 30326

    1-800-845-6215
    =
    =09=09
    =09=09=09=09

    Click here to unsubscribe from our mailing list. = Or reply to this message with the word unsubscribe in the subject line.


    ------=_Part_194950_6565857.1012893901005-- From mats.d.wichmann@intel.com Tue Feb 5 17:58:23 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Tue, 5 Feb 2002 09:58:23 -0800 Subject: CVS problems Message-ID: <39B5C4829263D411AA93009027AE9EBB15A71324@FMSMSX35> I'm having trouble syncing up with the CVS repository for about a week now. I know there's been some stuff committed in that time that I'd like to pick up. The problem is that as the update gets to the IA64/sgmlspec directory it hangs trying to get a lock: cvs server:[..date..] waiting for anoncvs_lsb's lock in /cvsroot/lsb/spec/archLSB/IA64/sgmlspec Anyway to unstick this? Thanks, Mats From anderson@metrolink.com Tue Feb 5 18:06:19 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Tue, 5 Feb 2002 13:06:19 -0500 (EST) Subject: CVS problems In-Reply-To: <39B5C4829263D411AA93009027AE9EBB15A71324@FMSMSX35> Message-ID: <20020205130445.Y457-100000@trantor.sc.metrolink.com> On Tue, 5 Feb 2002, Wichmann, Mats D wrote: > I'm having trouble syncing up with the CVS repository > for about a week now. > > I know there's been some stuff committed in that time > that I'd like to pick up. > > The problem is that as the update gets to the > IA64/sgmlspec directory it hangs trying to get a lock: > > cvs server:[..date..] waiting for anoncvs_lsb's lock in > /cvsroot/lsb/spec/archLSB/IA64/sgmlspec > > > Anyway to unstick this? I went to put in a support request for sourceforge to get this cleared, but I can no longer find the form that goes to them. If anyone knows where to find the support stuff that used to be there, please point it out. As a work-arund, remove the sgmlspec directory from your local tree. We aren't really using it anyway, and that way, this part gets skipped over, as long as you don't use '-d'. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From mats.d.wichmann@intel.com Thu Feb 7 16:37:57 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Thu, 7 Feb 2002 08:37:57 -0800 Subject: Spec: table layout gripe Message-ID: <39B5C4829263D411AA93009027AE9EBB15A71A86@FMSMSX35> I'm finding the library interface tables in the LSB spec terribly hard to read. The main problem is that they're formatted down, rather than accross, and some of the tables are big enough not to fit in a single browser window, nor on the printed page - you have to keep scrolling up and down or flipping pages just to look for a name. Does anyone else agree? If so, is it possible to look into having the tools spitting out the tables formatted across the page instead? Mats From anderson@metrolink.com Thu Feb 7 17:31:10 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Thu, 7 Feb 2002 12:31:10 -0500 (EST) Subject: Spec: table layout gripe In-Reply-To: <39B5C4829263D411AA93009027AE9EBB15A71A86@FMSMSX35> Message-ID: <20020207123047.R444-100000@trantor.sc.metrolink.com> On Thu, 7 Feb 2002, Wichmann, Mats D wrote: > If so, is it possible to look into having the tools spitting out the tables > formatted > across the page instead? Sure, that's possible. I did them vertically since the prior art was also done that way. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From mats.d.wichmann@intel.com Thu Feb 7 20:07:43 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Thu, 7 Feb 2002 12:07:43 -0800 Subject: confused by stdarg.h Message-ID: <39B5C4829263D411AA93009027AE9EBB15A71B94@FMSMSX35> My effort to compile using LSB headers launched me into a relatively thorough review of the headers and to file a bunch of bugs. Review / comment probably wouldn't hurt from some folks other than Stuart. Anyway, I have a question. What should be the spec stance with respect to headers that are provided by gcc. Several lsb headers use va_list, for example. va_list is not defined in any lsb header file, however there is a header that's supplied by gcc in the gcc-lib directory tree. In fact, I got here originally because I was having some conflicting defines where the lsb headers said something slightly different than the gcc-supplied stuff. Should the spec be "self-contained" or is it okay to depend on some things called out in the spec to actually be defined by gcc's own header files? Mats Wichmann From mats.d.wichmann@intel.com Fri Feb 8 18:22:13 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Fri, 8 Feb 2002 10:22:13 -0800 Subject: NSIG Message-ID: <39B5C4829263D411AA93009027AE9EBB15A71E88@FMSMSX35> Is NSIG supposed to be defined? The spec mentions it, in the context of this definition: extern const char *const _sys_siglist[NSIG]; NSIG itself is nowhere defined. Mats From gk4@austin.ibm.com Thu Feb 14 22:32:50 2002 From: gk4@austin.ibm.com (George Kraft IV) Date: Thu, 14 Feb 2002 16:32:50 -0600 Subject: REVIEW: psLSB-IA64 v0.9.9 until Thursday February 28th, 2002 Message-ID: <3C6C3B12.D00BE3FE@austin.ibm.com> The psLSB-IA64 v0.9.9 has been posted for public review. The review period ends in two weeks on Thursday February 28th, 2002. http://www.linuxbase.org/spec/lsbia64review.html PS: In the bugreview.html form, please specify in the text area of the form if the "Specification" is "gLSB", "psLSB-IA32", or "psLSB-IA64". Thanks, -- George Kraft IV gk4@austin.ibm.com Linux Standard Base From lawrencc@debian.org Tue Feb 19 02:42:38 2002 From: lawrencc@debian.org (Chris Lawrence) Date: Mon, 18 Feb 2002 20:42:38 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219022155.GC4806@wiggy.net> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> Message-ID: <20020219024238.GA7649@bellsouth.net> On Feb 19, Wichert Akkerman wrote: > Previously Chris Lawrence wrote: > > Will do. The uid/gid 1 issue is definitely an issue; Debian probably > > can't make that change, and I suspect many other LSB implementations > > would trip over it too if they have any POSIX already. > > We can just drop most of the standard accounts and become compatible > by simply not having an optional account. Most of bin/daemon/sync/etc. > aren't used anyway it seems. Unfortunately, the following accounts are required (per http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/usernames.html): USER GROUP UID GID root root 0 0 bin bin 1 1 daemon daemon X X X = unspecified On Debian: USER GROUP UID GID root root 0 0 bin bin 2 2 daemon daemon 1 1 So, either we need to figure out how to get bin and daemon to swap (or at least move daemon somewhere else and move bin from 2 to 1), or the spec needs to change. Frankly, I can't see any reason why uid/gid 1 should be assumed to be bin, especially since no other UIDs and GIDs are static (except 0, which is embedded in the kernel design...). After all, that's why we have getpwuid()... Chris -- Chris Lawrence - http://www.lordsutch.com/chris/ From andrew@pimlott.ne.mediaone.net Tue Feb 19 05:09:51 2002 From: andrew@pimlott.ne.mediaone.net (Andrew Pimlott) Date: Tue, 19 Feb 2002 00:09:51 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219024238.GA7649@bellsouth.net> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> Message-ID: <20020219050951.GA26563@pimlott.ne.mediaone.net> On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote: > Unfortunately, the following accounts are required (per > http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/usernames.html): > > USER GROUP UID GID > root root 0 0 > bin bin 1 1 > daemon daemon X X > > X = unspecified > > On Debian: > > USER GROUP UID GID > root root 0 0 > bin bin 2 2 > daemon daemon 1 1 > > So, either we need to figure out how to get bin and daemon to swap (or > at least move daemon somewhere else and move bin from 2 to 1), or the > spec needs to change. I would lobby to change the spec not to mention bin, daemon, or any of the optional users/groups, at all. They are not specified in a useful way, so they're at best dead-weight, and at worst an opportunity for conflicting interpretations. I filed a bug to this effect with a subject like "user specification is worse than useless". (The sourceforge page is down, so I can't find a URL now.) Andrew From Martijn van Oosterhout Tue Feb 19 05:54:05 2002 From: Martijn van Oosterhout (Martijn van Oosterhout) Date: Tue, 19 Feb 2002 16:54:05 +1100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219050951.GA26563@pimlott.ne.mediaone.net>; from andrew@pimlott.ne.mediaone.net on Tue, Feb 19, 2002 at 12:09:51AM -0500 References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> Message-ID: <20020219165405.B26966@svana.org> On Tue, Feb 19, 2002 at 12:09:51AM -0500, Andrew Pimlott wrote: > On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote: > I would lobby to change the spec not to mention bin, daemon, or any > of the optional users/groups, at all. They are not specified in a > useful way, so they're at best dead-weight, and at worst an > opportunity for conflicting interpretations. IIRC, I think the reasoning went as follows: - The LSB format is based on RPM which has a CPIO archive - CPIO archives store uid/gids as numbers, not names - Installed programs may want to use the daemon user - Hence the daemon user must have a fixed uid Tar stores names instead of numbers and so doesn't suffer from this problem. Note that once the program is running, it can use getpwent(). We're talking about silliness in cpio itself. I beleive the cpio new archive format fixes but it's not well supported. > I filed a bug to this effect with a subject like "user specification > is worse than useless". (The sourceforge page is down, so I can't > find a URL now.) Kind of funny that we would have to start changing the mappings of uids just because some people decided to use RPM as a standard install format. Ofcourse, I could be making this up... -- Martijn van Oosterhout http://svana.org/kleptog/ > Terrorists can only take my life. Only my government can take my freedom. From kukuk@suse.de Tue Feb 19 06:52:12 2002 From: kukuk@suse.de (Thorsten Kukuk) Date: Tue, 19 Feb 2002 07:52:12 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219165405.B26966@svana.org> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> <20020219165405.B26966@svana.org> Message-ID: <20020219075212.A31788@suse.de> On Tue, Feb 19, Martijn van Oosterhout wrote: > On Tue, Feb 19, 2002 at 12:09:51AM -0500, Andrew Pimlott wrote: > > On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote: > > I would lobby to change the spec not to mention bin, daemon, or any > > of the optional users/groups, at all. They are not specified in a > > useful way, so they're at best dead-weight, and at worst an > > opportunity for conflicting interpretations. > > IIRC, I think the reasoning went as follows: > - The LSB format is based on RPM which has a CPIO archive > - CPIO archives store uid/gids as numbers, not names > - Installed programs may want to use the daemon user > - Hence the daemon user must have a fixed uid Have you ever looked at RPM? I don't know which cpio format the RPM internal cpio is using, but the above is wrong, the demon user must not have a fixed uid. RPM does not depend on fixed uids. > Kind of funny that we would have to start changing the mappings of uids > just because some people decided to use RPM as a standard install format. Which is also wrong. This has nothing to do with the fact that LSB has decide to use the RPMv3 package format for delivering programs. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrenstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B From lawrencc@debian.org Tue Feb 19 07:09:10 2002 From: lawrencc@debian.org (Chris Lawrence) Date: Tue, 19 Feb 2002 01:09:10 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219075212.A31788@suse.de> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> <20020219165405.B26966@svana.org> <20020219075212.A31788@suse.de> Message-ID: <20020219070910.GA8034@bellsouth.net> On Feb 19, Thorsten Kukuk wrote: > On Tue, Feb 19, Martijn van Oosterhout wrote: > > > On Tue, Feb 19, 2002 at 12:09:51AM -0500, Andrew Pimlott wrote: > > > On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote: > > > I would lobby to change the spec not to mention bin, daemon, or any > > > of the optional users/groups, at all. They are not specified in a > > > useful way, so they're at best dead-weight, and at worst an > > > opportunity for conflicting interpretations. > > > > IIRC, I think the reasoning went as follows: > > - The LSB format is based on RPM which has a CPIO archive > > - CPIO archives store uid/gids as numbers, not names > > - Installed programs may want to use the daemon user > > - Hence the daemon user must have a fixed uid > > Have you ever looked at RPM? I don't know which cpio format the RPM > internal cpio is using, but the above is wrong, the demon user must > not have a fixed uid. RPM does not depend on fixed uids. Heh... this discussion was on lsb-discuss, what, 6 months ago. As far as I can figure out, there is no technical reason to require uid and gid 1 to be bin, and it's bad programming practice to assume any uid corresponds to any named user. When this last came up, I don't think anyone came up with a good reason not to drop the specification; indeed, I assumed it was gone until I went back and reread the section closely. Let's put it this way: making uid/gid 1 a requirement means Debian probably will never conform to the spec, because of the problem of breaking existing installs. It also creates problems for people who want to use NIS across multiple systems, as Solaris uses uid/gid 2 for bin (like Debian), or running LSB apps on Solaris/x86, which could be conformant if Sun or a third party wanted to do the work. Chris -- Chris Lawrence - http://www.lordsutch.com/chris/ From chewie@wookimus.net Tue Feb 19 07:37:32 2002 From: chewie@wookimus.net (Chad C. Walstrom) Date: Tue, 19 Feb 2002 01:37:32 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219070910.GA8034@bellsouth.net> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> <20020219165405.B26966@svana.org> <20020219075212.A31788@suse.de> <20020219070910.GA8034@bellsouth.net> Message-ID: <20020219073732.GD16523@wookimus.net> --tEFtbjk+mNEviIIX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2002 at 01:09:10AM -0600, Chris Lawrence wrote: > Let's put it this way: making uid/gid 1 a requirement means Debian > probably will never conform to the spec, because of the problem of > breaking existing installs. =20 Only apply the changes to new installs. Alternatively, create a configlet script for the Sysadmin to use while in single-user mode to change over things. We're not changing root here, just bin and daemon. I don't know any application that runs as daemon that still runs in single user mode. #!/bin/sh # # swap uid/gid btwn bin & daemon users/groups # # DISCLAIMER -- this is a hack intended for sysadmins willing to get # their hands dirty once and a while. # >/etc/nologin groupmod -gid 1 -o bin groupmod -gid 2 -o daemon usermod -uid 1 -gbin bin usermod -uid 2 -gdaemon daemon find / -uid 1 -gid 1 -exec chown 2:1 \{\} \; -print > /tmp/2:1.list find / -uid 2 -gid 2 -exec chown 1:1 \{\} \; # already found the files...chown them again to their final uid:gid cat /tmp/2:1.list | xargs chown 2:2 rm /tmp/2:1.list rm /etc/nologin If we have to, we could create/choose a high, random uid that isn't being used as the swap point. > It also creates problems for people who want to use NIS across > multiple systems, as Solaris uses uid/gid 2 for bin (like Debian), or > running LSB apps on Solaris/x86, which could be conformant if Sun or a > third party wanted to do the work. IMHO, you should not be sharing low uid/gid's over NIS, PERIOD, end of sentance. Your NIS uid/gid should be somewhere abovbe 1500 so that your system and operator accounts don't require full-time network connections to be accessible. How many times has your NFS server died or experienced lag, locking you out of your home directory? How many times have you been unable to login because some system profile script requires a file on an NFS automounted directory. How about NIS dying and no-one being able to login except root? It happens. All the time. Why? Badly configured systems, often inherited from one BOFH to another (It's not my fault! -- Han Solo). The fix? Manual labor, headaches, and lots of coffee. I know this from recent experience (geeze, every day, in fact). Should LSB be pushing us around over small, usually systems management related tasks? Probably not. Should the LSB be a good guideline on setting up a sane system to begin with? Certainly. Should we conform to LSB whenever possible. Absolutely. Does this mean we need to convert every running system over to accomedate a uid/gid change? No. The robust solution to such a switch would have to incorporate more tools than I listed above, such as 'ps' and 'fopen'. Perl or Python may be a nice, one-tool approach, and it sounds like the base Debian system should have at least Perl for the time being. Anyway, it's late, and I'm tired. Night! --=20 Chad Walstrom | a.k.a. ^chewie http://www.wookimus.net/ | s.k.a. gunnarr Get my public key, ICQ#, etc. $(mailx -s 'get info' chewie@wookimus.net) --tEFtbjk+mNEviIIX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8cgC8DMcLGCBsWv0RAt7QAKCA6UpPf97Osxdy4d8QaKJ5z0EdfACbB3Aw 4pxq4tbBXuhZqpzSSBEboWU= =XKXt -----END PGP SIGNATURE----- --tEFtbjk+mNEviIIX-- From alan@lxorguk.ukuu.org.uk Tue Feb 19 09:18:38 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 19 Feb 2002 09:18:38 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219165405.B26966@svana.org> from "Martijn van Oosterhout" at Feb 19, 2002 04:54:05 PM Message-ID: > IIRC, I think the reasoning went as follows: > - The LSB format is based on RPM which has a CPIO archive > - CPIO archives store uid/gids as numbers, not names RPM does not have that limitation > - Hence the daemon user must have a fixed uid RPM does not have that limitation either > Note that once the program is running, it can use getpwent(). We're talking Doesn't help you - the password file is not the first package installed on a typical distro > Ofcourse, I could be making this up... Probably From alan@lxorguk.ukuu.org.uk Tue Feb 19 09:25:22 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 19 Feb 2002 09:25:22 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219024238.GA7649@bellsouth.net> from "Chris Lawrence" at Feb 18, 2002 08:42:38 PM Message-ID: > Frankly, I can't see any reason why uid/gid 1 should be assumed to be > bin, especially since no other UIDs and GIDs are static (except 0, > which is embedded in the kernel design...). After all, that's why we > have getpwuid()... Agreed. The rest of the thread is junk but the basic initial question is a good one - why was bin forced to 1 ? From schilling@fokus.gmd.de Tue Feb 19 11:59:15 2002 From: schilling@fokus.gmd.de (Joerg Schilling) Date: Tue, 19 Feb 2002 12:59:15 +0100 (CET) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <200202191159.g1JBxFwW026893@burner.fokus.gmd.de> >From: Chris Lawrence >On Feb 19, Wichert Akkerman wrote: >> Previously Chris Lawrence wrote: >> > Will do. The uid/gid 1 issue is definitely an issue; Debian probably >> > can't make that change, and I suspect many other LSB implementations >> > would trip over it too if they have any POSIX already. >> >> We can just drop most of the standard accounts and become compatible >> by simply not having an optional account. Most of bin/daemon/sync/etc. >> aren't used anyway it seems. >Unfortunately, the following accounts are required (per >http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/usernames.html): >USER GROUP UID GID >root root 0 0 >bin bin 1 1 >daemon daemon X X >X = unspecified Daemon has always been 1 on all traditional UNIX versions including AT&T and *BSD. The real problem between AT&T and *BSD was that AT&T uses 2 for bin and 3 for sys while *BSD used 3 for bin and 2 for sys. Also note that on SunOS 3.x and 4.x "nonody"/"nogroup" have been 65534 \** while SunOS 5.x and SYSvr4 defines "nonody"/"nogroup" to be 60001 and in addition introduce "noaccess" with 60002. **) BSD seems to have copied over the old SunOS nobody mapping. NOTE: If you ever plan to share e.g. /usr via NFS in order to have e.g discless or dataless clients you need to aggree on a static map for all system relevant IDs. Also note: if you like to use a recent TAR standard format \** for data exchange there is a need to standardize nobody/nogroup for security reasons. If you don't standardize nobody/nogroup, you need at least forbid 65534 & 60001/60002 for regular users. Note that many people run file servers with a passwd file that does not hold uid information for the users on the NFS clients. It you make backups, there then is only numeric ID information. As you must take care people who use outdated TAR implementations (like the "pax" implementaion recommended by Mr. Kukuck from SuSE), keep in mind that those implementations do not support POSIX.1-2001 extended headers like "star" and thus will not understand them. They will only see the 7x3 bit values from the old TAR header. For this reason it is important that in case you are archiving ID values > 2097151 you need to use the value of "nobody" for the small number in the old TAR header. If you don't, you will end up to see the real ID modulo 2097151 which may be a real secority problem in case the files have TSUID or TSGID bit set in the permissions. OK, let me stop here and see if there is the right audience on this group before I probably waste my time while writing mail.... **) It seems that at least Mr. Kukuck from SuSE decided to use a "pax" implementation which only supports the 1990 POSIX standard, so there cannot be Large File support or support for UID/GID > 2097151 on LSB Linux. >On Debian: >USER GROUP UID GID >root root 0 0 >bin bin 2 2 >daemon daemon 1 1 This is funny and not somilar to any traditional UNIX system - why? Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From schilling@fokus.gmd.de Tue Feb 19 13:16:32 2002 From: schilling@fokus.gmd.de (Joerg Schilling) Date: Tue, 19 Feb 2002 14:16:32 +0100 (CET) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <200202191316.g1JDGWLw026966@burner.fokus.gmd.de> >From: Alan Cox >> IIRC, I think the reasoning went as follows: >> - The LSB format is based on RPM which has a CPIO archive >> - CPIO archives store uid/gids as numbers, not names >RPM does not have that limitation >> - Hence the daemon user must have a fixed uid >RPM does not have that limitation either >> Note that once the program is running, it can use getpwent(). We're talking >Doesn't help you - the password file is not the first package installed on >a typical distro So RPM _has_ that limitation.... Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From schilling@fokus.gmd.de Tue Feb 19 13:19:49 2002 From: schilling@fokus.gmd.de (Joerg Schilling) Date: Tue, 19 Feb 2002 14:19:49 +0100 (CET) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <200202191319.g1JDJnDQ026981@burner.fokus.gmd.de> >From: Alan Cox >> Frankly, I can't see any reason why uid/gid 1 should be assumed to be >> bin, especially since no other UIDs and GIDs are static (except 0, >> which is embedded in the kernel design...). After all, that's why we >> have getpwuid()... >Agreed. The rest of the thread is junk but the basic initial question is a >good one - why was bin forced to 1 ? In principle there is no reason to force a specifiv number. However there is a reason to force identical numbers to allow NFS mounting of /usr. If you decide on the numbers it would probably make sense to check the SYSvr4 passwd file because most commercial UNIX versions out use this mapping. root:x:0:1:Super-User:/:/sbin/sh daemon:x:1:1::/: bin:x:2:2::/usr/bin: sys:x:3:3::/: adm:x:4:4:Admin:/var/adm: lp:x:71:8:Line Printer Admin:/usr/spool/lp: uucp:x:5:5:uucp Admin:/usr/lib/uucp: nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico smmsp:x:25:25:SendMail Message Submission Program:/: listen:x:37:4:Network Admin:/usr/net/nls: nobody:x:60001:60001:Nobody:/: noaccess:x:60002:60002:No Access User:/: nobody4:x:65534:65534:SunOS 4.x Nobody:/: and for group: root::0:root other::1: bin::2:root,bin,daemon sys::3:root,bin,sys,adm adm::4:root,adm,daemon uucp::5:root,uucp mail::6:root tty::7:root,adm lp::8:root,lp,adm nuucp::9:root,nuucp staff::10: daemon::12:root,daemon sysadmin::14: smmsp::25:smmsp nobody::60001: noaccess::60002: nogroup::65534: Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From alan@lxorguk.ukuu.org.uk Tue Feb 19 14:19:20 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 19 Feb 2002 14:19:20 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <200202191319.g1JDJnDQ026981@burner.fokus.gmd.de> from "Joerg Schilling" at Feb 19, 2002 02:19:49 PM Message-ID: > >Agreed. The rest of the thread is junk but the basic initial question is a > >good one - why was bin forced to 1 ? > > In principle there is no reason to force a specifiv number. > However there is a reason to force identical numbers to allow NFS mounting of > /usr. No. Thats an argument for not forcing them in fact. If they are not dictated then you can pick an arbitary mapping and use that. Which means whatever legacy setup you have (providing it has no existing clashes) will work. Specifying entries just ensures you screw somebody From alan@lxorguk.ukuu.org.uk Tue Feb 19 14:19:58 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 19 Feb 2002 14:19:58 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <200202191316.g1JDGWLw026966@burner.fokus.gmd.de> from "Joerg Schilling" at Feb 19, 2002 02:16:32 PM Message-ID: > >> Note that once the program is running, it can use getpwent(). We're talking > > >Doesn't help you - the password file is not the first package installed on > >a typical distro > > So RPM _has_ that limitation.... With a postinstall trigger - no. From andrew@pimlott.ne.mediaone.net Tue Feb 19 14:47:53 2002 From: andrew@pimlott.ne.mediaone.net (Andrew Pimlott) Date: Tue, 19 Feb 2002 09:47:53 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219165405.B26966@svana.org> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> <20020219165405.B26966@svana.org> Message-ID: <20020219144753.GB31216@pimlott.ne.mediaone.net> On Tue, Feb 19, 2002 at 04:54:05PM +1100, Martijn van Oosterhout wrote: > - Installed programs may want to use the daemon user LSB programs? I don't see what justification they would have for doing so, since the daemon user is specified as "Subprocess special privileges", whatever that means. I think it would be much cleaner to specify that LSB programs should create their own users for daemon processes. (useradd is in LSB, and separate uids is better for security.) Similarly with bin: "Administrative user with some restrictions" doesn't tell me anything about how I, as a packager of an LSB program, would use it. Further, Debian has had user bin forever (probably for the same reason as the LSB: vague tradition), yet AFAICT has found absolutely no use for it. Why can't we end-around this whole issue by dropping these users from the LSB? This is the bug I filed: http://sourceforge.net/tracker/index.php?func=detail&aid=451195&group_id=1107&atid=101107 Andrew From wichert@wiggy.net Tue Feb 19 15:16:28 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Tue, 19 Feb 2002 16:16:28 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219144753.GB31216@pimlott.ne.mediaone.net> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020219021426.GA7547@bellsouth.net> <20020219022155.GC4806@wiggy.net> <20020219024238.GA7649@bellsouth.net> <20020219050951.GA26563@pimlott.ne.mediaone.net> <20020219165405.B26966@svana.org> <20020219144753.GB31216@pimlott.ne.mediaone.net> Message-ID: <20020219151628.GX4806@wiggy.net> Previously Andrew Pimlott wrote: > Why can't we end-around this whole issue by dropping these users > from the LSB? Very much agreed. We shouldn't have a single user or group in the spec unless we have a very good reason (and example) for them. Vague descriptions and things like `tradition' don't count. Personally I'm not aware of a single use of the daemon, bin or sys accounts and wouldn't mind dropping them. The less users we have the better. (accounts that is, you know what I mean :) Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From schilling@fokus.gmd.de Tue Feb 19 15:30:47 2002 From: schilling@fokus.gmd.de (Joerg Schilling) Date: Tue, 19 Feb 2002 16:30:47 +0100 (CET) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <200202191530.g1JFUlBJ027178@burner.fokus.gmd.de> >From alan@lxorguk.ukuu.org.uk Tue Feb 19 15:05:04 2002 >> >Agreed. The rest of the thread is junk but the basic initial question is a >> >good one - why was bin forced to 1 ? >> >> In principle there is no reason to force a specifiv number. >> However there is a reason to force identical numbers to allow NFS mounting of >> /usr. >No. Thats an argument for not forcing them in fact. If they are not dictated >then you can pick an arbitary mapping and use that. Which means whatever >legacy setup you have (providing it has no existing clashes) will work. If you cannot rely on hardcoded numbers, then it will not work to NFS mount /usr bewteen different distributions. This looks much like you are not taking LSB for serious. Note that neither NFS v1, nor V2 or v3 do contain any precautions to map user ids. Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From wichert@wiggy.net Tue Feb 19 15:38:38 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Tue, 19 Feb 2002 16:38:38 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <200202191530.g1JFUlBJ027178@burner.fokus.gmd.de> References: <200202191530.g1JFUlBJ027178@burner.fokus.gmd.de> Message-ID: <20020219153838.GC4806@wiggy.net> Previously Joerg Schilling wrote: > If you cannot rely on hardcoded numbers, then it will not work to NFS > mount /usr bewteen different distributions. You already can not, as was demonstrated not all Linux distributions use the same uid/gid for these users. Question is: why should you rely on having these users provided by the LSB? They don't serve any purpose (at least not within LSB). If people need them in their environment there is nothing to stop them from (re)creating them with a consistent uid/gid that is consistent throughout their environment. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From alan@lxorguk.ukuu.org.uk Tue Feb 19 16:12:35 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 19 Feb 2002 16:12:35 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <200202191530.g1JFUlBJ027178@burner.fokus.gmd.de> from "Joerg Schilling" at Feb 19, 2002 04:30:47 PM Message-ID: > >No. Thats an argument for not forcing them in fact. If they are not dictated > >then you can pick an arbitary mapping and use that. Which means whatever > >legacy setup you have (providing it has no existing clashes) will work. > > If you cannot rely on hardcoded numbers, then it will not work to NFS mount /usr > bewteen different distributions. You can fix the numbers on any system to match what you want. Thats what not defining numbers means. "I've got 8 legacy sun boxes so I'll use their system uid layout" > Note that neither NFS v1, nor V2 or v3 do contain any precautions to map user > ids. They don't disallow it either. See uuid in the unfsd package From vorlon@netexpress.net Tue Feb 19 17:44:55 2002 From: vorlon@netexpress.net (Steve Langasek) Date: Tue, 19 Feb 2002 11:44:55 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: References: <20020219165405.B26966@svana.org> Message-ID: <20020219174450.GB22260@netexpress.net> --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2002 at 09:18:38AM +0000, Alan Cox wrote: > > Note that once the program is running, it can use getpwent(). We're tal= king > Doesn't help you - the password file is not the first package installed on > a typical distro So the goal of this provision is to allow LSB packages to make use of=20 certain non-root facilities before the system has a password file? I'd think the easy way to avoid that nonsense is to specify that an=20 LSB-compliant system gives meaningful results when calling getpwnam()=20 for certain required usernames (whether it uses /etc/passwd, NIS, LDAP,=20 whatever). That one issue doesn't justify hard-coding of=20 arbitrarily-chosen uids for system users. In Debian, our /etc/passwd is provided by base-passwd, which is an=20 "Essential: yes" package of required priority that's part of the base=20 section of the archive. Anyone trying to install an LSB package on=20 Debian before the *installer* has even been allowed to run is engaged in=20 foot-shooting of Olympic proportions. While I don't know whether Debian would be considered a 'typical'=20 distro, I would expect that other common distros are similarly=20 unaffected by this concern. Steve Langasek postmodern programmer --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8co8SKN6ufymYLloRAlKpAJ4uug2mH1iBalCNNAX6GyXepetQAACdGi89 /xFqP0XugrJDg2EEJ9GFz6o= =jB0i -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From alan@lxorguk.ukuu.org.uk Wed Feb 20 02:08:19 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Wed, 20 Feb 2002 02:08:19 +0000 (GMT) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020219174450.GB22260@netexpress.net> from "Steve Langasek" at Feb 19, 2002 11:44:55 AM Message-ID: > > Doesn't help you - the password file is not the first package installed on > > a typical distro > > So the goal of this provision is to allow LSB packages to make use of=20 > certain non-root facilities before the system has a password file? Its not needed for that either. Nothing in an RPM based system that I know of requires bin is uid 1 From cyeoh@samba.org Wed Feb 20 02:53:20 2002 From: cyeoh@samba.org (Christopher Yeoh) Date: Wed, 20 Feb 2002 13:53:20 +1100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: References: <20020219174450.GB22260@netexpress.net> Message-ID: <15475.4000.229353.942995@gargle.gargle.HOWL> At 2002/2/20 02:08+0000 Alan Cox writes: > > > Doesn't help you - the password file is not the first package installed on > > > a typical distro > > > > So the goal of this provision is to allow LSB packages to make use of=20 > > certain non-root facilities before the system has a password file? > > Its not needed for that either. Nothing in an RPM based system that I know > of requires bin is uid 1 So does anyone out there have any objections to removing the requirement that the uid and gid of the bin user be 1? If no one comes up with a good reason in the next week I'll just remove it. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From wichert@wiggy.net Wed Feb 20 09:05:25 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Wed, 20 Feb 2002 10:05:25 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <15475.4000.229353.942995@gargle.gargle.HOWL> References: <20020219174450.GB22260@netexpress.net> <15475.4000.229353.942995@gargle.gargle.HOWL> Message-ID: <20020220090525.GU4806@wiggy.net> Previously Christopher Yeoh wrote: > So does anyone out there have any objections to removing the > requirement that the uid and gid of the bin user be 1? If no one > comes up with a good reason in the next week I'll just remove it. Why keep the bin user at all? I haven't seen a rationale for its existence yet. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From anderson@metrolink.com Wed Feb 20 14:27:14 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 09:27:14 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <15475.4000.229353.942995@gargle.gargle.HOWL> Message-ID: <20020220092211.F429-100000@trantor.sc.metrolink.com> On Wed, 20 Feb 2002, Christopher Yeoh wrote: > So does anyone out there have any objections to removing the > requirement that the uid and gid of the bin user be 1? We put it in there for a reason, and so far, I don't think anyone has correctly recalled the reason. Unfortunately, it was done so long ago that I don't remember all of the details either. I think part of the reason for having added this was that this was an area where divergence was beginning to occur, and those participating at the time felt that we should specify the common practice to prevent further divergence. Before we make a change here, some one should look through the archive, and try to summarize the discussions that let to it being added in the first place. > If no one > comes up with a good reason in the next week I'll just remove it. Unfortunately, we can't just remove it. It has been published as part of the standard. What we can do, however, is to mark that portion as "deprecated" and remove it in a future release. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From aj@azure.humbug.org.au Wed Feb 20 14:57:07 2002 From: aj@azure.humbug.org.au (Anthony Towns) Date: Thu, 21 Feb 2002 00:57:07 +1000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220092211.F429-100000@trantor.sc.metrolink.com> References: <15475.4000.229353.942995@gargle.gargle.HOWL> <20020220092211.F429-100000@trantor.sc.metrolink.com> Message-ID: <20020220145707.GA25873@azure.humbug.org.au> --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 09:27:14AM -0500, Stuart Anderson wrote: > We put it in there for a reason, and so far, I don't think anyone has > correctly recalled the reason. Unfortunately, it was done so long ago that > I don't remember all of the details either. You know, if no one can think of the reason in the months since this was first brought up in response to the "1.0" spec release, it quite simply can't have been a remotely good one. It's already evident that absolutely *none* of the stake holders in the LSB have any particular interest in keeping it, and a number of important stakeholders (Debian, you know, the second or third most popular Linux distribution worldwide, and everyone who wants their LSB compliant packages to run on Debian; not to mention Solaris ("Sun's implementation of Linux", if you'll recall)) have a strong desire to have it removed. > I think part of the reason for having added this was that this was an area > where divergence was beginning to occur, and those participating at the t= ime > felt that we should specify the common practice to prevent further diverg= ence. Preventing divergence is not the LSB's charter. The LSB's charter is to specify a set of APIs that will allow useful third party software to run across a wide variety of systems. Specifying the uid of the bin user does not make it easier to write software for Linux systems, and it limits the number of systems on which LSB-compliant software can run. > Unfortunately, we can't just remove it. It has been published as part > of the standard. What we can do, however, is to mark that portion as > "deprecated" and remove it in a future release. The standard is recognised to be buggy and there is no existing userbase. What better time do you think there'll be to remove it? Of course, I suppose you could argue that if the standard is kept buggy, there probably won't ever be a userbase. Do you really want to? Enough with going around in circles about pointless nonsense. There are a handful of simple changes that are needed right now for the LSB to achieve its goals. It's time to make them. Who has commit access to version 1.2 of the spec? Cheers, aj --=20 Anthony Towns We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each=20 toe individually.'' -- with kudos to Greg Lehey --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHO5QuRRvX9xctrtAQEwhgP9HPtSFZrk/bfhQai/BkpT6qruhktt8/dj T3FT1gic3c9z204etsShXUlGtimjd0IMwUAVmTccP+TYH4uP1akHklbVjVDnmPtG +07CV5x6pc5icdrkbuw9HFwe7bK+gsnoIvy71ruXQFoz5q7Yr8ps+OntKH3WNlra 8mp2dCpNqOM= =wTk7 -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From wichert@wiggy.net Wed Feb 20 14:58:34 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Wed, 20 Feb 2002 15:58:34 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220092211.F429-100000@trantor.sc.metrolink.com> References: <15475.4000.229353.942995@gargle.gargle.HOWL> <20020220092211.F429-100000@trantor.sc.metrolink.com> Message-ID: <20020220145834.GE4806@wiggy.net> Previously Stuart Anderson wrote: > I think part of the reason for having added this was that this was an area > where divergence was beginning to occur, and those participating at the time > felt that we should specify the common practice to prevent further divergence. I don't think divergence is a good reason for putting them into LSB: if we don't spec those users at all it doesn't matter if they diverge since people can't use them without violating the LSB, but more interestingly it will also allow us to remove them completely. > Unfortunately, we can't just remove it. It has been published as part > of the standard. What we can do, however, is to mark that portion as > "deprecated" and remove it in a future release. What I plan to do for Debian is not install those users on new installs but keep them around on existing systems. This will be done after the woody release though so it won't affect anyone for the current forseeable future. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From David.VomLehn@compaq.com Wed Feb 20 15:11:14 2002 From: David.VomLehn@compaq.com (VomLehn, David) Date: Wed, 20 Feb 2002 09:11:14 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <717252EC3E37AE4392E2614EA24E9F2B1ECD7C@txnexc01.americas.cpqcorp.net> I would urge some caution here. If I were to guess at a reason as to why bin has uid/gid of 1, I would suspect that some application installations use 1 as the bin uid/gid instead of looking it up. This may not be good practices, but the LSB work is primarily focused on codifying current practices, good or not. Before this is deprecated, it would probably help to look in distributions of various application packages and/or ask the creators/maintainers of those packages to check for an assumption that bin will have uid/gid equal to 1. And, since we all make mistakes, I'd suggest changing the bin uid/gid on a system in a distribution or two, install the most commonly used applications, and see if they execute properly. -----Original Message----- From: Wichert Akkerman [mailto:wichert@wiggy.net] Sent: Wednesday, February 20, 2002 8:59 AM To: debian-devel@lists.debian.org; lsb-spec@lists.linuxbase.org Subject: Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Previously Stuart Anderson wrote: > I think part of the reason for having added this was that this was an area > where divergence was beginning to occur, and those participating at the time > felt that we should specify the common practice to prevent further divergence. I don't think divergence is a good reason for putting them into LSB: if we don't spec those users at all it doesn't matter if they diverge since people can't use them without violating the LSB, but more interestingly it will also allow us to remove them completely. > Unfortunately, we can't just remove it. It has been published as part > of the standard. What we can do, however, is to mark that portion as > "deprecated" and remove it in a future release. What I plan to do for Debian is not install those users on new installs but keep them around on existing systems. This will be done after the woody release though so it won't affect anyone for the current forseeable future. Wichert. --=20 _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | --=20 To UNSUBSCRIBE, email to lsb-spec-request@lists.linuxbase.org with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org From anderson@metrolink.com Wed Feb 20 15:15:03 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 10:15:03 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220145707.GA25873@azure.humbug.org.au> Message-ID: <20020220100625.G429-100000@trantor.sc.metrolink.com> On Thu, 21 Feb 2002, Anthony Towns wrote: > You know, if no one can think of the reason in the months since this > was first brought up in response to the "1.0" spec release, it quite > simply can't have been a remotely good one. The words in question were written well over a year ago, which is why it is hard to recall the details. > It's already evident that > absolutely *none* of the stake holders in the LSB have any particular > interest in keeping it, and a number of important stakeholders (Debian, > you know, the second or third most popular Linux distribution worldwide, Yes, I am quite familiar with Debian as I use it in several places. > and everyone who wants their LSB compliant packages to run on Debian; not > to mention Solaris ("Sun's implementation of Linux", if you'll recall)) > have a strong desire to have it removed. I don't mind removing it, but I do mind making random, uncontrolled changes to a document that is supposed to be stable and "controlled". My point in this is that we need to follow a proper process in making changes like this. > Preventing divergence is not the LSB's charter. Actually, it is one of the original problems that cuased the LSB to be formed nearly 4 years ago. > The LSB's charter is > to specify a set of APIs that will allow useful third party software > to run across a wide variety of systems. Developing the ABI for Linux was seen as the best route to accomplishing the job. Adding a few things beyond the strict limits of the ABI was also seen as a good thing. > Specifying the uid of the bin > user does not make it easier to write software for Linux systems, and > it limits the number of systems on which LSB-compliant software can run. As I said above, I don't mind removing the uids, I just want to make sure that proper diligence is used when doing so. > The standard is recognised to be buggy and there is no existing userbase. > What better time do you think there'll be to remove it? I'm not resisting the removal of it, just that a proper process be followed. This avoids having to ask the questions "how large does the user base have to be before we can't fix something". > Of course, I suppose you could argue that if the standard is kept buggy, > there probably won't ever be a userbase. Do you really want to? I have never suggested keeping it buggy. > Enough with going around in circles about pointless nonsense. There are > a handful of simple changes that are needed right now for the LSB to > achieve its goals. It's time to make them. > > Who has commit access to version 1.2 of the spec? Myself and a few others, but I have been tasked with ensuring that changes are made in a consistant manner. That's all I am trying to do. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From anderson@metrolink.com Wed Feb 20 15:17:06 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 10:17:06 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220145834.GE4806@wiggy.net> Message-ID: <20020220101538.B429-100000@trantor.sc.metrolink.com> On Wed, 20 Feb 2002, Wichert Akkerman wrote: > I don't think divergence is a good reason for putting them into LSB: > if we don't spec those users at all it doesn't matter if they diverge > since people can't use them without violating the LSB, but more > interestingly it will also allow us to remove them completely. There was some original problem that was caused by the fact they were different on different distributions. I would just like to be able to recall what that problem was, and then we can decide if it still needs fixing or not. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From aj@azure.humbug.org.au Wed Feb 20 15:18:19 2002 From: aj@azure.humbug.org.au (Anthony Towns) Date: Thu, 21 Feb 2002 01:18:19 +1000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <717252EC3E37AE4392E2614EA24E9F2B1ECD7C@txnexc01.americas.cpqcorp.net> References: <717252EC3E37AE4392E2614EA24E9F2B1ECD7C@txnexc01.americas.cpqcorp.net> Message-ID: <20020220151819.GA27175@azure.humbug.org.au> --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 09:11:14AM -0600, VomLehn, David wrote: > I would urge some caution here. If I were to guess at a reason as to why > bin has uid/gid of 1, I would suspect that some application > installations use 1 as the bin uid/gid instead of looking it up. This > may not be good practices, but the LSB work is primarily focused on > codifying current practices, good or not. No, it's not. The LSB is focussed on codifying practices that can be used to install third party software on any distribution of Linux. Assuming the uid of the bin user is 1, is not one of those practices, and it should never have been codified. This change will not make any distribution non-conformant, and since there are absolutely no LSB compliant apps at present, won't break any of them, either. Cheers, aj --=20 Anthony Towns We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each=20 toe individually.'' -- with kudos to Greg Lehey --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHO+OuRRvX9xctrtAQF7rwQAnVhlVBqvF8nBJpIR0O8/3qnm5PumU+Jv ZjhM0SQ24/9LteLowm8rIndenAZzcYWIsAnnYBgwrCQMzamGS/uZNbqpgJcElTVu +HT8YYmB8DZJD1aHjkmbQLwW/7k1pzF43JMBX09UQjTU96DYdQIVT+m3A7fheiaa CmVrntNN6II= =G/KT -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From wichert@wiggy.net Wed Feb 20 15:18:59 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Wed, 20 Feb 2002 16:18:59 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <717252EC3E37AE4392E2614EA24E9F2B1ECD7C@txnexc01.americas.cpqcorp.net> References: <717252EC3E37AE4392E2614EA24E9F2B1ECD7C@txnexc01.americas.cpqcorp.net> Message-ID: <20020220151859.GH4806@wiggy.net> Previously VomLehn, David wrote: > I would urge some caution here. If I were to guess at a reason as to why > bin has uid/gid of 1, I would suspect that some application > installations use 1 as the bin uid/gid instead of looking it up. But this already isn't portable since the uid of bin is not consistent between Linux distributions. > This may not be good practices, but the LSB work is primarily focused > on codifying current practices, good or not. codifying a current broken practice is broken. Also notice that the description if bin and daemon in the LSB are vague at best which suggests that there really is nobody who has any good reason for having those accounts around. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From David.VomLehn@compaq.com Wed Feb 20 15:34:55 2002 From: David.VomLehn@compaq.com (VomLehn, David) Date: Wed, 20 Feb 2002 09:34:55 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <717252EC3E37AE4392E2614EA24E9F2B1ECD7D@txnexc01.americas.cpqcorp.net> Yes, assuming the bin uid/gid are 1 isn't good practice as it is not consistent between Linux distributions. That's not the issue and Debian is not going to comply with LSB 1.0, ever. But note that I am saying nothing about complying with any other version of the LSB. The most difficult question that a standards body codifying existing practice deals with is trying to not break existing software. Since most software should be using good practices and hence using getpwent(), most existing software will work with Debian. When we deprecate a specific item in the LSB, we are giving software providers notice that their software needs to be changed to comply with LSB 1.x, 2.x, etc. When the specification requirement that bin's uid/gid be 1 is obsoleted, software providers will have been given ample time (1-2 yrs.?) to update their software. At that time, Debian, with no changes, will become compliant with the version of the LSB in which the requirement that bin's uid/gid be 1 is dropped. If I were Debian, I would be frustrated at the length of time it takes to obsolete a feature. It's an unfortunate reality that software producers need to have time to change their products, but it is also an unavoidable reality. Lastly, I offer the observation that if it were easy to create and update a Linux interface standard, it would have been done a long time ago. -----Original Message----- From: Wichert Akkerman [mailto:wichert@wiggy.net] Sent: Wednesday, February 20, 2002 9:19 AM To: VomLehn, David Cc: debian-devel@lists.debian.org; lsb-spec@lists.linuxbase.org Subject: Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Previously VomLehn, David wrote: > I would urge some caution here. If I were to guess at a reason as to why > bin has uid/gid of 1, I would suspect that some application > installations use 1 as the bin uid/gid instead of looking it up. But this already isn't portable since the uid of bin is not consistent between Linux distributions. > This may not be good practices, but the LSB work is primarily focused > on codifying current practices, good or not. codifying a current broken practice is broken. Also notice that the description if bin and daemon in the LSB are vague at best which suggests that there really is nobody who has any good reason for having those accounts around. Wichert. --=20 _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From joy@cibalia.gkvk.hr Wed Feb 20 15:47:32 2002 From: joy@cibalia.gkvk.hr (Josip Rodin) Date: Wed, 20 Feb 2002 16:47:32 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220100625.G429-100000@trantor.sc.metrolink.com> References: <20020220145707.GA25873@azure.humbug.org.au> <20020220100625.G429-100000@trantor.sc.metrolink.com> Message-ID: <20020220154732.GE16663@cibalia.gkvk.hr> On Wed, Feb 20, 2002 at 10:15:03AM -0500, Stuart Anderson wrote: > > Preventing divergence is not the LSB's charter. > > Actually, it is one of the original problems that cuased the LSB to be formed > nearly 4 years ago. I think he meant "preventing divergence that doesn't need prevention is no the charter of LSB". > I'm not resisting the removal of it, just that a proper process be followed. > I have been tasked with ensuring that changes are made in a consistant > manner. That's all I am trying to do. Okay, so let's summarize. This rule breaks things as it is. If we change it, other things might break. However, nobody can think of what these other things are. The choice seems pretty clear, now let's start the procedure of changing. :) -- 2. That which causes joy or happiness. From wichert@wiggy.net Wed Feb 20 15:55:59 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Wed, 20 Feb 2002 16:55:59 +0100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <717252EC3E37AE4392E2614EA24E9F2B1ECD7D@txnexc01.americas.cpqcorp.net> References: <717252EC3E37AE4392E2614EA24E9F2B1ECD7D@txnexc01.americas.cpqcorp.net> Message-ID: <20020220155559.GI4806@wiggy.net> Previously VomLehn, David wrote: > That's not the issue and Debian is not going to comply with LSB 1.0, > ever. >From what I see no distribution will be LSB 1.0 complient but will start with 1.1 instead. But that isn't really relevant here. > The most difficult question that a standards body codifying existing > practice deals with is trying to not break existing software. Mostly agreed. > If I were Debian, I would be frustrated at the length of time it takes > to obsolete a feature. That isn't frustrating. Debian has always been in the business of providing seemless upgrades and we've been dealing with numerous multi-year transitions forever so we know how that works. The frustrating bit is that apparently these users were added to the LSB without a clear rationale and we need to clean up the resulting mess now. > It's an unfortunate reality that software producers need to have time > to change their products, but it is also an unavoidable reality. Can we try and investigate if there is a product out there that actually uses these two users? I would be very surprised of one exists. > Lastly, I offer the observation that if it were easy to create and > update a Linux interface standard, it would have been done a long time > ago. That isn't going to stop anyone from complaining though :) Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From anderson@metrolink.com Wed Feb 20 15:57:49 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 10:57:49 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220154732.GE16663@cibalia.gkvk.hr> Message-ID: <20020220105408.I429-100000@trantor.sc.metrolink.com> On Wed, 20 Feb 2002, Josip Rodin wrote: > I think he meant "preventing divergence that doesn't need prevention is no > the charter of LSB". I can agree with that. At the time (over a year ago), those participating in the LSB work felt that is was needed, so it got added. I agree, that it probably isn't needed, and just want to back it out in an appropriate manner. > Okay, so let's summarize. This rule breaks things as it is. If we change it, > other things might break. However, nobody can think of what these other > things are. The choice seems pretty clear, now let's start the procedure of > changing. :) OK 8-). I do feel that part of the proceedure is to understand why it was added in the first place. The only thing worse than having it in there, would be to remove it, and then discover the hard way why it had been put in there to begin with. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From David.VomLehn@compaq.com Wed Feb 20 16:05:34 2002 From: David.VomLehn@compaq.com (VomLehn, David) Date: Wed, 20 Feb 2002 10:05:34 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <717252EC3E37AE4392E2614EA24E9F2B1ECD7E@txnexc01.americas.cpqcorp.net> This is a multi-part message in MIME format. ------_=_NextPart_001_01C1BA28.6D7F2801 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable See below. -----Original Message----- From: Anthony Towns [ mailto:aj@azure.humbug.org.au] Sent: Wednesday, February 20, 2002 9:18 AM To: debian-devel@lists.debian.org; lsb-spec@lists.linuxbase.org Subject: Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package On Wed, Feb 20, 2002 at 09:11:14AM -0600, VomLehn, David wrote: > I would urge some caution here. If I were to guess at a reason as to why > bin has uid/gid of 1, I would suspect that some application > installations use 1 as the bin uid/gid instead of looking it up. This > may not be good practices, but the LSB work is primarily focused on > codifying current practices, good or not. No, it's not. The LSB is focussed on codifying practices that can be used to install third party software on any distribution of Linux. Assuming the uid of the bin user is 1, is not one of those practices, and it should never have been codified. Yes, and I think it's likely we made a mistake. It's now too late to change that for versions 1.0 and 1.1 of the LSB specification and I suggest that we simply understand the current state of affairs, accept it, and implement a reasonable process to fix the mistake. Doing so will take at least a year after the fix process begins to allow any application providers to make the required change. =20 The fix for this follows a well-beaten path--we are not the first standardization body to make a mistake. Assuming there is nobody who can find any reason for the current state of affairs, the very next release of the LSB includes, 1) a statement that the requirement that uid and gid be one is deprecated and will become obsolete in a future release, 2) specify that the plan is to obsolete this requirement in the first approved version of the LSB specification after a particular date, and 3) deliver on item 2. This change will not make any distribution non-conformant, and since there are absolutely no LSB compliant apps at present, won't break any of them, either. Yes, and it's great when we can move forward without breaking anything. The fact that there are no LSB compliant applications at present does not mean that there are no applications which completely meet the LSB specification. When a proper validation procedure exists for formally declaring an application compliant with LSB 1.1, the ones which assume that the uid and gid of bin are one will also be compliant. Since I expect the LSB effort to continue into the future, I also expect that some LSB 1.1 compliant applications will not be LSB compliant to a future version of the specification. I think I've made my position clear, so I have nothing further to discuss on this issue in LSB mailing lists. If anyone else wishes to engage me in further dialog, please send email directly to me. If there is a reason to view things differently, I'll publicize it myself. ------_=_NextPart_001_01C1BA28.6D7F2801 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    See below.

    -----Original=20 Message-----
    From: Anthony Towns [mailto:aj@azure.humbug.org.au]=
    Sent:=20 Wednesday, February 20, 2002 9:18 AM
    To: = debian-devel@lists.debian.org;=20 lsb-spec@lists.linuxbase.org
    Subject: Re: Bug#134658: ITP: lsb -- = Linux=20 Standard Base 1.1 core
    support package


    On Wed, Feb 20, = 2002 at=20 09:11:14AM -0600, VomLehn, David wrote:
    > I would urge some = caution here.=20 If I were to guess at a reason as to why
    > bin has uid/gid of 1, I = would=20 suspect that some application
    > installations use 1 as the bin = uid/gid=20 instead of looking it up. This
    > may not be good practices, but = the LSB=20 work is primarily focused on
    > codifying current practices, good = or=20 not.

    No, it's not. The LSB is focussed on codifying practices = that can be=20 used
    to install third party software on any distribution of Linux.=20 Assuming
    the uid of the bin user is 1, is not one of those practices, = and=20 it
    should never have been codified.

    Yes, and I think it's = likely we=20 made a mistake. It's now too late to change that for versions 1.0 and = 1.1 of=20 the LSB specification and I suggest that we simply understand the = current=20 state of affairs, accept it, and implement a reasonable process to fix = the=20 mistake. Doing so will take at least a year after the fix process = begins to=20 allow any application providers to make the required = change.
     
    The fix for this = follows a=20 well-beaten path--we are not the first standardization body to make a = mistake.=20 Assuming there is nobody who can find any reason for the current state = of=20 affairs, the very next release of the LSB includes, 1) a statement = that the=20 requirement that uid and gid be one is deprecated and will become = obsolete in=20 a future release, 2) specify that the plan is to obsolete this = requirement in=20 the first approved version of the LSB specification after a particular = date,=20 and 3) deliver on item 2.

    This change will not make any = distribution=20 non-conformant, and since
    there are absolutely no LSB compliant apps = at=20 present, won't break any
    of them, either.

    Yes, and=20 it's great when we can move forward without breaking anything. The = fact that=20 there are no LSB compliant applications at present does not mean that = there=20 are no applications which completely meet the LSB specification. When = a proper=20 validation procedure exists for formally declaring an application = compliant=20 with LSB 1.1, the ones which assume that the uid and gid of bin are = one will=20 also be compliant. Since I expect the LSB effort to continue into the = future,=20 I also expect that some LSB 1.1 compliant applications will not be LSB = compliant to a future version of the specification.

    I think=20 I've made my position clear, so I have nothing further to discuss on = this=20 issue in LSB mailing lists. If anyone else wishes to engage me in = further=20 dialog, please send email directly to me. If there is a reason to view = things=20 differently, I'll publicize it=20 myself.

     ------_=_NextPart_001_01C1BA28.6D7F2801-- From mats.d.wichmann@intel.com Wed Feb 20 16:13:13 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Wed, 20 Feb 2002 08:13:13 -0800 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA29.7F421FF0 Content-Type: text/plain; charset="iso-8859-1" Note that the LSB is presently engaged in a process (building the certification program) which includes an obsolescence plan as a deliverable. Yes, and I think it's likely we made a mistake. It's now too late to change that for versions 1.0 and 1.1 of the LSB specification and I suggest that we simply understand the current state of affairs, accept it, and implement a reasonable process to fix the mistake. Doing so will take at least a year after the fix process begins to allow any application providers to make the required change. The fix for this follows a well-beaten path--we are not the first standardization body to make a mistake. Assuming there is nobody who can find any reason for the current state of affairs, the very next release of the LSB includes, 1) a statement that the requirement that uid and gid be one is deprecated and will become obsolete in a future release, 2) specify that the plan is to obsolete this requirement in the first approved version of the LSB specification after a particular date, and 3) deliver on item 2. ------_=_NextPart_001_01C1BA29.7F421FF0 Content-Type: text/html; charset="iso-8859-1"
    Note that the LSB is presently engaged in a process (building the
    certification program) which includes an obsolescence plan as
    a deliverable.
    Yes, and I think it's likely we made a mistake. It's now too late to change that for versions 1.0 and 1.1 of the LSB specification and I suggest that we simply understand the current state of affairs, accept it, and implement a reasonable process to fix the mistake. Doing so will take at least a year after the fix process begins to allow any application providers to make the required change.
     
    The fix for this follows a well-beaten path--we are not the first standardization body to make a mistake. Assuming there is nobody who can find any reason for the current state of affairs, the very next release of the LSB includes, 1) a statement that the requirement that uid and gid be one is deprecated and will become obsolete in a future release, 2) specify that the plan is to obsolete this requirement in the first approved version of the LSB specification after a particular date, and 3) deliver on item 2.  
     
    ------_=_NextPart_001_01C1BA29.7F421FF0-- From aj@azure.humbug.org.au Wed Feb 20 16:17:39 2002 From: aj@azure.humbug.org.au (Anthony Towns) Date: Thu, 21 Feb 2002 02:17:39 +1000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220100625.G429-100000@trantor.sc.metrolink.com> References: <20020220145707.GA25873@azure.humbug.org.au> <20020220100625.G429-100000@trantor.sc.metrolink.com> Message-ID: <20020220161739.GB27175@azure.humbug.org.au> --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 10:15:03AM -0500, Stuart Anderson wrote: > On Thu, 21 Feb 2002, Anthony Towns wrote: > > You know, if no one can think of the reason in the months since this > > was first brought up in response to the "1.0" spec release, it quite > > simply can't have been a remotely good one. > The words in question were written well over a year ago, which is why it > is hard to recall the details. Well, it's over half a year since this was first brought up as a problem (4 July 2001, http://lists.debian.org/lsb-spec/2001/lsb-spec-200107/msg00002.html at the very least). > I don't mind removing it, but I do mind making random, uncontrolled chang= es > to a document that is supposed to be stable and "controlled". My point in= this > is that we need to follow a proper process in making changes like this. Well, it'd have been nice if that had happened in the first place, with, say, some reasonable opportunity to comment on things like this *before* they were specified. But since that didn't happen, the LSB simply has to fix it now, however galling that may be. > > Specifying the uid of the bin > > user does not make it easier to write software for Linux systems, and > > it limits the number of systems on which LSB-compliant software can run. > As I said above, I don't mind removing the uids, I just want to make sure= that > proper diligence is used when doing so. What, exactly, is "proper diligence" ? It would seem to me that due diligence would involve contacting key distribution vendors (Red Hat, Debian, Mandrake, SuSE) and ensuring there are no issues with a change. This clearly was *not* done before the bin uid was added to the 1.0 spec (the change wasn't even mentioned on the list before the 1.0 spec was released); and it clearly *has* been done now (there are developers from all of those distributions on the LSB specs, and developers from at least two of them have commented in favour of the change). By contrast, where was the due diligence in response to 496591 ("LSB packages should be named ".lsb")? The only response I've seen to that (and since I raised the issue, I'd assume I'd see what response there is), was the thread beginning at: http://lists.debian.org/lsb-discuss/2001/lsb-discuss-200112/msg00035.html and a "discussed and rejected" response to the sourceforge bug report, and in one of the conference call minutes. If you look back through the thread, you'll see absolutely no consensus or meeting of minds was achieved. There are a host of other issues that I and others have raised which have been dealt with in a similarly haphazard way (hardcoding Red Hat's interpretation of runlevels into the init script spec, the useless "local mounts" and "remote mount" system services, to name a couple of examples). These aren't things that kill the spec (unlike a number of the details in the user/group spec), but they are detrimental. The LSB group is doing a fine job of ignoring them all out of existance, though. > > The standard is recognised to be buggy and there is no existing userbas= e. > > What better time do you think there'll be to remove it? > I'm not resisting the removal of it, just that a proper process be follow= ed. So forgive me if these words ring completely hollow. [0] > > Enough with going around in circles about pointless nonsense. There are > > a handful of simple changes that are needed right now for the LSB to > > achieve its goals. It's time to make them. > > Who has commit access to version 1.2 of the spec? > Myself and a few others, but I have been tasked with ensuring that change= s are > made in a consistant manner. That's all I am trying to do. Well, I'm not sure I can dispute the consistency of the change policy ("Oh, it's from Debian, eh? Ignore it."), but ensuring necessary or useful changes are made quickly and correctly seems like a much more worthy goal. It's not really fun watching a project that seems like it could be fairly important to the Linux community falling into all the usual traps of non-bazaar development [0]. Cheers, aj [0] Process over functionality. Unresponsiveness to comments. Closed channels of communication between the core developers instead of regular use of mailing lists. Worrying more about releasing at LinuxWorld than getting something useful, or at least, not actively harmful, out. --=20 Anthony Towns We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each=20 toe individually.'' -- with kudos to Greg Lehey --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHPMIuRRvX9xctrtAQFyegP+Ni71fIaqhw47jMjEEej+SCzokK8bBl+Y +PYvnsKYlWD773SQ5bmHzMm3STzaM2UZwQ7dTJKmTGk6T7odw6e+Wo22pvp0c5Ou v20dWoWiWGHellNpfUwF+tI53EWargInyphhaXcwSPAZGLQoslYTixBGOGoM67eS 5JNgIcg3aV8= =Ruer -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From aj@azure.humbug.org.au Wed Feb 20 16:26:29 2002 From: aj@azure.humbug.org.au (Anthony Towns) Date: Thu, 21 Feb 2002 02:26:29 +1000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> References: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> Message-ID: <20020220162629.GC27175@azure.humbug.org.au> --hOcCNbCCxyk/YU74 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 08:13:13AM -0800, Wichmann, Mats D wrote: > It's now too late to change > that for versions 1.0 and 1.1 of the LSB specification=20 I know no one's going to actually listen to me here, but it bears repeating: this is quite simply wrong. It's our spec. We can do whatever we like to it. We can declare that packages written by people whose middle name has an odd number of letters were never intended to comply with the specs, and issue updates to both version 1.0 and 1.1 tomorrow to say that. No one is going to stop us. We're not going to be thrown in prison. We're not going to have our editors or our web pages taken away from us. More to the point: we're not even going to annoy anyone. Of the distributors who've started trying to conform to the LSB, *none* of them will have to change anything. Any application developers who've been writing LSB packages will be pleased to have been informed of what they have to do to make sure their programs actually run on Debian. People writing test suites will have one less thing to try to test, so they'll be overjoyed. We could do this tomorrow, and _no one_ would have any cause to complain. Of course, the *real* lesson to learn from this is *NEVER* *EVER* to make an official release without having a thorough round of reviews and actually resolving all the issues that're raised, no matter how long this takes. The uid-of-user-bin issue was raised as soon as we saw the form that section took, which unfortunately was immediately after the 1.0 spec was published, and during the review period for the 1.1 spec. Cheers, aj --=20 Anthony Towns We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each=20 toe individually.'' -- with kudos to Greg Lehey --hOcCNbCCxyk/YU74 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHPONORRvX9xctrtAQFSQwQAlMH0UNp/HiTLYlxMgMIKQFPBR50EEfXv /Ahp9EyvRILIBrhScwqPhNajXx2Xcy/JH6R9ij0Dv0DXoZmPoVyFj+CVqmWoX0/4 AmnaA5t1Xu1vJ+9he0hhBVpKY8408CBsBIKYkxivIR3Enk0hXnZA8NJ4m1IXwJQ3 bFZnxPGf5Ms= =PeW2 -----END PGP SIGNATURE----- --hOcCNbCCxyk/YU74-- From lawrencc@debian.org Wed Feb 20 16:27:13 2002 From: lawrencc@debian.org (Chris Lawrence) Date: Wed, 20 Feb 2002 10:27:13 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <717252EC3E37AE4392E2614EA24E9F2B1ECD7E@txnexc01.americas.cpqcorp.net> References: <717252EC3E37AE4392E2614EA24E9F2B1ECD7E@txnexc01.americas.cpqcorp.net> Message-ID: <20020220162713.GB13253@phy.olemiss.edu> On Feb 20, VomLehn, David wrote: > The fix for this follows a well-beaten path--we are not the first > standardization body to make a mistake. Assuming there is nobody who can > find any reason for the current state of affairs, the very next release > of the LSB includes, 1) a statement that the requirement that uid and > gid be one is deprecated and will become obsolete in a future release, > 2) specify that the plan is to obsolete this requirement in the first > approved version of the LSB specification after a particular date, and > 3) deliver on item 2. Sounds reasonable enough to me, I guess. I think our main concern over on the Debian side of the aisle is that this will be a sticking point for conformance; we want to have LSB support, and we'd like to be as close as possible to full support in woody, and be fully conformant for woody+1. (Not that we officially have any woody+1 release goals beyond contining the pre-FHS symlink phaseout.) Anyway, if people on the lsb-spec list want to see how close we are to conformance (IMHO, of course ;-), the place to start is the start of the thread (lsb-spec got on a few posts in): http://lists.debian.org/debian-devel/2002/debian-devel-200202/msg01335.html and what I have so far (including a few minor fixes) is: http://people.debian.org/~lawrencc/lsb_1.1.0-2.tar.gz Chris -- Chris Lawrence - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765 From mats.d.wichmann@intel.com Wed Feb 20 18:24:23 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Wed, 20 Feb 2002 10:24:23 -0800 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <39B5C4829263D411AA93009027AE9EBB111CA00C@FMSMSX35> > On Wed, Feb 20, 2002 at 08:13:13AM -0800, Wichmann, Mats D wrote: > > It's now too late to change > > that for versions 1.0 and 1.1 of the LSB specification I didn't, actually. That was David. > Of course, the *real* lesson to learn from this is *NEVER* *EVER* to > make an official release without having a thorough round of > reviews Which there was... > and > actually resolving all the issues that're raised, no matter how long > this takes. The participants seemed to agree that there needed to be a process that included a finishing date. That process was followed, and there was plenty of room to comment. Are there going to be "bugs" in the result that are found when it's actually put into use? Of course, like with any product. From andrew@pimlott.ne.mediaone.net Wed Feb 20 18:30:43 2002 From: andrew@pimlott.ne.mediaone.net (Andrew Pimlott) Date: Wed, 20 Feb 2002 13:30:43 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220100625.G429-100000@trantor.sc.metrolink.com> References: <20020220145707.GA25873@azure.humbug.org.au> <20020220100625.G429-100000@trantor.sc.metrolink.com> Message-ID: <20020220183043.GC11521@pimlott.ne.mediaone.net> On Wed, Feb 20, 2002 at 10:15:03AM -0500, Stuart Anderson wrote: > The words in question were written well over a year ago, which is why it > is hard to recall the details. ... > I don't mind removing it, but I do mind making random, uncontrolled changes > to a document that is supposed to be stable and "controlled". My point in this > is that we need to follow a proper process in making changes like this. I guess this will come off as smart, but if it is "controlled", I would have expected someone to write down why this section was written in the first place. It sounds like the early versions were hastily slapped together (this is not the only section that gives me this impression), yet now you expect people to endure a painful process to make obviously needed amendments. Andrew From dtype@dtype.org Wed Feb 20 19:05:05 2002 From: dtype@dtype.org (M. Drew Streib) Date: Wed, 20 Feb 2002 19:05:05 +0000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220183043.GC11521@pimlott.ne.mediaone.net> References: <20020220145707.GA25873@azure.humbug.org.au> <20020220100625.G429-100000@trantor.sc.metrolink.com> <20020220183043.GC11521@pimlott.ne.mediaone.net> Message-ID: <20020220190505.GL10581@dtype.org> --mqHBVT07r4ObqsKY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 01:30:43PM -0500, Andrew Pimlott wrote: > now you expect people to endure a painful process to make obviously > needed amendments. For the sake of forward movement, I'd like to suggest that we're not far from total agreement here: 1) There may not be a good reason for requiring these users, and especially at a particular uid. 2) We should investigate why the decision was made in the first place. This is only due diligence. I would expect any distribution to do the same before making a change that _potentially_ broke expected behavior. 3) If we find that there wasn't a good reason for these users, or=20 that the reasons don't outweigh the 'brokenness' of requiring them, they should be removed via the proper methods for standards revision. Unfortunately, this isn't quite as easy as simply making the change, as the first spec revisions, like it or not, are printed and labeled. This doesn't mean that the change can't be made however. Moving forward, it would seem most productive to simply find the past discussion on this isssue, if any, then counter any decisions made in the past with the discusion from the past couple of days. It seems likely that this will result in a spec change, but=20 not pursuing at least a basic review of the facts (and history of that part of the spec, if any) would be negligent. -drew --=20 M. Drew Streib , Free Standards Group (freestandards.org) co-founder, SourceForge.net | core team, freedb | sysadmin, Linux Intl. creator, keyanalyze report | maintnr, *.us.pgp.net | other freedom/law --mqHBVT07r4ObqsKY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxz82EACgkQg2i7WWb7wYx4iQCgi9VJQTJ+OEgBtZ0yz+0g+hzO /rgAn07BXvIiWTk8TUxAqqf4uUGfeZ1e =YRVi -----END PGP SIGNATURE----- --mqHBVT07r4ObqsKY-- From anderson@metrolink.com Wed Feb 20 19:05:48 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 14:05:48 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220183043.GC11521@pimlott.ne.mediaone.net> Message-ID: <20020220135357.G429-100000@trantor.sc.metrolink.com> On Wed, 20 Feb 2002, Andrew Pimlott wrote: > I guess this will come off as smart, but if it is "controlled", I > would have expected someone to write down why this section was > written in the first place. Good point. In fact, how to maintain a rational as part of the document was discussed. At the time, it didn't seem critical to include the rational in the standards document. (You can have a good debate about wether rational is appropriate for the normative parts of a standards). Anyway, because we all learn from what we do, it now seems that having the rational would be helpful. > It sounds like the early versions were hastily slapped together > (this is not the only section that gives me this impression), There were fewer people contributing back then, so some section probably were hastily written. > yet > now you expect people to endure a painful process to make obviously > needed amendments. It doesn't have to be a painful process. I didn't mean to imply that it should be, or even that is has to be a heavy process, only that some process must be followed. Changing the document simply because write access is available is not an appropriate process. I think we've demonstrated that there is concensus that the change should be made. I agree with that. I do think that before removing or deprecating something we should make sure we understand why it was added in the first place. If the answer is that it was rushed and overlooked in the beginning, then that's fine. If there is some other reason, then we need to be sure that we have considered it. Once this is done, then we can change the wording in the spec to indicate that is is deprecated. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From lawrencc@debian.org Wed Feb 20 19:17:54 2002 From: lawrencc@debian.org (Chris Lawrence) Date: Wed, 20 Feb 2002 13:17:54 -0600 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220135357.G429-100000@trantor.sc.metrolink.com> References: <20020220183043.GC11521@pimlott.ne.mediaone.net> <20020220135357.G429-100000@trantor.sc.metrolink.com> Message-ID: <20020220191754.GB16644@phy.olemiss.edu> On Feb 20, Stuart Anderson wrote: > On Wed, 20 Feb 2002, Andrew Pimlott wrote: > > > I guess this will come off as smart, but if it is "controlled", I > > would have expected someone to write down why this section was > > written in the first place. > > Good point. In fact, how to maintain a rational as part of the document > was discussed. At the time, it didn't seem critical to include the rational > in the standards document. (You can have a good debate about wether rational > is appropriate for the normative parts of a standards). Anyway, because we > all learn from what we do, it now seems that having the rational would be > helpful. If nothing else, a rationale would help flesh things out for people doing a clean-room implementation. I for one was mystified about the init runlevel section, and also had trouble figuring out what was supposed to apply just to LSB *applications* and what applies to LSB implementations. (For example, do all init scripts on a system have to comply with LSB's specification, i.e. regarding return codes and arguments, or just the ones provided by LSB conforming applications?) Rationale would clear some of this stuff up. (i.e. "We required the status argument because some distributions have tools that depend on it." versus "We required the status argument because some applications need to learn the state of services started by init.") Chris -- Chris Lawrence - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765 From teg@redhat.com Wed Feb 20 19:31:20 2002 From: teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) Date: 20 Feb 2002 14:31:20 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220162629.GC27175@azure.humbug.org.au> References: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> <20020220162629.GC27175@azure.humbug.org.au> Message-ID: Anthony Towns writes: > On Wed, Feb 20, 2002 at 08:13:13AM -0800, Wichmann, Mats D wrote: > > It's now too late to change > > that for versions 1.0 and 1.1 of the LSB specification > > I know no one's going to actually listen to me here, but it bears > repeating: this is quite simply wrong. > > It's our spec. We can do whatever we like to it. We can declare that > packages written by people whose middle name has an odd number of > letters were never intended to comply with the specs, and issue updates > to both version 1.0 and 1.1 tomorrow to say that. No one is going to stop > us. We're not going to be thrown in prison. We're not going to have our > editors or our web pages taken away from us. > > More to the point: we're not even going to annoy anyone. Of the > distributors who've started trying to conform to the LSB, *none* of them > will have to change anything. Any application developers who've been > writing LSB packages will be pleased to have been informed of what they > have to do to make sure their programs actually run on Debian. They don't care about running on Debian - at least, they shouldn't. If they have written a program using this part of LSB 1.0, it shouldn't matter if it's Debian, Slackware or Caldera they are running on if these distribution claim to implement the standard. If they don't claim to implement it, the program isn't expected to run anyway. Any revision of the standard shouldn't go through overnight, but be in a future revision after being carefully reviewed, and a rationale for the change should be given (as it should have for being in there in the first place). > We could do this tomorrow, and _no one_ would have any cause to > complain. Anyone using it (developers, book printers, etc) would have cause. -- Trond Eivind Glomsrød Red Hat, Inc. From anderson@metrolink.com Wed Feb 20 19:48:16 2002 From: anderson@metrolink.com (Stuart Anderson) Date: Wed, 20 Feb 2002 14:48:16 -0500 (EST) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220161739.GB27175@azure.humbug.org.au> Message-ID: <20020220143012.X429-100000@trantor.sc.metrolink.com> Anthony, First off, I'd like to say that I appreciate your diligence in poking us with these issues. Because we are all human, we can only deal with so many things at once, and as a result stuff falls through the cracks. If it weren't for you and others that continue to champion these issues, we would be stuck with some bad decisions. We thought that we had things in place (such as the bug tracking system on sourceforge) to help us ensure that things didn't fall through the cracks. Apparently, though it has helped tremendously, we still have problems with this. Now, before things get completely ramped up for the next release of the spec, is a good time to examine these kinds of proceedure to see how well they have worked. Since it is obvious that they haven't, I have created and assigned to myself a Task to examing the bug processing proceedure we have used. This proceedure should be more consensus based with a few more checks and balances that we currently have. One of the known issues that we have is the lack of a proper dispute resolution mechanism. This is being worked on in a larger context, but is not yet available. Lacking a proper mechanism for this, if you can provide me the list of bug numbers that you felt were inappropriately closed or rejected, I will re-open them and ensure that they are properly addressed. Stuart Stuart R. Anderson anderson@metrolink.com Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 http://www.metrolink.com/ XFree86 Core Team From spotter@yucs.org Wed Feb 20 21:04:56 2002 From: spotter@yucs.org (Shaya Potter) Date: 20 Feb 2002 16:04:56 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220135357.G429-100000@trantor.sc.metrolink.com> References: <20020220135357.G429-100000@trantor.sc.metrolink.com> Message-ID: <1014239099.7817.123.camel@zaphod> On Wed, 2002-02-20 at 14:05, Stuart Anderson wrote: > On Wed, 20 Feb 2002, Andrew Pimlott wrote: > > > I guess this will come off as smart, but if it is "controlled", I > > would have expected someone to write down why this section was > > written in the first place. > > Good point. In fact, how to maintain a rational as part of the document > was discussed. At the time, it didn't seem critical to include the rational > in the standards document. (You can have a good debate about wether rational > is appropriate for the normative parts of a standards). Anyway, because we > all learn from what we do, it now seems that having the rational would be > helpful. rational as part of the spec document, would probably make the actuall spec a little "wordy" (not sure of the right term). There should perhaps be 2 documents, 1 would be the actual spec, the other would be the spec + rational. This would also help avoid the traditional disagreement in the meaning of the spec, as the "commentary" on the "bible" (so to speak) would be readily available :) From mats.d.wichmann@intel.com Wed Feb 20 21:52:12 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Wed, 20 Feb 2002 13:52:12 -0800 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <39B5C4829263D411AA93009027AE9EBB111CA00F@FMSMSX35> > rational as part of the spec document, would probably make the actuall > spec a little "wordy" (not sure of the right term). There should > perhaps be 2 documents, 1 would be the actual spec, the other would be > the spec + rational. This would also help avoid the traditional > disagreement in the meaning of the spec, as the "commentary" on the > "bible" (so to speak) would be readily available :) Rationale is often banished to the back of the document in an appendix, or for a large volume, to a separate document. Andrew Josey and others who've been through the mill several times can probably comment more on the reasons for including/excluding rationale. Certainly one con argument is that it makes more work since the rationale also has to have carefully crafted wording, and choices have to be made on what to include. Personally, I would have found a rationale section very useful as I came to this process quite late and the answer to certain questions seemed on occasion to be "it's in the mail archive" - which, as we've just seen from the number of posts on this thread - can mean quite a bit of work to wade through - and may sometimes be buried under a subject name that doesn't seem to relate if the dicussion has evolved. Or to put it shorter, the historical record may be accurate, but it's not necessarily concise or to the point. From aj@azure.humbug.org.au Thu Feb 21 02:36:19 2002 From: aj@azure.humbug.org.au (Anthony Towns) Date: Thu, 21 Feb 2002 12:36:19 +1000 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: References: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> <20020220162629.GC27175@azure.humbug.org.au> Message-ID: <20020221023619.GC16395@azure.humbug.org.au> --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 02:31:20PM -0500, Trond Eivind Glomsr?d wrote: > They don't care about running on Debian - at least, they shouldn't.=20 You're confused. ISV's using the LSB obviously care about running on Debian: they care about running on as many platforms as possible to increase their potential market share, either so they can make more money, or so they can be more famous. What they don't want to do is have to special case us. If they follow the LSB 1.0 or 1.1 specs, and make any use of the bin=3Duid 1 clause, then they'll find they *will* have to special case us, and that will annoy them, since the LSB's raison d'etre is to avoid that nonsense. Correcting the spec allows us to avoid annoying them. Not correcting it buys no one anything. > If > they have written a program using this part of LSB 1.0, it shouldn't > matter if it's Debian, Slackware or Caldera they are running on if > these distribution claim to implement the standard. If they don't > claim to implement it, the program isn't expected to run anyway. We're not designing this spec in a vacuum. There are real people out there with real needs that we're trying to satisfy. If we're not satisfying their needs now, we need to change it so we are. Debian is one set of such people, ISVs who want their products to run on both Red Hat and Debian are another. Our aim is to let people say "Sure, my program will run on Linux. Doesn't matter what flavour. Red Hat, SuSE, Debian, Slackware, heck, even BSD or Solaris via the compatability layers." We're not aiming to have people say "It'll run on Red Hat and SuSE. It won't run on Debian, because although that's Linux, it's not *really* Linux". Or at least, the people who I've talked to aren't. > Any revision of the standard shouldn't go through overnight,=20 > but be in a future revision after being carefully reviewed,=20 > and a rationale for > the change should be given (as it should have for being in there in > the first place). Sure. All of these things should happen. But they shouldn't be used as an excuse to delay or block a necessary change for months (like has already happened on this very issue) when the *original spec* had absolutely none of these things. > > We could do this tomorrow, and _no one_ would have any cause to > > complain. > Anyone using it (developers, book printers, etc) would have cause. All those masses of developers shipping LSB 1.0 or 1.1 compliant software? Or the masses of publishers who've already written whole chapters about why uid 1 should be the bin user, even though we can't think of even a sentence to justify it? > Trond Eivind Glomsr?d > Red Hat, Inc. Of course, I suppose Red Hat does have a market incentive to make it as difficult as possible for Debian to comply with the LSB.=20 "Oh, no, your products won't run on Debian, because those hacker wannabes can't manage to comply with simple community developed standards. Better buy Red Hat instead." So I suppose someone does have a cause to complain afterall. My mistake. Cheers, aj, who'd be much less bitter if the last seven months had resulted in pretty much anything other than "Oh, but Debian should suffer for our art too, coz Red Hat did" (Hi, Chris), or "Yes, yes, interesting point. But we must have a careful transition, and working out what that would be like is on our todo list, so please don't bother us now". --=20 Anthony Towns We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each=20 toe individually.'' -- with kudos to Greg Lehey --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHRdI+RRvX9xctrtAQGQOQP/cQgT4uZ1mPTdTwmCFJs79GIfYDj13il8 JyfLumNKqal6roI1UGyCUubRFqD4jGbcbwXzuDwUKBvxwcArifgNqHZWuODDM3+D e+vt2+tZGJgdYIfx8WL1DibFjQsLR4a9eMFl8ESHIzVxYJUS1h39H9a6iEMXRdRm 01AmA6H4on8= =ACGo -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- From shockwave@tlh.com.ar Wed Feb 20 02:48:04 2002 From: shockwave@tlh.com.ar (shockwave) Date: Tue, 19 Feb 2002 23:48:04 -0300 Subject: unsubscribe Message-ID: <003301c1b9b9$809dd440$32c80dd1@a> This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C1B99F.DFD37380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_000D_01C1B99F.DFD37380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
    ------=_NextPart_000_000D_01C1B99F.DFD37380-- From cyeoh@samba.org Thu Feb 21 02:56:25 2002 From: cyeoh@samba.org (Christopher Yeoh) Date: Thu, 21 Feb 2002 13:56:25 +1100 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020221023619.GC16395@azure.humbug.org.au> References: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> <20020220162629.GC27175@azure.humbug.org.au> <20020221023619.GC16395@azure.humbug.org.au> Message-ID: <15476.25049.578373.529666@gargle.gargle.HOWL> At 2002/2/21 12:36+1000 Anthony Towns writes: > aj, who'd be much less bitter if the last seven months had resulted in > pretty much anything other than "Oh, but Debian should suffer for > our art too, coz Red Hat did" (Hi, Chris), or "Yes, yes, interesting Er. I never said that, I just pointed out that all the distributions have had to do a fair amount of work to become compliant and Debian is not alone in this regard. Chris. -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From david-downey@codecastle.com Thu Feb 21 03:35:40 2002 From: david-downey@codecastle.com (David D.W. Downey) Date: Wed, 20 Feb 2002 19:35:40 -0800 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <15476.25049.578373.529666@gargle.gargle.HOWL> Message-ID: OK, maybe I'm an idiot here, but I've been following this thread and I have a question. WHY does the LSB even _define_ numeric UID settings? For every distrib I've used, Slackware, SuSe, Mandrake, Red Hat, Debian, Peanut, Stampede, and others, any system user (meaning system related such as bin, adm, wheel, ect ect) were always extrememly low UID numbers. This in turn signifies to the system, as stated in the POSIX standard (don't shoot me if I'm wrong, been a LONG time since I've read it), are reserved specificly for system related accounts. These accounts have the required access privileges set up before any distrib is relased, regardless of maker. So, if X for instances, needs access to the video hardware (using sys or some other system defined account) all one needs to do is set the permissions to that user. Where the API would come in is in defining the test definition for determining the right account to use, not the physical UID number. If I am way off, don't fry me, this was a quick and dirty email for the question as it popped into my head. I'm willing learn a lesson or two if I'm off. David D.W. Downey -----Original Message----- From: Christopher Yeoh [mailto:cyeoh@samba.org] Sent: Wednesday, 20 February, 2002 6:56 PM To: debian-devel@lists.debian.org; lsb-spec@lists.linuxbase.org Subject: Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package At 2002/2/21 12:36+1000 Anthony Towns writes: > aj, who'd be much less bitter if the last seven months had resulted in > pretty much anything other than "Oh, but Debian should suffer for > our art too, coz Red Hat did" (Hi, Chris), or "Yes, yes, interesting Er. I never said that, I just pointed out that all the distributions have had to do a fair amount of work to become compliant and Debian is not alone in this regard. Chris. -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia -- To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org From knghtbrd@bluecherry.net Thu Feb 21 03:40:14 2002 From: knghtbrd@bluecherry.net (Joseph Carter) Date: Wed, 20 Feb 2002 19:40:14 -0800 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020220105408.I429-100000@trantor.sc.metrolink.com> References: <20020220154732.GE16663@cibalia.gkvk.hr> <20020220105408.I429-100000@trantor.sc.metrolink.com> Message-ID: <20020221034014.GA3680@bluecherry.net> --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 10:57:49AM -0500, Stuart Anderson wrote: > > Okay, so let's summarize. This rule breaks things as it is. If we chang= e it, > > other things might break. However, nobody can think of what these other > > things are. The choice seems pretty clear, now let's start the procedur= e of > > changing. :) >=20 > OK 8-). I do feel that part of the proceedure is to understand why it was > added in the first place. The only thing worse than having it in there, w= ould > be to remove it, and then discover the hard way why it had been put in th= ere > to begin with. Thank you. It seems plainly obvious that this is necessary and I suspect not many will object to so doing, but I have come to discover that when dealing with groups you actually have to SAY these things now and then. As for how some of the users and groups LSB proposes as standard got there when nobody can seem to remember how or why, I can offer existing practice as a reason. You may recall that two of the things discussed early in the life of LSB were deployment to existing systems wherever practical and NFS shares between LSB compliant systems. The latter, I recall, was shot down for its impracticality when considering the former. They are explanation enough for a number of things I have seen reconsidered by the LSB project over the past few years. ;) I don't have old list archives handy and am currently unable to search to see if my memory happens to coincide neatly with reality yet. I doo seem to remember this very discussion taking place over this very case long ago now, so it is at least possible. =3D) --=20 Joseph Carter Hey, that's MY freak show! =20 mariab - don't think Debian hasn't had some very stupid and obvious bugs before of course, we usually fix ours BEFORE we release =3DD --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: 1024D/DCF9DAB3 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 iEYEARECAAYFAjx0bB4ACgkQj/fXo9z52rMPqACcCRU2gH9GTqdAkqIqli6oVFCI w+gAnjfARLbJW/DVl00QxCay8pCXNn46 =Fz37 -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From sesoft@263.net Thu Feb 21 05:06:15 2002 From: sesoft@263.net (sesoft@263.net) Date: Thu, 21 Feb 2002 13:06:15 +0800 Subject: ¾«µäÓªÏúÈí¼þÍƼö Message-ID: ¡ñËÑÒ׸ßËÙÓÊÖ·ËÑÑ°¼Ò[emailsearcher] ·¢²¼Ö÷Ò³£ºhttp://www.jstrade.com/ ×îа汾£ºV2.3 Èí¼þ´óС£º709KB ÎÞÐè°²×°¼´¿ÉʹÓà Ö÷Õ¾ÏÂÔØ£ºhttp://www.jstrade.com/emailsearcher/emailsearcher.exe Èí¼þÌØÉ«£º ¡ôÓòÃûµçÓÊËÑË÷£¬Ö»ÐèÊäÈëÒ»¸öºó׺Èçhotmail.com/email.com¼´¿ÉËÑË÷µçÓÊ ¡ô¸ßÆ·ÖʶàÏß³Ìģʽ£¬ÑéÖ¤ËÑË÷ËÙ¶È×î¿ì¿É´ïÿСʱ60000¸öÕæʵÓÐЧµçÓÊ ¡ôÊÖ¶¯/×Ô¶¯±£´æ½ø³Ì£¬¿ÉÖжϺó¼ÌÐøËÑË÷£¬¿ÉÍíÉÏÎÞÈËÖµÊØ£¬ÊÊÒË°üÔÂÉÏÍø ¡ô×Ô½¨×ÀÃæSMTP·þÎñÆ÷£¬¿Éµ¥·¢»òȺ·¢Îı¾/ÍøÒ³Ðżþµ½ËÑË÷ºóµÄÓÐЧÓÊÖ· ¡ôÓïÒô²Ù×÷»½ÐÑÌáʾ/×Ô¶¯¹Ò¶ÏÍøÂ磬¿ÉÓÚϵͳÍÐÅÌ´¦ºǫ́¹¤×÷£¬Ê¡Ê±Ê¡Ç® ¡ô¾«ÐıàÖÆ50Íò³£¼ûÓû§Ãû´Çµä£¬²¢ÇÒ¿É×ÔÐÐÀ©³ä£¬×î´óÌá¸ßËÑË÷×¼ÖлúÂÊ ¡ôÔùËÍ2000¸ö¹úÄÚÃâ·Ñ/µçÐÅÊÕ·ÑÓʼþ·þÎñÆ÷ºó׺£¬Èçsohu.com/263.net/µÈ ¡ô¶ÌÆÚÄÚ»ñµÃÊý°ÙÍòÕæʵ¿Í»§ÓªÏú×ÊÔ´£¬ÒÑΪºÜ¶à¹«Ë¾ºÍ¸öÈË׬ȡ·áºñÀûÈó ¡ñËÑÒ××ÀÃæÓʼþ·þÎñÆ÷[emailsender] ·¢²¼Ö÷Ò³£ºhttp://www.jstrade.com/ ×îа汾£ºV2.3 Èí¼þ´óС£º465KB ÎÞÐè°²×°¼´¿ÉʹÓà Ö÷Õ¾ÏÂÔØ£ºhttp://www.jstrade.com/emailsender/emailsender.exe Èí¼þÌØÉ«£º ¡ôÆÕͨµçÄÔ×Ô½¨SMTP·¢ËÍ·þÎñÆ÷£¬ÎÞÐèÔÙΪµçОÖ/ISP·âɱ·¢ÐÅÕʺŷ³ÄÕ ¡ô¸ßÆ·ÖʶàÏ̹߳¤×÷ģʽ£¬ÑéÖ¤·¢ÐÅËÙ¶È×î¿ì¿É´ïÿСʱ50000·âµçÓÊ ¡ôÊÖ¶¯/×Ô¶¯±£´æ½ø³Ì£¬¿ÉÖжϺó¼ÌÐø·¢ËÍ£¬¿ÉÍíÉÏÎÞÈËÖµÊØ£¬ÊÊÒË°üÔÂÉÏÍø ¡ôµ¥·¢/Ⱥ·¢¿ÉÑ¡£¬ÇáËɱà׫Îı¾/ÍøÒ³¸ñʽÐÅÌ壬֧³Ö²»ÏÞÊýÁ¿¸½¼þ·¢ËÍ ¡ôÓïÒô²Ù×÷»½ÐÑÌáʾ/×Ô¶¯¹Ò¶ÏÍøÂ磬¿ÉÓÚϵͳÍÐÅÌ´¦ºǫ́¹¤×÷£¬Ê¡Ê±Ê¡Ç® ¡ô¶ÔÿһÓÊÖ·ÌØ¿ì·¢ÐÅ£¬×Ô¶¯·ÖÀë·¢Ëͳɹ¦/ʧ°ÜµçÓÊ£¬ÇáËÉɸѡÓʼþÁбí¿â ¡ô¹úÄÚ¶à¼ÒÖªÃûµç×ÓÉÌÎñ¹«Ë¾Ñ¡Óã¬ÊÇÍƹãÍøÕ¾ºÍ¿ªÕ¹ÍøÉϹã¸æµÄ¾ø¼Ñ¹¤¾ß From schilling@fokus.gmd.de Thu Feb 21 12:12:03 2002 From: schilling@fokus.gmd.de (Joerg Schilling) Date: Thu, 21 Feb 2002 13:12:03 +0100 (CET) Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package Message-ID: <200202211212.g1LCC3oM001540@burner.fokus.gmd.de> >From: "David D.W. Downey" >WHY does the LSB even _define_ numeric UID settings? For every distrib I've >used, Slackware, SuSe, Mandrake, Red Hat, Debian, Peanut, Stampede, and >others, any system user (meaning system related such as bin, adm, wheel, ect >ect) were always extrememly low UID numbers. This in turn signifies to the >system, as stated in the POSIX standard (don't shoot me if I'm wrong, been a >LONG time since I've read it), are reserved specificly for system related >accounts. These accounts have the required access privileges set up before >any distrib is relased, regardless of maker. So, if X for instances, needs >access to the video hardware (using sys or some other system defined >account) all one needs to do is set the permissions to that user. Let me do a second try... If you believe that there is no need to garantee people to NFS mount /usr or anything that comes SUID/SGID to one of the system accounts, you don't need to specify numeric id's for anything than root. However, not specifying the numeric ID for "nobody" will introduce a big potential security problem when old (outdated) program implementations like gnutar or pax try to unpack TAR archives that conform to POSIX-2001 and hold users with numeric IDs > 2097151 whily unpacking based on numeric IDs (e.g. because the the passwd file is missing the right entries). Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From kukuk@suse.de Thu Feb 21 15:07:41 2002 From: kukuk@suse.de (Thorsten Kukuk) Date: Thu, 21 Feb 2002 16:07:41 +0100 Subject: Bug in spec: tty has tr options Message-ID: <20020221160741.A9975@suse.de> Hi, the LSB 1.1 spec seems to have a bug: The options described for tty are the one for tr. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrenstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B From alan@lxorguk.ukuu.org.uk Thu Feb 21 15:28:02 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Thu, 21 Feb 2002 15:28:02 +0000 (GMT) Subject: Bug in spec: tty has tr options In-Reply-To: <20020221160741.A9975@suse.de> from "Thorsten Kukuk" at Feb 21, 2002 04:07:41 PM Message-ID: > the LSB 1.1 spec seems to have a bug: The options described for tty > are the one for tr. Oops. I guess nobody can be compliant for two years while we obsolete it 8) From teg@redhat.com Thu Feb 21 20:10:57 2002 From: teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) Date: 21 Feb 2002 15:10:57 -0500 Subject: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package In-Reply-To: <20020221023619.GC16395@azure.humbug.org.au> References: <39B5C4829263D411AA93009027AE9EBB111CA009@FMSMSX35> <20020220162629.GC27175@azure.humbug.org.au> <20020221023619.GC16395@azure.humbug.org.au> Message-ID: Anthony Towns writes: > On Wed, Feb 20, 2002 at 02:31:20PM -0500, Trond Eivind Glomsrød wrote: > > They don't care about running on Debian - at least, they shouldn't. > > You're confused. > > ISV's using the LSB obviously care about running on Debian: they care about > running on as many platforms as possible to increase their potential market > share, either so they can make more money, or so they can be more > famous. My point it they shouldn't have to care about distribution specific items, issues coming from Debian or anyone else. One of the main goals of LSB is to isolate the developers from this. > What they don't want to do is have to special case us. If they follow > the LSB 1.0 or 1.1 specs, and make any use of the bin=uid 1 clause, then > they'll find they *will* have to special case us, and that will annoy > them, since the LSB's raison d'etre is to avoid that nonsense. Correcting > the spec allows us to avoid annoying them. Not correcting it buys no > one anything. It's not a bug, it's a "why the ???? did this feature get added?" issue, which also highlights the necessity of documenting _why_ things are put into the standard. A specific release of particular distribution not conforming to the LSB standard is not an LSB bug. > > If they have written a program using this part of LSB 1.0, it > > shouldn't matter if it's Debian, Slackware or Caldera they are > > running on if these distribution claim to implement the > > standard. If they don't claim to implement it, the program isn't > > expected to run anyway. > > We're not designing this spec in a vacuum. There are real people out there > with real needs that we're trying to satisfy. If we're not satisfying > their needs now, we need to change it so we are. Debian is one set of > such people, ISVs who want their products to run on both Red Hat and > Debian are another. Debian not complying with LSB is not much of LSB need, it's a Debian need if they want to comply. > Our aim is to let people say "Sure, my program will run on Linux. Doesn't > matter what flavour. Red Hat, SuSE, Debian, Slackware, heck, even BSD > or Solaris via the compatability layers." We're not aiming to have > people say "It'll run on Red Hat and SuSE. It won't run on Debian, > because although that's Linux, it's not *really* Linux". Or at least, > the people who I've talked to aren't. Then Debian could fix it if they want to comply with the standard. > > Any revision of the standard shouldn't go through overnight, but > > be in a future revision after being carefully reviewed, and a > > rationale for the change should be given (as it should have for > > being in there in the first place). > > Sure. All of these things should happen. But they shouldn't be used as an > excuse to delay or block a necessary change for months (like has already > happened on this very issue) when the *original spec* had absolutely > none of these things. Changes should not get silently and quickly put in, unless they're typos or similar. > > > We could do this tomorrow, and _no one_ would have any cause to > > > complain. Anyone using it (developers, book printers, etc) > > > would have cause. > > All those masses of developers shipping LSB 1.0 or 1.1 compliant software? > Or the masses of publishers who've already written whole chapters about > why uid 1 should be the bin user, even though we can't think of even a > sentence to justify it? Or just printing the standard? One thing is having a 1.0.1 with this removed, but you don't just silently revise a standard. If I pick it up in print, I want 1.0 to be 1.0. Not one of a couple of 1.0s. > > Trond Eivind Glomsrød > > Red Hat, Inc. > > Of course, I suppose Red Hat does have a market incentive to make it > as difficult as possible for Debian to comply with the LSB. > > "Oh, no, your products won't run on Debian, because those hacker wannabes > can't manage to comply with simple community developed standards. Better > buy Red Hat instead." > > So I suppose someone does have a cause to complain afterall. My mistake. That's just stupid. > Cheers, > aj, who'd be much less bitter if the last seven months had resulted in > pretty much anything other than "Oh, but Debian should suffer for > our art too, coz Red Hat did" (Hi, Chris) Minimal suffering for everyone is a good thing. -- Trond Eivind Glomsrød Red Hat, Inc. From gk4@austin.ibm.com Fri Feb 22 16:19:31 2002 From: gk4@austin.ibm.com (George Kraft IV) Date: Fri, 22 Feb 2002 10:19:31 -0600 Subject: LSB Users & Groups References: Message-ID: <3C766F93.1B09F374@austin.ibm.com> Okay, I must take the credit, or blame for the LSB's initial Users & Groups section and its maintenance. :-) In December of 1999 I took the action item to investigate users & groups APIs, commands, user names, group names, uids, & gids. http://lists.debian.org/lsb-spec/2000/lsb-spec-200001/msg00056.html >From that list we sorted out what was to be standardized and what was to be left out. The LSB's ABI and command tables were updated accordingly, then the rest was discussed at workgroup & telephone conference meetings, and via email. We should all agree that root=0, and systems require the "bin" and "daemon" mnemonic user and group names. In retrospect, I guess if few programs/services are hardcoding 1, then they are wrong and specifying bin or daemon equal to 1 would be worse. :-) I agree that our processes need to be more systematic and/or precise. We will fix this ASAP and run "bin=1" and tty(1) through the process. http://www.linuxbase.org/spec/gLSB/gLSB/usernames.html http://www.linuxbase.org/spec/gLSB/gLSB/tty.html I appreciate everyone's constructive participation. Sincerely, George Kraft IV gk4@austin.ibm.com Senior Software Engineer IBM Linux Technology Center Chair of the LSB From wichert@wiggy.net Fri Feb 22 16:39:15 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Fri, 22 Feb 2002 17:39:15 +0100 Subject: LSB Users & Groups In-Reply-To: <3C766F93.1B09F374@austin.ibm.com> References: <3C766F93.1B09F374@austin.ibm.com> Message-ID: <20020222163915.GH6817@wiggy.net> Previously George Kraft IV wrote: > We should all agree that root=0, and systems require the "bin" and "daemon" > mnemonic user and group names. I would still like to see a rationale for requiring bin and daemon, they do not seem to serve any purpose. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From mstone@debian.org Fri Feb 22 16:59:37 2002 From: mstone@debian.org (Michael Stone) Date: Fri, 22 Feb 2002 11:59:37 -0500 Subject: LSB Users & Groups In-Reply-To: <3C766F93.1B09F374@austin.ibm.com>; from gk4@austin.ibm.com on Fri, Feb 22, 2002 at 10:19:31AM -0600 References: <3C766F93.1B09F374@austin.ibm.com> Message-ID: <20020222115937.R14610@justice.loyola.edu> --Fnm8lRGFTVS/3GuM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2002 at 10:19:31AM -0600, George Kraft IV wrote: > http://lists.debian.org/lsb-spec/2000/lsb-spec-200001/msg00056.html >=20 > From that list we sorted out what was to be standardized and what was to = be left > out. The LSB's ABI and command tables were updated accordingly, then the= rest > was discussed at workgroup & telephone conference meetings, and via email. So this debacle was caused by bad data? (bin and daemon are reversed for, at least, D5) > We should all agree that root=3D0, and systems require the "bin" and "dae= mon" > mnemonic user and group names Why? (not the root part ;-) --=20 Mike Stone --Fnm8lRGFTVS/3GuM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHZ4+Q0hVr09l8FJAQFHrAQAxldmvj4eVHW+PR+xCOsx+kgrdpyOuDm2 SRI514V1nG7AHgkunOhKLCNo6efl7vbezY/bHbWLV0bsdil56CrCEEat5168Zoql KIbCo1NaRZAyhhcK8jlw+kqhev2kqSeEUpH/d7IogWULXMpZP1tdqIv28PQzVnmt eNXuW3yGp/E= =3Fub -----END PGP SIGNATURE----- --Fnm8lRGFTVS/3GuM-- From gk4@austin.ibm.com Fri Feb 22 17:22:33 2002 From: gk4@austin.ibm.com (George Kraft IV) Date: Fri, 22 Feb 2002 11:22:33 -0600 Subject: LSB Users & Groups References: <3C766F93.1B09F374@austin.ibm.com> <20020222163915.GH6817@wiggy.net> Message-ID: <3C767E59.B3E923D5@austin.ibm.com> Wichert Akkerman wrote: > > Previously George Kraft IV wrote: > > We should all agree that root=0, and systems require the "bin" and "daemon" > > mnemonic user and group names. > > I would still like to see a rationale for requiring bin and daemon, they > do not seem to serve any purpose. > The thought was that some applications (and/or shell scripts) could/would fail if root.root, bin.bin, and daemon.daemon did not exist on a system; however, the other user and group names in the optional table below are just suggested. http://www.linuxbase.org/spec/gLSB/gLSB/usernames.html In short, the LSB v1.1.0 specification requires: root.root = 0 bin.bin = 1 daemon.daemon However, we've had a long discussion regarding bin = 1, and we will address that. :-) George (gk4) From wichert@wiggy.net Fri Feb 22 17:43:12 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Fri, 22 Feb 2002 18:43:12 +0100 Subject: LSB Users & Groups In-Reply-To: <3C767E59.B3E923D5@austin.ibm.com> References: <3C766F93.1B09F374@austin.ibm.com> <20020222163915.GH6817@wiggy.net> <3C767E59.B3E923D5@austin.ibm.com> Message-ID: <20020222174312.GJ6817@wiggy.net> Previously George Kraft IV wrote: > The thought was that some applications (and/or shell scripts) > could/would fail if root.root, bin.bin, and daemon.daemon did not > exist on a system That doesn't answer my question though. There is no (documented or otherwise) reason for bin and daemon existing. Nobody seems to know what to use them for and I haven't ever seen anything that uses them. Leaving them in LSB can only lead to different possibly conflicting kinds of usage for those accounts which does not help at all. The thought that an application might break also wasn't valid: applications can break due to any difference between LSB and existing systems, so if you follow that argument the LSB would have to document every possible existing Linux system or an application just might break. If an application does need an account for a special reason it can always create a system account for itself and use that. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From frankie@debian.org Fri Feb 22 18:07:14 2002 From: frankie@debian.org (Francesco P. Lovergine) Date: Fri, 22 Feb 2002 19:07:14 +0100 Subject: LSB Users & Groups In-Reply-To: <20020222174312.GJ6817@wiggy.net> References: <3C766F93.1B09F374@austin.ibm.com> <20020222163915.GH6817@wiggy.net> <3C767E59.B3E923D5@austin.ibm.com> <20020222174312.GJ6817@wiggy.net> Message-ID: <20020222180714.GB10351@localhost.localdomain> On Fri, Feb 22, 2002 at 06:43:12PM +0100, Wichert Akkerman wrote: > Previously George Kraft IV wrote: > > The thought was that some applications (and/or shell scripts) > > could/would fail if root.root, bin.bin, and daemon.daemon did not > > exist on a system > > That doesn't answer my question though. There is no (documented or > otherwise) reason for bin and daemon existing. Nobody seems to know > what to use them for and I haven't ever seen anything that uses them. > > Leaving them in LSB can only lead to different possibly conflicting > kinds of usage for those accounts which does not help at all. > > The thought that an application might break also wasn't valid: applications > can break due to any difference between LSB and existing systems, > so if you follow that argument the LSB would have to document every > possible existing Linux system or an application just might break. > > If an application does need an account for a special reason it can > always create a system account for itself and use that. > > Wichert. > Completely agree. Those accounts exist for hystorical reasons in other unices. I see no real rationale to require their existence in debian nowdays. -- Francesco P. Lovergine From Martijn van Oosterhout Fri Feb 22 21:50:54 2002 From: Martijn van Oosterhout (Martijn van Oosterhout) Date: Sat, 23 Feb 2002 08:50:54 +1100 Subject: LSB Users & Groups In-Reply-To: <20020222174312.GJ6817@wiggy.net>; from wichert@wiggy.net on Fri, Feb 22, 2002 at 06:43:12PM +0100 References: <3C766F93.1B09F374@austin.ibm.com> <20020222163915.GH6817@wiggy.net> <3C767E59.B3E923D5@austin.ibm.com> <20020222174312.GJ6817@wiggy.net> Message-ID: <20020223085054.C3466@svana.org> On Fri, Feb 22, 2002 at 06:43:12PM +0100, Wichert Akkerman wrote: > Previously George Kraft IV wrote: > > The thought was that some applications (and/or shell scripts) > > could/would fail if root.root, bin.bin, and daemon.daemon did not > > exist on a system > > That doesn't answer my question though. There is no (documented or > otherwise) reason for bin and daemon existing. Nobody seems to know > what to use them for and I haven't ever seen anything that uses them. Actually, on my debian unstable system here: daemon 111 0.0 0.3 1416 464 ? S 08:21 0:00 /sbin/portmap daemon 290 0.0 0.4 1420 608 ? S 08:21 0:00 /usr/sbin/atd So they are used and we can't summarily remove them. These could be shunted to another user, but which one? They *are* daemons. -- Martijn van Oosterhout http://svana.org/kleptog/ > If the company that invents a cure for AIDS is expected to make their > money back in 17 years, why can't we ask the same of the company that > markets big-titted lip-syncing chicks and goddamn cartoon mice? From wichert@wiggy.net Fri Feb 22 23:13:10 2002 From: wichert@wiggy.net (Wichert Akkerman) Date: Sat, 23 Feb 2002 00:13:10 +0100 Subject: LSB Users & Groups In-Reply-To: <20020223085054.C3466@svana.org> References: <3C766F93.1B09F374@austin.ibm.com> <20020222163915.GH6817@wiggy.net> <3C767E59.B3E923D5@austin.ibm.com> <20020222174312.GJ6817@wiggy.net> <20020223085054.C3466@svana.org> Message-ID: <20020222231309.GN6817@wiggy.net> Previously Martijn van Oosterhout wrote: > Actually, on my debian unstable system here: > > daemon 111 0.0 0.3 1416 464 ? S 08:21 0:00 /sbin/portmap > daemon 290 0.0 0.4 1420 608 ? S 08:21 0:00 /usr/sbin/atd That's a bug, they should create their own user and use that instead. Wichert. -- _________________________________________________________________ /wichert@wiggy.net This space intentionally left occupied \ | wichert@deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From lawrencc@debian.org Mon Feb 25 04:22:00 2002 From: lawrencc@debian.org (Chris Lawrence) Date: Sun, 24 Feb 2002 22:22:00 -0600 Subject: LSB package for Debian: final(?) release candidate In-Reply-To: <15473.45447.699122.380451@gargle.gargle.HOWL> References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> Message-ID: <20020225042200.GA24546@bellsouth.net> FYI: I have a release candidate of the lsb package (version 1.1.0-3) available at: http://people.debian.org/~lawrencc/ Matt Taggart and I had an off-list discussion about what should be in the package, and this is the culmination of that work. Again, we'd like to see an LSB package that uses the init functionality so we can test our implementation. (The apache package *could*, but the prerm and postinst scripts appear to be Red Hat scripts with all the actions commented out.) Chris -- Chris Lawrence - http://www.lordsutch.com/chris/ From news@ccid-mrd.com.cn Tue Feb 26 05:07:39 2002 From: news@ccid-mrd.com.cn (news) Date: Tue, 26 Feb 2002 13:07:39 0800 Subject: 2002 CCID semiconductor industrial & market ANNAL reports Message-ID: <1014700059.40@com.cn> --_========_000000510_========_ Content-Type: text/plain; charset=""; format=flowed WELCOME TO ORDER 2002 CCID semiconductor Reports £¨For more information please visit our website WWW.CCID-MRD.COM.CN£© 1.A Review of 2001 China IC Industry & a Forecast on 2002-2005 2.A Review of 2001 China IC Market and a Forecast on 2002-2005 3.An Analysis of 2001 China IC Imports and Exports & a Forecast on 2002-2005 4. A Review of 2001 China Discrete Devices Industry & A Forecast on 2002-2005 5. An Analysis of 2001 China Export & Import of Discrete Devices & A Forecast on 2002-2005 6.A review of 2001 china¡¯s IC Market (by Catalogue) & a forecast on 2002-2005 7.A Review of China's 2001 Computer IC & a Forecast on 2002-2005 8.A Review of 2001 China Consumer IC & a Forecast on 2002-2005 9.A Review of 2001 China Telecommunication IC & a Forecast on 2002-2005 10.A Review of 2001 China IC Card and a Forecast on 2002-2005 11.A Review of 2001 China Memory and a Forecast on 2002-2005 12.A Review of 2001 China Analog Circuit and a Forecast on 2002-2005 13.A Review of 2001 China Power IC and a Forecast on 2002-2005 14.A Review of 2001 China DSP and a Forecast on 2002-2005 15.A Review of 2001 China MCU and a Forecast on 2002-2005 16.A Review of 2001 China Power IC and a Forecast on 2002-2005 17.A Review of 2001 China AD/DA and a Forecast on 2002-2005 18.MNCs Electronic Corporations In China: Investment, Marketing, And Trends 19.semiconductor MNCs in china: 2002 Edition Chinese only 34.A Survey of 2001 China Semiconductor's distribution market 20.A Review of 2001 China Semiconductor Equipment and Instruments and a Forecast on 2002-2005 22.A Review of 2001 China Electronic products and a Forecast on 2002-2005 23.A Review of 2001 China Semiconductor Industry Special Materials & A Forecast on 2002-2005 24.A Review of 2001 China Semiconductor Packaging materials and a Forecast on 2002-2005 25.A Review of 2001 World Semiconductor and a Forecast on 2002-2005 26.Research on China IC Industry Policy 27.2001 China IC Industry Annual Report£¨2002 Edition£© 31.China Semiconductor Information ( one edition per quarter) 33.2001 China Semiconductor Industry Association (CSIA) Member Directory 21.A Review of 2001 China LCD device and a Forecast on 2002-200529.A Review of 2001 China LED device and a Forecast on 2002-2005 30.A Review of China PCB Industry and market and forecast 32.A Review of China Connector Industry and market and forecast 1. 2001 China SMT Device Industry and Market: A Review & A Forecast 2. 2001 China SMT Equipment Industry and Market: A Review & A Forecast 3. 2001 China UPS Industry: A Review & A Forecast 4. 2001 China Transformer, Inductor and Ballast Industry and Market: A Review & A Forecast 5. 2001 China Primary Battery and Storage Battery Industry and Market: A Review & A Forecast 6. 2001 China Speaker and Headphone Industry and Market: A Review & A Forecast 7. 2001 China Switch, Plug and Outlet Industry and Market: A Review & A Forecast 8. 2001 China Magnetic Head Device Industry and Market: A Review & A Forecast 9. 2001 China Eletromagnet and Permanent Magnet Industry and Market: A Review & A Forecast 10. CCID Semiconductor Information£¨One Edition per three month£© 11. A survey of 2001 China Sparking Plug, Ignition Magnetos and Permanent DC Generator 12. 2001 China Buzzer Industry and Market: A Review & A Forecast 13. 2001 China Electric Relay Industry and Market: A Review & A Forecast 14. 2001 China Cathode Ray Tube Industry and Market: A Review & A Forecast 15. 2001 China insulated wire, cable and optical cable Industry and Market: A Review & A Forecast 16. 2001 China Carbon Electrode and Insulator Industry and Market: A Review & A Forecast 17. 2001 China Film Camera and Projector Industry and Market: A Review & A Forecast 18. 2001 China Electrical Fan, Air Conditioning and Dryer Industry and Market: A Review & A Forecast 19. 2001 China Auto Washing Machine and Clothes Dryer Industry and Market: A Review & A Forecast 20. 2001 China Dishwashing Machine (domestic household) Industry and Market: A Review & A Forecast 21. 2001 China Electrical Scale Industry and Market: A Review & A Forecast 22. 2001 China Embroider machine Industry and Market: A Review & A Forecast 23. 2001 China Calculating Machine Industry and Market: A Review & A Forecast 24. 2001 China Electronic Equipment for Kitchen Industry and Market: A Review & A Forecast 25. 2001 China Electric Razor Industry and Market: A Review & A Forecast 26. 2001 China Water Heater Industry and Market: A Review & A Forecast 27. 2001 China Electrical Hair Dressing Tool Industry and Market: A Review & A Forecast 28. 2001 China Electric Iron Industry and Market: A Review & A Forecast 29. 2001 China Radio Sets, Tape Recorder and Audio Industry and Market: A Review & A Forecast 30. 2001 China VF Megaphone Industry and Market: A Review & A Forecast 31. 2001 China Satellite Ground Station for TV Industry and Market: A Review & A Forecast 32. 2001 China VCD and DVD Industry and Market: A Review & A Forecast 33. 2001 China Set Top Box Industry and Market: A Review & A Forecast 34. 2001 China Telecamera Industry and Market: A Review & A Forecast 35. 2001 China Television Set Industry and Market: A Review & A Forecast 36. 2001 China Camera Industry and Market: A Review & A Forecast 37. 2001 China Audiphone Industry and Market: A Review & A Forecast 38. 2001 China Electric Watch and Timer Industry and Market: A Review & A Forecast 39. 2001 China Musical Instrument Industry and Market: A Review & A Forecast 40. 2001 China Video Game Machine Industry and Market: A Review & A Forecast 41. 2001 China Tape and Record Industry and Market: A Review & A Forecast 42. 2001 China Toys Motor Industry and Market: A Review & A Forecast 43. 2001 China Printer Industry and Market: A Review & A Forecast 44. 2001 China Cash Register and Sales Terminal Register Industry and Market: A Review & A Forecast 45. 2001 China Postage Stamper and Booking Machine Industry and Market: A Review & A Forecast 46. 2001 China Display Industry and Market: A Review & A Forecast 47. 2001 China Scanner Industry and Market: A Review & A Forecast 48. 2001 China Keyboard and Mouse Industry and Market: A Review & A Forecast 49. 2001 China Digital Equipment Industry and Market: A Review & A Forecast 50. 2001 China Storage Block Industry and Market: A Review & A Forecast 51. 2001 China Hardpan, Floppy Disc and Driver Industry and Market: A Review & A Forecast 52. 2001 China Money-Draw Machine Industry and Market: A Review & A Forecast 53. 2001 China Voltage-stabilized Source Industry and Market: A Review & A Forecast 54. 2001 China Disc and Magnetic Card Industry and Market: A Review & A Forecast 55. 2001 China Computer Software Industry and Market: A Review & A Forecast 56. 2001 China Telephone Industry and Market: A Review & A Forecast 57. 2001 China FAX Industry and Market: A Review & A Forecast 58. 2001 China Program-Controlled Exchange Industry and Market: A Review & A Forecast 59. 2001 China Optical Transmission Equipment Industry and Market: A Review & A Forecast 60. 2001 China IP Telephone Signal Converter Industry and Market: A Review & A Forecast 61. 2001 China Concentrator and Indicator Industry and Market: A Review & A Forecast 62. 2001 China Modem Industry and Market: A Review & A Forecast 63. 2001 China Facsimile Signal Sensor Industry and Market: A Review & A Forecast 64. 2001 China Walkie-Talkie Industry and Market: A Review & A Forecast 65. 2001 China Mobile Phone and Beeper Industry and Market: A Review & A Forecast 66. 2001 China Fibre-Optical Communication and Fibre-Optical Property tester Industry and Market: A Review & A Forecast 67. 2001 China Duplicator Industry and Market: A Review & A Forecast 68. 2001 China Mail Processor Industry and Market: A Review & A Forecast 69. 2001 China Paper-cutting Machine Industry and Market: A Review & A Forecast 70. 2001 China Auto Vending Machine Industry and Market: A Review & A Forecast 71. 2001 China Portal Electric Tool Industry and Market: A Review & A Forecast 72. 2001 China Sewing Machine Industry and Market: A Review & A Forecast 73. 2001 China Photo Enlarger and Reduction Printer Industry and Market: A Review & A Forecast 74. 2001 China Slide Projector Industry and Market: A Review & A Forecast 75. 2001 China Plotter Equipment Industry and Market: A Review & A Forecast 76. 2001 China Electric Lighting and Signal Equipment Industry and Market: A Review & A Forecast 77. 2001 China Electric Dry Oven and Heater Industry and Market: A Review & A Forecast 78. 2001 China Boarding Machine Industry and Market: A Review & A Forecast 79. 2001 China Traffic Control Equipment Industry and Market: A Review & A Forecast 80. 2001 China Warning Device Industry and Market: A Review & A Forecast 81. 2001 China Navigation Radio Facilities Industry and Market: A Review & A Forecast 82. 2001 China Metal-Mine detector Industry and Market: A Review & A Forecast 83. 2001 China Precipitator Industry and Market: A Review & A Forecast 84. 2001 China Injection Machine, Plastic Comminutor and Industry and Market: A Review & A Forecast 85. 2001 China Set Microscope Industry and Market: A Review & A Forecast 86. 2001 China Locating Compass Industry and Market: A Review & A Forecast 87. 2001 China rangefinder Industry and Market: A Review & A Forecast 88. 2001 China Barostat and Thermostat Industry and Market: A Review & A Forecast 89. 2001 China Machine Tools Industry and Market: A Review & A Forecast 90. 2001 China Automobile Equipment Industry and Market: A Review & A Forecast 91. 2001 China Medical Equipment Industry and Market: A Review & A Forecast 92. 2001 China Gasmeter, Watermeter and Eletrometer Industry and Market: A Review & A Forecast 93. 2001 China Odometer and Velograph Industry and Market: A Review & A Forecast 94. 2001 China Ammeter,Voltmeter and Multimeter Industry and Market: A Review & A Forecast 95. 2001 China OSC Industry and Market: A Review & A Forecast 96. 2001 China Resistance Tester Industry and Market: A Review & A Forecast Name: China Center of Information Industry Development(CCID) Microelectronics Reserch Department(MRD) Address£ºChina Semiconductor Industry Association.27,Rd.wanshoulu PC£º100846 Website£ºwww.ccid-mrd.com.cn EMAIL: guoyiran@ccid-mrd.com.cn NEWS@ccid-mrd.com.cn TEL: 86-10-68208592, 86-10-68208589 Fax: 86-10-68208590 , 86-10-68208594 Contact:¡¡Guo Yiran (¹ùÒãÈ») , Louisa Lv(ÂÀÕÜ) , Lydie Li(Àî°®»ª) --_========_000000510_========_ Content-Type: application/octet-stream; name="Information of China IC Market by CCID.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Information of China IC Market by CCID.htm" PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIg0K eG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCINCnhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVx dWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9R0IyMzEyIj4NCjxt ZXRhIG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9R2VuZXJh dG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDkiPg0KPG1ldGEgbmFtZT1PcmlnaW5hdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDkiPg0KPGxpbmsgcmVsPUZpbGUtTGlzdA0KaHJlZj0iLi9J bmZvcm1hdGlvbiUyMG9mJTIwQ2hpbmElMjBJQyUyME1hcmtldCUyMGJ5JTIwQ0NJRC5maWxlcy9m aWxlbGlzdC54bWwiPg0KPHRpdGxlPldFTENPTUUgVE8gT1JERVIgMjAwMiBDQ0lEIHNlbWljb25k dWN0b3IgUmVwb3J0czwvdGl0bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpEb2N1 bWVudFByb3BlcnRpZXM+DQogIDxvOkF1dGhvcj56ZW5nemhlbjwvbzpBdXRob3I+DQogIDxvOlRl bXBsYXRlPk5vcm1hbDwvbzpUZW1wbGF0ZT4NCiAgPG86TGFzdEF1dGhvcj5haWh1YTwvbzpMYXN0 QXV0aG9yPg0KICA8bzpSZXZpc2lvbj4yPC9vOlJldmlzaW9uPg0KICA8bzpUb3RhbFRpbWU+Mjwv bzpUb3RhbFRpbWU+DQogIDxvOkNyZWF0ZWQ+MjAwMi0wMi0yNVQwMToyMzowMFo8L286Q3JlYXRl ZD4NCiAgPG86TGFzdFNhdmVkPjIwMDItMDItMjVUMDE6MjM6MDBaPC9vOkxhc3RTYXZlZD4NCiAg PG86UGFnZXM+NTwvbzpQYWdlcz4NCiAgPG86V29yZHM+MTU0ODwvbzpXb3Jkcz4NCiAgPG86Q2hh cmFjdGVycz44ODI2PC9vOkNoYXJhY3RlcnM+DQogIDxvOkNvbXBhbnk+bXJkPC9vOkNvbXBhbnk+ DQogIDxvOkxpbmVzPjczPC9vOkxpbmVzPg0KICA8bzpQYXJhZ3JhcGhzPjE3PC9vOlBhcmFncmFw aHM+DQogIDxvOkNoYXJhY3RlcnNXaXRoU3BhY2VzPjEwODM4PC9vOkNoYXJhY3RlcnNXaXRoU3Bh Y2VzPg0KICA8bzpWZXJzaW9uPjkuMjgxMjwvbzpWZXJzaW9uPg0KIDwvbzpEb2N1bWVudFByb3Bl cnRpZXM+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpX b3JkRG9jdW1lbnQ+DQogIDx3OlB1bmN0dWF0aW9uS2VybmluZy8+DQogIDx3OkRyYXdpbmdHcmlk VmVydGljYWxTcGFjaW5nPjcuOCCw9TwvdzpEcmF3aW5nR3JpZFZlcnRpY2FsU3BhY2luZz4NCiAg PHc6RGlzcGxheUhvcml6b250YWxEcmF3aW5nR3JpZEV2ZXJ5PjA8L3c6RGlzcGxheUhvcml6b250 YWxEcmF3aW5nR3JpZEV2ZXJ5Pg0KICA8dzpEaXNwbGF5VmVydGljYWxEcmF3aW5nR3JpZEV2ZXJ5 PjI8L3c6RGlzcGxheVZlcnRpY2FsRHJhd2luZ0dyaWRFdmVyeT4NCiAgPHc6Q29tcGF0aWJpbGl0 eT4NCiAgIDx3OlNwYWNlRm9yVUwvPg0KICAgPHc6QmFsYW5jZVNpbmdsZUJ5dGVEb3VibGVCeXRl V2lkdGgvPg0KICAgPHc6RG9Ob3RMZWF2ZUJhY2tzbGFzaEFsb25lLz4NCiAgIDx3OlVMVHJhaWxT cGFjZS8+DQogICA8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCiAgIDx3OkFkanVzdExpbmVI ZWlnaHRJblRhYmxlLz4NCiAgIDx3OlVzZUZFTGF5b3V0Lz4NCiAgPC93OkNvbXBhdGliaWxpdHk+ DQogPC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6y87M5TsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWFsdDpTaW1TdW47DQoJ bXNvLWZvbnQtY2hhcnNldDoxMzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCglt c28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MyAxMzUxMzUyMzIg MTYgMCAyNjIxNDUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcMDAwQgwiOw0KCXBh bm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtYWx0OiJUaW1lcyBOZXcgUm9t YW4iOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpyb21h bjsNCgltc28tZm9udC1mb3JtYXQ6b3RoZXI7DQoJbXNvLWZvbnQtcGl0Y2g6YXV0bzsNCgltc28t Zm9udC1zaWduYXR1cmU6MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEDLzszlIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWNoYXJz ZXQ6MTM0Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6 dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjEgMTM1MTM1MjMyIDE2IDAgMjYyMTQ0IDA7 fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTpp bnRlci1pZGVvZ3JhcGg7DQoJbXNvLXBhZ2luYXRpb246bm9uZTsNCglmb250LXNpemU6MTAuNXB0 Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6y87M5TsNCgltc28tZm9udC1rZXJuaW5n OjEuMHB0O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6IzY2MDAwMDsNCglt c28tdGV4dC1hbmltYXRpb246bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZTsNCgl0ZXh0LXVu ZGVybGluZTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lOw0KCXRleHQtbGluZS10aHJvdWdo Om5vbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmds ZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlm eTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCW1zby1wYWdpbmF0aW9uOm5vbmU7 DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseTrLzszlOw0KCW1zby1oYW5zaS1mb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJbXNvLWZvbnQta2VybmluZzoxLjBwdDt9DQpwDQoJe21hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OsvOzOU7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KIC8qIFBhZ2UgRGVmaW5pdGlvbnMgKi8NCkBwYWdlDQoJe21zby1w YWdlLWJvcmRlci1zdXJyb3VuZC1oZWFkZXI6bm87DQoJbXNvLXBhZ2UtYm9yZGVyLXN1cnJvdW5k LWZvb3Rlcjpubzt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCglt YXJnaW46NzIuMHB0IDkwLjk1cHQgNzIuMHB0IDkwLjlwdDsNCgltc28taGVhZGVyLW1hcmdpbjo0 Mi41NXB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjQ5LjZwdDsNCgltc28tcGFwZXItc291cmNlOjA7 DQoJbGF5b3V0LWdyaWQ6MTUuNnB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30N Ci0tPg0KPC9zdHlsZT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1aSC1DTiBsaW5rPSIjNjYwMDAw IiB2bGluaz1wdXJwbGUgc3R5bGU9J3RhYi1pbnRlcnZhbDoyMS4wcHQ7DQp0ZXh0LWp1c3RpZnkt dHJpbTpwdW5jdHVhdGlvbic+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjEgc3R5bGU9J2xheW91dC1n cmlkOjE1LjZwdCc+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFz XT4mbmJzcDs8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGI+PHNwYW4N Cmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEw LjVwdDttc28taGFuc2ktZm9udC1mYW1pbHk6DQrLzszlO2NvbG9yOmJsdWUnPldFTENPTUUgVE8g T1JERVIgMjAwMiBDQ0lEIHNlbWljb25kdWN0b3IgUmVwb3J0czxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQt YWxpZ246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz6j qDxzcGFuIGxhbmc9RU4tVVM+Rm9yIG1vcmUgaW5mb3JtYXRpb24gcGxlYXNlDQp2aXNpdCBvdXIg d2Vic2l0ZSA8aT48c3BhbiBzdHlsZT0nY29sb3I6IzMzNjZGRic+PGENCmhyZWY9Imh0dHA6Ly93 d3cuY2NpZC1tcmQuY29tLmNuLyI+PHNwYW4gc3R5bGU9J2NvbG9yOiMzMzY2RkYnPldXVy5DQ0lE LU1SRC5DT00uQ048L3NwYW4+PC9hPjwvc3Bhbj48L2k+o6k8bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5i c3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4x LkENClJldmlldyBvZiAyMDAxIENoaW5hIElDIEluZHVzdHJ5ICZhbXA7IGEgRm9yZWNhc3Qgb24g MjAwMi0yMDA1PHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Mi5BDQpSZXZpZXcgb2Yg MjAwMSBDaGluYSBJQyBNYXJrZXQgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PHNwYW4NCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+My5Bbg0KQW5hbHlzaXMgb2YgMjAwMSBDaGlu YSBJQyBJbXBvcnRzIGFuZCBFeHBvcnRzICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz40LiBBDQpSZXZpZXcgb2Yg MjAwMSBDaGluYSBEaXNjcmV0ZSBEZXZpY2VzIEluZHVzdHJ5ICZhbXA7IEEgRm9yZWNhc3Qgb24g MjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41LiBB bg0KQW5hbHlzaXMgb2YgMjAwMSBDaGluYSBFeHBvcnQgJmFtcDsgSW1wb3J0IG9mIERpc2NyZXRl IERldmljZXMgJmFtcDsgQSBGb3JlY2FzdA0Kb24gMjAwMi0yMDA1PHNwYW4gc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz42LkENCnJldmlldyBvZiAyMDAxIGNoaW5hoa9zIElDIE1hcmtldCAoYnkg Q2F0YWxvZ3VlKSAmYW1wOyBhIGZvcmVjYXN0IG9uIDIwMDItMjAwNSA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Ny5BDQpSZXZpZXcgb2YgQ2hpbmEncyAyMDAxIENv bXB1dGVyIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21z by1oYW5zaS1mb250LWZhbWlseTrLzszlJz44LkENClJldmlldyBvZiAyMDAxIENoaW5hIENvbnN1 bWVyIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1o YW5zaS1mb250LWZhbWlseTrLzszlJz45LkENClJldmlldyBvZiAyMDAxIENoaW5hIFRlbGVjb21t dW5pY2F0aW9uIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xMC5BDQpSZXZpZXcgb2YgMjAwMSBDaGluYSBJ QyBDYXJkIGFuZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MTEuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hpbmEgTWVtb3J5IGFu ZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz4xMi5BDQpSZXZpZXcgb2YgMjAwMSBDaGluYSBBbmFsb2cgQ2lyY3VpdCBhbmQg YSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+MTMuQSBSZXZpZXcNCm9mIDIwMDEgQ2hpbmEgUG93ZXIgSUMgYW5kIGEgRm9yZWNh c3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjE0LkENClJldmlldyBvZiAyMDAxIENoaW5hIERTUCBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIw MDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTUuQQ0KUmV2aWV3 IG9mIDIwMDEgQ2hpbmEgTUNVIGFuZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xNi5BDQpSZXZpZXcgb2YgMjAwMSBDaGlu YSBQb3dlciBJQyBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28t aGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTcuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hpbmEgQUQvREEg YW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OsvOzOUnPjE4Lk1OQ3MNCkVsZWN0cm9uaWMgQ29ycG9yYXRpb25zIEluIENoaW5hOiBJ bnZlc3RtZW50LCBNYXJrZXRpbmcsIEFuZCBUcmVuZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2kt Zm9udC1mYW1pbHk6y87M5Sc+MTkuc2VtaWNvbmR1Y3Rvcg0KTU5DcyBpbiBjaGluYTogMjAwMiBF ZGl0aW9uIENoaW5lc2Ugb25seSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MzQuQQ0KU3VydmV5PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsg PC9zcGFuPm9mPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4y MDAxIENoaW5hIFNlbWljb25kdWN0b3IncyBkaXN0cmlidXRpb24NCm1hcmtldCA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MjAuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hp bmEgU2VtaWNvbmR1Y3RvciBFcXVpcG1lbnQgYW5kIEluc3RydW1lbnRzIGFuZCBhIEZvcmVjYXN0 IG9uDQoyMDAyLTIwMDUgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjIyLkENClJldmlldyBvZiAyMDAxIENoaW5hIEVsZWN0cm9uaWMgcHJvZHVjdHMgYW5kIGEgRm9y ZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjIzLkENClJldmlldyBvZiAyMDAxIENoaW5hIFNlbWljb25kdWN0b3IgSW5kdXN0cnkgU3Bl Y2lhbDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46DQp5ZXMiPiZuYnNwOyA8L3NwYW4+TWF0ZXJp YWxzICZhbXA7IEEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5z aS1mb250LWZhbWlseTrLzszlJz4yNC5BIFJldmlldw0Kb2YgMjAwMSBDaGluYSBTZW1pY29uZHVj dG9yIFBhY2thZ2luZyBtYXRlcmlhbHMgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI1LkENClJldmlldyBvZiAyMDAx IFdvcmxkIFNlbWljb25kdWN0b3IgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI2LlJlc2VhcmNoDQpvbiBDaGluYSBJ QyBJbmR1c3RyeSBQb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M 5Sc+MjcuMjAwMQ0KQ2hpbmEgSUMgSW5kdXN0cnkgQW5udWFsIFJlcG9ydKOoMjAwMiBFZGl0aW9u o6k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MzEuQ2hpbmENClNl bWljb25kdWN0b3IgSW5mb3JtYXRpb24gKCBvbmUgZWRpdGlvbiBwZXIgcXVhcnRlcik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MzMuMjAwMQ0KQ2hpbmEgU2VtaWNv bmR1Y3RvciBJbmR1c3RyeSBBc3NvY2lhdGlvbiAoQ1NJQSkgTWVtYmVyIERpcmVjdG9yeSA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MjEuQQ0KUmV2aWV3IG9mIDIw MDEgQ2hpbmEgTENEIGRldmljZSBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+PG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNp LWZvbnQtZmFtaWx5OsvOzOUnPjI5LkENClJldmlldyBvZiAyMDAxIENoaW5hIExFRCBkZXZpY2Ug YW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OsvOzOUnPjMwLkENClJldmlldyBvZiBDaGluYSBQQ0IgSW5kdXN0cnkgYW5kIG1hcmtl dCBhbmQgZm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjMyLkENClJldmlldyBvZiBDaGluYSBDb25uZWN0b3IgSW5kdXN0cnkgYW5kIG1hcmtldCBhbmQg Zm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjEuIDIw MDENCkNoaW5hIFNNVCBEZXZpY2UgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsg QSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Mi4g MjAwMQ0KQ2hpbmEgU01UIEVxdWlwbWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz4zLiAyMDAxDQpDaGluYSBVUFMgSW5kdXN0cnk6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3Qg PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjQuIDIwMDENCkNoaW5h IFRyYW5zZm9ybWVyLCBJbmR1Y3RvciBhbmQgQmFsbGFzdCBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+NS4gMjAwMQ0KQ2hpbmEgUHJpbWFyeSBCYXR0ZXJ5IGFuZCBTdG9yYWdlIEJh dHRlcnkgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjYuPHNwYW4NCnN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIFNwZWFrZXIgYW5kIEhl YWRwaG9uZQ0KSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Ny48c3Bhbg0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hpbmEgU3dpdGNoLCBQbHVn IGFuZCBPdXRsZXQNCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjguPHNwYW4NCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIE1hZ25ldGlj IEhlYWQgRGV2aWNlDQpJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45LiAyMDAxDQpD aGluYSBFbGV0cm9tYWduZXQgYW5kIFBlcm1hbmVudCBNYWduZXQgSW5kdXN0cnkgYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZv bnQtZmFtaWx5OsvOzOUnPjEwLg0KQ0NJRCBTZW1pY29uZHVjdG9yIEluZm9ybWF0aW9uo6hPbmUg RWRpdGlvbiBwZXIgdGhyZWUgbW9udGijqSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+MTEuIEENCnN1cnZleSBvZiAyMDAxIENoaW5hIFNwYXJraW5nIFBsdWcsIEln bml0aW9uIE1hZ25ldG9zIGFuZCBQZXJtYW5lbnQgREMNCkdlbmVyYXRvciA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTIuDQoyMDAxIENoaW5hIEJ1enplciBJbmR1 c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xMy4NCjIwMDEgQ2hpbmEgRWxlY3RyaWMgUmVs YXkgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTQuDQoyMDAxIENoaW5hIENhdGhv ZGUgUmF5IFR1YmUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTUuDQoyMDAxIENo aW5hIGluc3VsYXRlZCB3aXJlLCBjYWJsZSBhbmQgb3B0aWNhbCBjYWJsZSBJbmR1c3RyeSBhbmQg TWFya2V0OiBBDQpSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MTYuDQoyMDAxIENoaW5hIENhcmJvbiBFbGVjdHJvZGUgYW5k IEluc3VsYXRvciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTcuDQoyMDAxIENo aW5hIEZpbG0gQ2FtZXJhIGFuZCBQcm9qZWN0b3IgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZp ZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OsvOzOUnPjE4LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L3NwYW4+ MjAwMSBDaGluYSBFbGVjdHJpY2FsIEZhbiwgQWlyDQpDb25kaXRpb25pbmcgYW5kIERyeWVyIElu ZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjE5Lg0KMjAwMSBDaGluYSBBdXRvIFdhc2hp bmcgTWFjaGluZSBhbmQgQ2xvdGhlcyBEcnllciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dw0KJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MjAuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4y MDAxIENoaW5hIERpc2h3YXNoaW5nIE1hY2hpbmUNCihkb21lc3RpYyBob3VzZWhvbGQpIEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjIxLg0KMjAwMSBDaGluYSBFbGVjdHJpY2FsIFNj YWxlIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjIyLg0KMjAwMSBDaGluYSBFbWJy b2lkZXIgbWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4yMy4NCjIwMDEg Q2hpbmEgQ2FsY3VsYXRpbmcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz4yNC4NCjIwMDEgQ2hpbmEgRWxlY3Ryb25pYyBFcXVpcG1lbnQgZm9yIEtpdGNoZW4gSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsNCkEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI1Lg0KMjAwMSBDaGluYSBFbGVjdHJpYyBSYXpv ciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4yNi4NCjIwMDEgQ2hpbmEgV2F0ZXIg SGVhdGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI3Lg0KMjAwMSBDaGluYSBF bGVjdHJpY2FsIEhhaXIgRHJlc3NpbmcgVG9vbCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MjguDQoyMDAxIENoaW5hIEVsZWN0cmljIElyb24gSW5kdXN0cnkgYW5kIE1hcmtldDog QSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+MjkuDQoyMDAxIENoaW5hIFJhZGlvIFNldHMsIFRhcGUgUmVjb3JkZXIgYW5k IEF1ZGlvIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4zMC4NCjIwMDEgQ2hpbmEg VkYgTWVnYXBob25lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjMxLg0KMjAwMSBD aGluYSBTYXRlbGxpdGUgR3JvdW5kIFN0YXRpb24gZm9yIFRWIEluZHVzdHJ5IGFuZCBNYXJrZXQ6 IEEgUmV2aWV3ICZhbXA7DQpBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz4zMi4NCjIwMDEgQ2hpbmEgVkNEIGFuZCBEVkQgSW5kdXN0cnkgYW5kIE1h cmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2kt Zm9udC1mYW1pbHk6y87M5Sc+MzMuDQoyMDAxIENoaW5hIFNldCBUb3AgQm94IEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM0Lg0KMjAwMSBDaGluYSBUZWxlY2FtZXJhIEluZHVzdHJ5 IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNv LWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM1LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyA8L3NwYW4+MjAwMSBDaGluYSBUZWxldmlzaW9uIFNldCBJbmR1c3RyeSBhbmQN Ck1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MzYuDQoyMDAxIENoaW5hIENhbWVyYSBJbmR1c3RyeSBhbmQg TWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5z aS1mb250LWZhbWlseTrLzszlJz4zNy4NCjIwMDEgQ2hpbmEgQXVkaXBob25lIEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM4LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyA8L3NwYW4+MjAwMSBDaGluYSBFbGVjdHJpYyBXYXRjaCBhbmQgVGltZXINCkluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM5Lg0KMjAwMSBDaGluYSBNdXNpY2FsIEluc3Ry dW1lbnQgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NDAuDQoyMDAxIENoaW5hIFZp ZGVvIEdhbWUgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZv cmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz40MS4NCjIw MDEgQ2hpbmEgVGFwZSBhbmQgUmVjb3JkIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZh bXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjQyLg0KMjAwMSBDaGluYSBUb3lzIE1vdG9yIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3 ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjQzLg0KMjAwMSBDaGluYSBQcmludGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3 ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjQ0Lg0KMjAwMSBDaGluYSBDYXNoIFJlZ2lzdGVyIGFuZCBTYWxlcyBUZXJtaW5hbCBSZWdp c3RlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBDQpSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NDUuDQoyMDAxIENoaW5hIFBv c3RhZ2UgU3RhbXBlciBhbmQgQm9va2luZyBNYWNoaW5lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40Ni4NCjIwMDEgQ2hpbmEgRGlzcGxheSBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40Ny4NCjIwMDEgQ2hpbmEgU2Nhbm5lciBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40OC4NCjIwMDEgQ2hpbmEgS2V5Ym9hcmQgYW5kIE1vdXNlIEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjQ5Lg0KMjAwMSBDaGluYSBEaWdpdGFsIEVxdWlwbWVudCBJ bmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41MC4NCjIwMDEgQ2hpbmEgU3RvcmFnZSBC bG9jayBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41MS4NCjIwMDEgQ2hpbmEgSGFy ZHBhbiwgRmxvcHB5IERpc2MgYW5kIERyaXZlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOw0KQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+NTIuDQoyMDAxIENoaW5hIE1vbmV5LURyYXcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFy a2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1m b250LWZhbWlseTrLzszlJz41My4NCjIwMDEgQ2hpbmEgVm9sdGFnZS1zdGFiaWxpemVkIFNvdXJj ZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NTQuDQoyMDAxIENoaW5hIERpc2Mg YW5kIE1hZ25ldGljIENhcmQgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0K Rm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjU1Lg0K MjAwMSBDaGluYSBDb21wdXRlciBTb2Z0d2FyZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrL zszlJz41Ni4NCjIwMDEgQ2hpbmEgVGVsZXBob25lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2 aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OsvOzOUnPjU3Lg0KMjAwMSBDaGluYSBGQVggSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcg JmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M 5Sc+NTguDQoyMDAxIENoaW5hIFByb2dyYW0tQ29udHJvbGxlZCBFeGNoYW5nZSBJbmR1c3RyeSBh bmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28t aGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NTkuDQoyMDAxIENoaW5hIE9wdGljYWwgVHJhbnNtaXNz aW9uIEVxdWlwbWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3Jl Y2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NjAuPHNwYW4N CnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIElQIFRl bGVwaG9uZSBTaWduYWwgQ29udmVydGVyDQpJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz42MS48c3Bhbg0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEg Q2hpbmEgQ29uY2VudHJhdG9yIGFuZCBJbmRpY2F0b3INCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFt aWx5OsvOzOUnPjYyLg0KMjAwMSBDaGluYSBNb2RlbSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWls eTrLzszlJz42My4NCjIwMDEgQ2hpbmEgRmFjc2ltaWxlIFNpZ25hbCBTZW5zb3IgSW5kdXN0cnkg YW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNv LWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY0Lg0KMjAwMSBDaGluYSBXYWxraWUtVGFsa2llIElu ZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY1Lg0KMjAwMSBDaGluYSBNb2JpbGUgUGhv bmUgYW5kIEJlZXBlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3Jl Y2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NjYuDQoyMDAx IENoaW5hIEZpYnJlLU9wdGljYWwgQ29tbXVuaWNhdGlvbiBhbmQgRmlicmUtT3B0aWNhbCBQcm9w ZXJ0eSB0ZXN0ZXINCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY3Lg0KMjAwMSBD aGluYSBEdXBsaWNhdG9yIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY4Lg0KMjAw MSBDaGluYSBNYWlsIFByb2Nlc3NvciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1w OyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz42 OS4NCjIwMDEgQ2hpbmEgUGFwZXItY3V0dGluZyBNYWNoaW5lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6 IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz43MC4NCjIwMDEgQ2hpbmEgQXV0byBWZW5kaW5nIE1hY2hpbmUgSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NzEuDQoyMDAxIENoaW5hIFBvcnRhbCBFbGVjdHJp YyBUb29sIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjcyLg0KMjAwMSBDaGluYSBT ZXdpbmcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz43My48c3Bhbg0K c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hpbmEgUGhvdG8g RW5sYXJnZXIgYW5kIFJlZHVjdGlvbg0KUHJpbnRlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWls eTrLzszlJz43NC4NCjIwMDEgQ2hpbmEgU2xpZGUgUHJvamVjdG9yIEluZHVzdHJ5IGFuZCBNYXJr ZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZv bnQtZmFtaWx5OsvOzOUnPjc1LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L3NwYW4+MjAwMSBDaGluYSBQbG90dGVyIEVxdWlwbWVudCBJbmR1c3RyeQ0KYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9u dC1mYW1pbHk6y87M5Sc+NzYuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 IDwvc3Bhbj4yMDAxIENoaW5hIEVsZWN0cmljIExpZ2h0aW5nIGFuZCBTaWduYWwNCkVxdWlwbWVu dCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz43Ny4NCjIwMDEgQ2hpbmEgRWxlY3Ry aWMgRHJ5IE92ZW4gYW5kIEhlYXRlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1w OyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ NzguDQoyMDAxIENoaW5hIEJvYXJkaW5nIE1hY2hpbmUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBS ZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+NzkuDQoyMDAxIENoaW5hIFRyYWZmaWMgQ29udHJvbCBFcXVpcG1lbnQgSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjgwLg0KMjAwMSBDaGluYSBXYXJuaW5nIERldmlj ZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44MS4NCjIwMDEgQ2hpbmEgTmF2aWdh dGlvbiBSYWRpbyBGYWNpbGl0aWVzIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7 IEENCkZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44 Mi48c3Bhbg0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hp bmEgTWV0YWwtTWluZSBkZXRlY3RvciBJbmR1c3RyeQ0KYW5kIE1hcmtldDogQSBSZXZpZXcgJmFt cDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ ODMuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENo aW5hIFByZWNpcGl0YXRvciBJbmR1c3RyeSBhbmQNCk1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBG b3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODQuDQoy MDAxIENoaW5hIEluamVjdGlvbiBNYWNoaW5lLCBQbGFzdGljIENvbW1pbnV0b3IgYW5kIEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEENClJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44NS4NCjIwMDEgQ2hpbmEgU2V0IE1pY3Jvc2Nv cGUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODYuDQoyMDAxIENoaW5hIExvY2F0 aW5nIENvbXBhc3MgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODcuDQoyMDAxIENo aW5hIHJhbmdlZmluZGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjg4Lg0KMjAw MSBDaGluYSBCYXJvc3RhdCBhbmQgVGhlcm1vc3RhdCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+ODkuDQoyMDAxIENoaW5hIE1hY2hpbmUgVG9vbHMgSW5kdXN0cnkgYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9u dC1mYW1pbHk6y87M5Sc+OTAuDQoyMDAxIENoaW5hIEF1dG9tb2JpbGUgRXF1aXBtZW50IEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjkxLg0KMjAwMSBDaGluYSBNZWRpY2FsIEVxdWlw bWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45Mi4NCjIwMDEgQ2hpbmEgR2Fz bWV0ZXIsIFdhdGVybWV0ZXIgYW5kIEVsZXRyb21ldGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz45My4NCjIwMDEgQ2hpbmEgT2RvbWV0ZXIgYW5kIFZlbG9ncmFwaCBJbmR1c3Ry eSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+OTQuDQoyMDAxIENoaW5hIEFtbWV0ZXIsVm9sdG1l dGVyIGFuZCBNdWx0aW1ldGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6PHNwYW4NCnN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5BIFJldmlldyAmYW1wOyBB IEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45NS4N CjIwMDEgQ2hpbmEgT1NDIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjk2Lg0KMjAw MSBDaGluYSBSZXNpc3RhbmNlIFRlc3RlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8 IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlm XT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tdG9wOjBjbTttYXJn aW4tcmlnaHQ6MzAuMHB0O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0Og0KMTUuMHB0O21h cmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDoxNy4yNXB0O2xpbmUtaGVpZ2h0OjE1MCUn PjxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJc MDAwQgwiO2NvbG9yOm5hdnknPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5k aWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21hcmdpbi10b3A6MGNtO21h cmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6DQoxNS4wcHQ7 bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7bGluZS1oZWlnaHQ6MTUw JSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlwwMDBCDCI7Y29sb3I6bmF2eSc+TmFtZTogQzwvc3Bhbj48c3Bhbg0KbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjpu YXZ5Jz5oaW5hDQpDZW50ZXIgb2YgSW5mb3JtYXRpb24gSW5kdXN0cnkgRGV2ZWxvcG1lbnQoPC9z cGFuPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJcMDAwQgwiO2NvbG9yOm5hdnknPkNDSUQpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBz dHlsZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz48c3Bhbg0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFu DQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvc3Bhbj5NaWNyb2VsZWN0cm9uaWNz IFJlc2VyY2ggRGVwYXJ0bWVudChNUkQpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHls ZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTtt YXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcu MjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5BZGRyZXNzPC9zcGFuPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYXNjaWktZm9udC1mYW1pbHk6IlwwMDBC DCI7bXNvLWhhbnNpLWZvbnQtZmFtaWx5Og0KIlwwMDBCDCI7Y29sb3I6bmF2eSc+o7o8L3NwYW4+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJc MDAwQgwiO2NvbG9yOm5hdnknPkNoaW5hIFNlbWljb25kdWN0b3IgSW5kdXN0cnkNCkFzc29jaWF0 aW9uLjI3LFJkLndhbnNob3VsdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21h cmdpbi10b3A6MGNtO21hcmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2lu LWxlZnQ6DQoxNS4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7 bGluZS1oZWlnaHQ6MTUwJSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2eSc+UEM8L3NwYW4+PHNwYW4NCnN0eWxl PSdmb250LXNpemU6MTAuMHB0O21zby1hc2NpaS1mb250LWZhbWlseToiXDAwMEIMIjttc28taGFu c2ktZm9udC1mYW1pbHk6DQoiXDAwMEIMIjtjb2xvcjpuYXZ5Jz6jujwvc3Bhbj48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29s b3I6bmF2eSc+MTAwODQ2PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2lu LXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVm dDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcuMjVwdDtsaW5l LWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5XZWJzaXRlPC9zcGFuPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdDttc28tYXNjaWktZm9udC1mYW1pbHk6IlwwMDBCDCI7bXNvLWhh bnNpLWZvbnQtZmFtaWx5Og0KIlwwMDBCDCI7Y29sb3I6bmF2eSc+o7o8L3NwYW4+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmNvbG9yOm5hdnknPjxhIGhyZWY9Imh0 dHA6Ly93d3cuY2NpZC1tcmQuY29tLmNuLyI+d3d3LmNjaWQtbXJkLmNvbS5jbjwvYT48L3NwYW4+ PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7Y29sb3I6bmF2eSc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBz dHlsZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5FTUFJTDogPGENCmhy ZWY9Im1haWx0bzpndW95aXJhbkBjY2lkLW1yZC5jb20uY24iPmd1b3lpcmFuQGNjaWQtbXJkLmNv bS5jbjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tdG9wOjBj bTttYXJnaW4tcmlnaHQ6MzAuMHB0O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0Og0KMGNt O21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDoxNTAlJz48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2 eSc+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoNCnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YQ0K aHJlZj0ibWFpbHRvOk5FV1NAY2NpZC1tcmQuY29tLmNuIj5ORVdTQGNjaWQtbXJkLmNvbS5jbjwv YT48L3NwYW4+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OiJcMDAwQgwiO2Nv bG9yOiM2NjMzMDAnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21hcmdpbi10 b3A6MGNtO21hcmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6 DQoxNS4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7bGluZS1o ZWlnaHQ6MTUwJSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2eSc+VEVMOjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyA8L3NwYW4+ODYtMTAtNjgyMDg1OTIsPHNwYW4NCnN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU4OSZuYnNwOzwvc3Bhbj48 c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMw MCc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2luLXRvcDowY207bWFy Z2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDoNCjE1LjBwdDtt YXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAl Jz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi XDAwMEIMIjtjb2xvcjpuYXZ5Jz5GYXg6PHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU5MCAsPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU5NDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVT DQpzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMwMCc+PG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9J3RleHQtaW5kZW50OjMx LjVwdDttc28tY2hhci1pbmRlbnQtY291bnQ6My4wOw0KbXNvLWNoYXItaW5kZW50LXNpemU6MTAu NXB0Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseToiXDAwMEIMIjsNCmNvbG9y OiMzMzY2RkYnPkNvbnRhY3Q6PC9zcGFuPjxzcGFuIHN0eWxlPSdtc28tYXNjaWktZm9udC1mYW1p bHk6IlwwMDBCDCI7DQptc28taGFuc2ktZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzMzNjZG Ric+oaE8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtZmFtaWx5OiJcMDAwQgwi O2NvbG9yOiM2NjMzMDAnPkd1bzxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46DQp5ZXMiPiZuYnNw OyA8L3NwYW4+WWlyYW4gKDwvc3Bhbj48c3BhbiBzdHlsZT0nbXNvLWFzY2lpLWZvbnQtZmFtaWx5 OiJcMDAwQgwiOw0KbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiJcMDAwQgwiO2NvbG9yOiM2NjMzMDAn Prn50uPIuzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBC DCI7Y29sb3I6IzY2MzMwMCc+KSAsPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoNCnllcyI+Jm5i c3A7IDwvc3Bhbj5Mb3Vpc2EgTHYoPC9zcGFuPjxzcGFuIHN0eWxlPSdtc28tYXNjaWktZm9udC1m YW1pbHk6IlwwMDBCDCI7DQptc28taGFuc2ktZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2 MzMwMCc+wsDV3Dwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1mYW1pbHk6Ilww MDBCDCI7Y29sb3I6IzY2MzMwMCc+KSAsIDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0n Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCmNvbG9yOiM2NjMzMDAnPkx5ZGllIExpKDwvc3Bhbj48c3BhbiBzdHlsZT0nbXNv LWFzY2lpLWZvbnQtZmFtaWx5OiJcMDAwQgwiOw0KbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiJcMDAw QgwiO2NvbG9yOiM2NjMzMDAnPsDusK67qjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0n Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMwMCc+KTwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_========_000000510_========_ From msw@redhat.com Tue Feb 26 15:42:00 2002 From: msw@redhat.com (Matt Wilson) Date: Tue, 26 Feb 2002 10:42:00 -0500 Subject: LSB package for Debian: final(?) release candidate In-Reply-To: <20020225042200.GA24546@bellsouth.net>; from lawrencc@debian.org on Sun, Feb 24, 2002 at 10:22:00PM -0600 References: <20020219005001.328C6303B@quantex> <15473.45447.699122.380451@gargle.gargle.HOWL> <20020225042200.GA24546@bellsouth.net> Message-ID: <20020226104200.A12134@devserv.devel.redhat.com> Ditto, we need some LSB package that installs an init script to test our functionality as well. Cheers, Matt On Sun, Feb 24, 2002 at 10:22:00PM -0600, Chris Lawrence wrote: > FYI: I have a release candidate of the lsb package (version 1.1.0-3) > available at: > > http://people.debian.org/~lawrencc/ > > Matt Taggart and I had an off-list discussion about what should be in > the package, and this is the culmination of that work. > > Again, we'd like to see an LSB package that uses the init > functionality so we can test our implementation. (The apache package > *could*, but the prerm and postinst scripts appear to be Red Hat > scripts with all the actions commented out.) > > > Chris > -- > Chris Lawrence - http://www.lordsutch.com/chris/ > > > -- > To UNSUBSCRIBE, email to lsb-spec-request@lists.linuxbase.org > with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org From mats.d.wichmann@intel.com Tue Feb 26 17:51:03 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Tue, 26 Feb 2002 09:51:03 -0800 Subject: LSB package for Debian: final(?) release candidate Message-ID: <39B5C4829263D411AA93009027AE9EBB16677A1E@FMSMSX35> > Ditto, we need some LSB package that installs an init script to test > our functionality as well. Suggest some existing packages that do so and I can take a little bit of time to root around and see if they're compilable as LSB apps. Mats From msw@redhat.com Tue Feb 26 17:52:49 2002 From: msw@redhat.com (Matt Wilson) Date: Tue, 26 Feb 2002 12:52:49 -0500 Subject: LSB package for Debian: final(?) release candidate In-Reply-To: <39B5C4829263D411AA93009027AE9EBB16677A1E@FMSMSX35>; from mats.d.wichmann@intel.com on Tue, Feb 26, 2002 at 09:51:03AM -0800 References: <39B5C4829263D411AA93009027AE9EBB16677A1E@FMSMSX35> Message-ID: <20020226125249.C22926@devserv.devel.redhat.com> Apache is the clear starting point. On Tue, Feb 26, 2002 at 09:51:03AM -0800, Wichmann, Mats D wrote: > > Suggest some existing packages that do so and I can take a little > bit of time to root around and see if they're compilable as LSB > apps. From mats.d.wichmann@intel.com Tue Feb 26 18:01:48 2002 From: mats.d.wichmann@intel.com (Wichmann, Mats D) Date: Tue, 26 Feb 2002 10:01:48 -0800 Subject: LSB package for Debian: final(?) release candidate Message-ID: <39B5C4829263D411AA93009027AE9EBB16677A2D@FMSMSX35> Apache's already in the app battery. Does that mean it got built avoiding the init-script issue? > Apache is the clear starting point. > > On Tue, Feb 26, 2002 at 09:51:03AM -0800, Wichmann, Mats D wrote: > > > > Suggest some existing packages that do so and I can take a little > > bit of time to root around and see if they're compilable as LSB > > apps. > From msw@redhat.com Tue Feb 26 18:06:14 2002 From: msw@redhat.com (Matt Wilson) Date: Tue, 26 Feb 2002 13:06:14 -0500 Subject: LSB package for Debian: final(?) release candidate In-Reply-To: <39B5C4829263D411AA93009027AE9EBB16677A2D@FMSMSX35>; from mats.d.wichmann@intel.com on Tue, Feb 26, 2002 at 10:01:48AM -0800 References: <39B5C4829263D411AA93009027AE9EBB16677A2D@FMSMSX35> Message-ID: <20020226130614.E22926@devserv.devel.redhat.com> On Tue, Feb 26, 2002 at 10:01:48AM -0800, Wichmann, Mats D wrote: > Apache's already in the app battery. Does that mean it got built > avoiding the init-script issue? Or ignoring it. Cheers, Matt From dtype@dtype.org Tue Feb 26 18:31:50 2002 From: dtype@dtype.org (M. Drew Streib) Date: Tue, 26 Feb 2002 18:31:50 +0000 Subject: LSB package for Debian: final(?) release candidate In-Reply-To: <39B5C4829263D411AA93009027AE9EBB16677A2D@FMSMSX35> References: <39B5C4829263D411AA93009027AE9EBB16677A2D@FMSMSX35> Message-ID: <20020226183150.GM10581@dtype.org> --98VPa0byqqIRxGTH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 26, 2002 at 10:01:48AM -0800, Wichmann, Mats D wrote: > Apache's already in the app battery. Does that mean it got built > avoiding the init-script issue? Yes. I didn't have any implementations to work against, so I=20 skipped/avoided it at the time of the build. The source rpm is also on the ftp site, so it should be relatively easy to modify... -drew --=20 M. Drew Streib , Free Standards Group (freestandards.org) co-founder, SourceForge.net | core team, freedb | sysadmin, Linux Intl. creator, keyanalyze report | maintnr, *.us.pgp.net | other freedom/law --98VPa0byqqIRxGTH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjx71JYACgkQg2i7WWb7wYyz0wCfT76xuN/WwSH5AvZnLGKogGDc sGEAnjkdtYpWyybwJdGrl597HVtuzMda =k37Z -----END PGP SIGNATURE----- --98VPa0byqqIRxGTH-- From news@ccid-mrd.com.cn Wed Feb 27 00:41:28 2002 From: news@ccid-mrd.com.cn (news) Date: Wed, 27 Feb 2002 08:41:28 0800 Subject: 2002 CCID semiconductor industrial & market ANNAL reports Message-ID: <1014770488.520@com.cn> --_========_000000182_========_ Content-Type: text/plain; charset=""; format=flowed WELCOME TO ORDER 2002 CCID semiconductor Reports £¨For more information please visit our website WWW.CCID-MRD.COM.CN£© 1.A Review of 2001 China IC Industry & a Forecast on 2002-2005 2.A Review of 2001 China IC Market and a Forecast on 2002-2005 3.An Analysis of 2001 China IC Imports and Exports & a Forecast on 2002-2005 4. A Review of 2001 China Discrete Devices Industry & A Forecast on 2002-2005 5. An Analysis of 2001 China Export & Import of Discrete Devices & A Forecast on 2002-2005 6.A review of 2001 china¡¯s IC Market (by Catalogue) & a forecast on 2002-2005 7.A Review of China's 2001 Computer IC & a Forecast on 2002-2005 8.A Review of 2001 China Consumer IC & a Forecast on 2002-2005 9.A Review of 2001 China Telecommunication IC & a Forecast on 2002-2005 10.A Review of 2001 China IC Card and a Forecast on 2002-2005 11.A Review of 2001 China Memory and a Forecast on 2002-2005 12.A Review of 2001 China Analog Circuit and a Forecast on 2002-2005 13.A Review of 2001 China Power IC and a Forecast on 2002-2005 14.A Review of 2001 China DSP and a Forecast on 2002-2005 15.A Review of 2001 China MCU and a Forecast on 2002-2005 16.A Review of 2001 China Power IC and a Forecast on 2002-2005 17.A Review of 2001 China AD/DA and a Forecast on 2002-2005 18.MNCs Electronic Corporations In China: Investment, Marketing, And Trends 19.semiconductor MNCs in china: 2002 Edition Chinese only 34.A Survey of 2001 China Semiconductor's distribution market 20.A Review of 2001 China Semiconductor Equipment and Instruments and a Forecast on 2002-2005 22.A Review of 2001 China Electronic products and a Forecast on 2002-2005 23.A Review of 2001 China Semiconductor Industry Special Materials & A Forecast on 2002-2005 24.A Review of 2001 China Semiconductor Packaging materials and a Forecast on 2002-2005 25.A Review of 2001 World Semiconductor and a Forecast on 2002-2005 26.Research on China IC Industry Policy 27.2001 China IC Industry Annual Report£¨2002 Edition£© 31.China Semiconductor Information ( one edition per quarter) 33.2001 China Semiconductor Industry Association (CSIA) Member Directory 21.A Review of 2001 China LCD device and a Forecast on 2002-200529.A Review of 2001 China LED device and a Forecast on 2002-2005 30.A Review of China PCB Industry and market and forecast 32.A Review of China Connector Industry and market and forecast 1. 2001 China SMT Device Industry and Market: A Review & A Forecast 2. 2001 China SMT Equipment Industry and Market: A Review & A Forecast 3. 2001 China UPS Industry: A Review & A Forecast 4. 2001 China Transformer, Inductor and Ballast Industry and Market: A Review & A Forecast 5. 2001 China Primary Battery and Storage Battery Industry and Market: A Review & A Forecast 6. 2001 China Speaker and Headphone Industry and Market: A Review & A Forecast 7. 2001 China Switch, Plug and Outlet Industry and Market: A Review & A Forecast 8. 2001 China Magnetic Head Device Industry and Market: A Review & A Forecast 9. 2001 China Eletromagnet and Permanent Magnet Industry and Market: A Review & A Forecast 10. CCID Semiconductor Information£¨One Edition per three month£© 11. A survey of 2001 China Sparking Plug, Ignition Magnetos and Permanent DC Generator 12. 2001 China Buzzer Industry and Market: A Review & A Forecast 13. 2001 China Electric Relay Industry and Market: A Review & A Forecast 14. 2001 China Cathode Ray Tube Industry and Market: A Review & A Forecast 15. 2001 China insulated wire, cable and optical cable Industry and Market: A Review & A Forecast 16. 2001 China Carbon Electrode and Insulator Industry and Market: A Review & A Forecast 17. 2001 China Film Camera and Projector Industry and Market: A Review & A Forecast 18. 2001 China Electrical Fan, Air Conditioning and Dryer Industry and Market: A Review & A Forecast 19. 2001 China Auto Washing Machine and Clothes Dryer Industry and Market: A Review & A Forecast 20. 2001 China Dishwashing Machine (domestic household) Industry and Market: A Review & A Forecast 21. 2001 China Electrical Scale Industry and Market: A Review & A Forecast 22. 2001 China Embroider machine Industry and Market: A Review & A Forecast 23. 2001 China Calculating Machine Industry and Market: A Review & A Forecast 24. 2001 China Electronic Equipment for Kitchen Industry and Market: A Review & A Forecast 25. 2001 China Electric Razor Industry and Market: A Review & A Forecast 26. 2001 China Water Heater Industry and Market: A Review & A Forecast 27. 2001 China Electrical Hair Dressing Tool Industry and Market: A Review & A Forecast 28. 2001 China Electric Iron Industry and Market: A Review & A Forecast 29. 2001 China Radio Sets, Tape Recorder and Audio Industry and Market: A Review & A Forecast 30. 2001 China VF Megaphone Industry and Market: A Review & A Forecast 31. 2001 China Satellite Ground Station for TV Industry and Market: A Review & A Forecast 32. 2001 China VCD and DVD Industry and Market: A Review & A Forecast 33. 2001 China Set Top Box Industry and Market: A Review & A Forecast 34. 2001 China Telecamera Industry and Market: A Review & A Forecast 35. 2001 China Television Set Industry and Market: A Review & A Forecast 36. 2001 China Camera Industry and Market: A Review & A Forecast 37. 2001 China Audiphone Industry and Market: A Review & A Forecast 38. 2001 China Electric Watch and Timer Industry and Market: A Review & A Forecast 39. 2001 China Musical Instrument Industry and Market: A Review & A Forecast 40. 2001 China Video Game Machine Industry and Market: A Review & A Forecast 41. 2001 China Tape and Record Industry and Market: A Review & A Forecast 42. 2001 China Toys Motor Industry and Market: A Review & A Forecast 43. 2001 China Printer Industry and Market: A Review & A Forecast 44. 2001 China Cash Register and Sales Terminal Register Industry and Market: A Review & A Forecast 45. 2001 China Postage Stamper and Booking Machine Industry and Market: A Review & A Forecast 46. 2001 China Display Industry and Market: A Review & A Forecast 47. 2001 China Scanner Industry and Market: A Review & A Forecast 48. 2001 China Keyboard and Mouse Industry and Market: A Review & A Forecast 49. 2001 China Digital Equipment Industry and Market: A Review & A Forecast 50. 2001 China Storage Block Industry and Market: A Review & A Forecast 51. 2001 China Hardpan, Floppy Disc and Driver Industry and Market: A Review & A Forecast 52. 2001 China Money-Draw Machine Industry and Market: A Review & A Forecast 53. 2001 China Voltage-stabilized Source Industry and Market: A Review & A Forecast 54. 2001 China Disc and Magnetic Card Industry and Market: A Review & A Forecast 55. 2001 China Computer Software Industry and Market: A Review & A Forecast 56. 2001 China Telephone Industry and Market: A Review & A Forecast 57. 2001 China FAX Industry and Market: A Review & A Forecast 58. 2001 China Program-Controlled Exchange Industry and Market: A Review & A Forecast 59. 2001 China Optical Transmission Equipment Industry and Market: A Review & A Forecast 60. 2001 China IP Telephone Signal Converter Industry and Market: A Review & A Forecast 61. 2001 China Concentrator and Indicator Industry and Market: A Review & A Forecast 62. 2001 China Modem Industry and Market: A Review & A Forecast 63. 2001 China Facsimile Signal Sensor Industry and Market: A Review & A Forecast 64. 2001 China Walkie-Talkie Industry and Market: A Review & A Forecast 65. 2001 China Mobile Phone and Beeper Industry and Market: A Review & A Forecast 66. 2001 China Fibre-Optical Communication and Fibre-Optical Property tester Industry and Market: A Review & A Forecast 67. 2001 China Duplicator Industry and Market: A Review & A Forecast 68. 2001 China Mail Processor Industry and Market: A Review & A Forecast 69. 2001 China Paper-cutting Machine Industry and Market: A Review & A Forecast 70. 2001 China Auto Vending Machine Industry and Market: A Review & A Forecast 71. 2001 China Portal Electric Tool Industry and Market: A Review & A Forecast 72. 2001 China Sewing Machine Industry and Market: A Review & A Forecast 73. 2001 China Photo Enlarger and Reduction Printer Industry and Market: A Review & A Forecast 74. 2001 China Slide Projector Industry and Market: A Review & A Forecast 75. 2001 China Plotter Equipment Industry and Market: A Review & A Forecast 76. 2001 China Electric Lighting and Signal Equipment Industry and Market: A Review & A Forecast 77. 2001 China Electric Dry Oven and Heater Industry and Market: A Review & A Forecast 78. 2001 China Boarding Machine Industry and Market: A Review & A Forecast 79. 2001 China Traffic Control Equipment Industry and Market: A Review & A Forecast 80. 2001 China Warning Device Industry and Market: A Review & A Forecast 81. 2001 China Navigation Radio Facilities Industry and Market: A Review & A Forecast 82. 2001 China Metal-Mine detector Industry and Market: A Review & A Forecast 83. 2001 China Precipitator Industry and Market: A Review & A Forecast 84. 2001 China Injection Machine, Plastic Comminutor and Industry and Market: A Review & A Forecast 85. 2001 China Set Microscope Industry and Market: A Review & A Forecast 86. 2001 China Locating Compass Industry and Market: A Review & A Forecast 87. 2001 China rangefinder Industry and Market: A Review & A Forecast 88. 2001 China Barostat and Thermostat Industry and Market: A Review & A Forecast 89. 2001 China Machine Tools Industry and Market: A Review & A Forecast 90. 2001 China Automobile Equipment Industry and Market: A Review & A Forecast 91. 2001 China Medical Equipment Industry and Market: A Review & A Forecast 92. 2001 China Gasmeter, Watermeter and Eletrometer Industry and Market: A Review & A Forecast 93. 2001 China Odometer and Velograph Industry and Market: A Review & A Forecast 94. 2001 China Ammeter,Voltmeter and Multimeter Industry and Market: A Review & A Forecast 95. 2001 China OSC Industry and Market: A Review & A Forecast 96. 2001 China Resistance Tester Industry and Market: A Review & A Forecast Name: China Center of Information Industry Development(CCID) Microelectronics Reserch Department(MRD) Address£ºChina Semiconductor Industry Association.27,Rd.wanshoulu PC£º100846 Website£ºwww.ccid-mrd.com.cn EMAIL: guoyiran@ccid-mrd.com.cn NEWS@ccid-mrd.com.cn TEL: 86-10-68208592, 86-10-68208589 Fax: 86-10-68208590 , 86-10-68208594 Contact:¡¡Guo Yiran (¹ùÒãÈ») , Louisa Lv(ÂÀÕÜ) , Lydie Li(Àî°®»ª) --_========_000000182_========_ Content-Type: application/octet-stream; name="Information of China IC Market by CCID.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Information of China IC Market by CCID.htm" PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIg0K eG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCINCnhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVx dWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9R0IyMzEyIj4NCjxt ZXRhIG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9R2VuZXJh dG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDkiPg0KPG1ldGEgbmFtZT1PcmlnaW5hdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDkiPg0KPGxpbmsgcmVsPUZpbGUtTGlzdA0KaHJlZj0iLi9J bmZvcm1hdGlvbiUyMG9mJTIwQ2hpbmElMjBJQyUyME1hcmtldCUyMGJ5JTIwQ0NJRC5maWxlcy9m aWxlbGlzdC54bWwiPg0KPHRpdGxlPldFTENPTUUgVE8gT1JERVIgMjAwMiBDQ0lEIHNlbWljb25k dWN0b3IgUmVwb3J0czwvdGl0bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpEb2N1 bWVudFByb3BlcnRpZXM+DQogIDxvOkF1dGhvcj56ZW5nemhlbjwvbzpBdXRob3I+DQogIDxvOlRl bXBsYXRlPk5vcm1hbDwvbzpUZW1wbGF0ZT4NCiAgPG86TGFzdEF1dGhvcj5haWh1YTwvbzpMYXN0 QXV0aG9yPg0KICA8bzpSZXZpc2lvbj4yPC9vOlJldmlzaW9uPg0KICA8bzpUb3RhbFRpbWU+Mjwv bzpUb3RhbFRpbWU+DQogIDxvOkNyZWF0ZWQ+MjAwMi0wMi0yNVQwMToyMzowMFo8L286Q3JlYXRl ZD4NCiAgPG86TGFzdFNhdmVkPjIwMDItMDItMjVUMDE6MjM6MDBaPC9vOkxhc3RTYXZlZD4NCiAg PG86UGFnZXM+NTwvbzpQYWdlcz4NCiAgPG86V29yZHM+MTU0ODwvbzpXb3Jkcz4NCiAgPG86Q2hh cmFjdGVycz44ODI2PC9vOkNoYXJhY3RlcnM+DQogIDxvOkNvbXBhbnk+bXJkPC9vOkNvbXBhbnk+ DQogIDxvOkxpbmVzPjczPC9vOkxpbmVzPg0KICA8bzpQYXJhZ3JhcGhzPjE3PC9vOlBhcmFncmFw aHM+DQogIDxvOkNoYXJhY3RlcnNXaXRoU3BhY2VzPjEwODM4PC9vOkNoYXJhY3RlcnNXaXRoU3Bh Y2VzPg0KICA8bzpWZXJzaW9uPjkuMjgxMjwvbzpWZXJzaW9uPg0KIDwvbzpEb2N1bWVudFByb3Bl cnRpZXM+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpX b3JkRG9jdW1lbnQ+DQogIDx3OlB1bmN0dWF0aW9uS2VybmluZy8+DQogIDx3OkRyYXdpbmdHcmlk VmVydGljYWxTcGFjaW5nPjcuOCCw9TwvdzpEcmF3aW5nR3JpZFZlcnRpY2FsU3BhY2luZz4NCiAg PHc6RGlzcGxheUhvcml6b250YWxEcmF3aW5nR3JpZEV2ZXJ5PjA8L3c6RGlzcGxheUhvcml6b250 YWxEcmF3aW5nR3JpZEV2ZXJ5Pg0KICA8dzpEaXNwbGF5VmVydGljYWxEcmF3aW5nR3JpZEV2ZXJ5 PjI8L3c6RGlzcGxheVZlcnRpY2FsRHJhd2luZ0dyaWRFdmVyeT4NCiAgPHc6Q29tcGF0aWJpbGl0 eT4NCiAgIDx3OlNwYWNlRm9yVUwvPg0KICAgPHc6QmFsYW5jZVNpbmdsZUJ5dGVEb3VibGVCeXRl V2lkdGgvPg0KICAgPHc6RG9Ob3RMZWF2ZUJhY2tzbGFzaEFsb25lLz4NCiAgIDx3OlVMVHJhaWxT cGFjZS8+DQogICA8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCiAgIDx3OkFkanVzdExpbmVI ZWlnaHRJblRhYmxlLz4NCiAgIDx3OlVzZUZFTGF5b3V0Lz4NCiAgPC93OkNvbXBhdGliaWxpdHk+ DQogPC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6y87M5TsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWFsdDpTaW1TdW47DQoJ bXNvLWZvbnQtY2hhcnNldDoxMzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCglt c28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MyAxMzUxMzUyMzIg MTYgMCAyNjIxNDUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcMDAwQgwiOw0KCXBh bm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtYWx0OiJUaW1lcyBOZXcgUm9t YW4iOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpyb21h bjsNCgltc28tZm9udC1mb3JtYXQ6b3RoZXI7DQoJbXNvLWZvbnQtcGl0Y2g6YXV0bzsNCgltc28t Zm9udC1zaWduYXR1cmU6MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEDLzszlIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWNoYXJz ZXQ6MTM0Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6 dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjEgMTM1MTM1MjMyIDE2IDAgMjYyMTQ0IDA7 fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTpp bnRlci1pZGVvZ3JhcGg7DQoJbXNvLXBhZ2luYXRpb246bm9uZTsNCglmb250LXNpemU6MTAuNXB0 Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6y87M5TsNCgltc28tZm9udC1rZXJuaW5n OjEuMHB0O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6IzY2MDAwMDsNCglt c28tdGV4dC1hbmltYXRpb246bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZTsNCgl0ZXh0LXVu ZGVybGluZTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lOw0KCXRleHQtbGluZS10aHJvdWdo Om5vbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmds ZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlm eTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCW1zby1wYWdpbmF0aW9uOm5vbmU7 DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseTrLzszlOw0KCW1zby1oYW5zaS1mb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJbXNvLWZvbnQta2VybmluZzoxLjBwdDt9DQpwDQoJe21hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OsvOzOU7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KIC8qIFBhZ2UgRGVmaW5pdGlvbnMgKi8NCkBwYWdlDQoJe21zby1w YWdlLWJvcmRlci1zdXJyb3VuZC1oZWFkZXI6bm87DQoJbXNvLXBhZ2UtYm9yZGVyLXN1cnJvdW5k LWZvb3Rlcjpubzt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCglt YXJnaW46NzIuMHB0IDkwLjk1cHQgNzIuMHB0IDkwLjlwdDsNCgltc28taGVhZGVyLW1hcmdpbjo0 Mi41NXB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjQ5LjZwdDsNCgltc28tcGFwZXItc291cmNlOjA7 DQoJbGF5b3V0LWdyaWQ6MTUuNnB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30N Ci0tPg0KPC9zdHlsZT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1aSC1DTiBsaW5rPSIjNjYwMDAw IiB2bGluaz1wdXJwbGUgc3R5bGU9J3RhYi1pbnRlcnZhbDoyMS4wcHQ7DQp0ZXh0LWp1c3RpZnkt dHJpbTpwdW5jdHVhdGlvbic+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjEgc3R5bGU9J2xheW91dC1n cmlkOjE1LjZwdCc+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFz XT4mbmJzcDs8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGI+PHNwYW4N Cmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEw LjVwdDttc28taGFuc2ktZm9udC1mYW1pbHk6DQrLzszlO2NvbG9yOmJsdWUnPldFTENPTUUgVE8g T1JERVIgMjAwMiBDQ0lEIHNlbWljb25kdWN0b3IgUmVwb3J0czxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQt YWxpZ246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz6j qDxzcGFuIGxhbmc9RU4tVVM+Rm9yIG1vcmUgaW5mb3JtYXRpb24gcGxlYXNlDQp2aXNpdCBvdXIg d2Vic2l0ZSA8aT48c3BhbiBzdHlsZT0nY29sb3I6IzMzNjZGRic+PGENCmhyZWY9Imh0dHA6Ly93 d3cuY2NpZC1tcmQuY29tLmNuLyI+PHNwYW4gc3R5bGU9J2NvbG9yOiMzMzY2RkYnPldXVy5DQ0lE LU1SRC5DT00uQ048L3NwYW4+PC9hPjwvc3Bhbj48L2k+o6k8bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5i c3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4x LkENClJldmlldyBvZiAyMDAxIENoaW5hIElDIEluZHVzdHJ5ICZhbXA7IGEgRm9yZWNhc3Qgb24g MjAwMi0yMDA1PHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Mi5BDQpSZXZpZXcgb2Yg MjAwMSBDaGluYSBJQyBNYXJrZXQgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PHNwYW4NCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+My5Bbg0KQW5hbHlzaXMgb2YgMjAwMSBDaGlu YSBJQyBJbXBvcnRzIGFuZCBFeHBvcnRzICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz40LiBBDQpSZXZpZXcgb2Yg MjAwMSBDaGluYSBEaXNjcmV0ZSBEZXZpY2VzIEluZHVzdHJ5ICZhbXA7IEEgRm9yZWNhc3Qgb24g MjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41LiBB bg0KQW5hbHlzaXMgb2YgMjAwMSBDaGluYSBFeHBvcnQgJmFtcDsgSW1wb3J0IG9mIERpc2NyZXRl IERldmljZXMgJmFtcDsgQSBGb3JlY2FzdA0Kb24gMjAwMi0yMDA1PHNwYW4gc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz42LkENCnJldmlldyBvZiAyMDAxIGNoaW5hoa9zIElDIE1hcmtldCAoYnkg Q2F0YWxvZ3VlKSAmYW1wOyBhIGZvcmVjYXN0IG9uIDIwMDItMjAwNSA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Ny5BDQpSZXZpZXcgb2YgQ2hpbmEncyAyMDAxIENv bXB1dGVyIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21z by1oYW5zaS1mb250LWZhbWlseTrLzszlJz44LkENClJldmlldyBvZiAyMDAxIENoaW5hIENvbnN1 bWVyIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1o YW5zaS1mb250LWZhbWlseTrLzszlJz45LkENClJldmlldyBvZiAyMDAxIENoaW5hIFRlbGVjb21t dW5pY2F0aW9uIElDICZhbXA7IGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xMC5BDQpSZXZpZXcgb2YgMjAwMSBDaGluYSBJ QyBDYXJkIGFuZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MTEuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hpbmEgTWVtb3J5IGFu ZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz4xMi5BDQpSZXZpZXcgb2YgMjAwMSBDaGluYSBBbmFsb2cgQ2lyY3VpdCBhbmQg YSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+MTMuQSBSZXZpZXcNCm9mIDIwMDEgQ2hpbmEgUG93ZXIgSUMgYW5kIGEgRm9yZWNh c3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjE0LkENClJldmlldyBvZiAyMDAxIENoaW5hIERTUCBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIw MDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTUuQQ0KUmV2aWV3 IG9mIDIwMDEgQ2hpbmEgTUNVIGFuZCBhIEZvcmVjYXN0IG9uIDIwMDItMjAwNTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xNi5BDQpSZXZpZXcgb2YgMjAwMSBDaGlu YSBQb3dlciBJQyBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28t aGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTcuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hpbmEgQUQvREEg YW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OsvOzOUnPjE4Lk1OQ3MNCkVsZWN0cm9uaWMgQ29ycG9yYXRpb25zIEluIENoaW5hOiBJ bnZlc3RtZW50LCBNYXJrZXRpbmcsIEFuZCBUcmVuZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2kt Zm9udC1mYW1pbHk6y87M5Sc+MTkuc2VtaWNvbmR1Y3Rvcg0KTU5DcyBpbiBjaGluYTogMjAwMiBF ZGl0aW9uIENoaW5lc2Ugb25seSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MzQuQQ0KU3VydmV5PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsg PC9zcGFuPm9mPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4y MDAxIENoaW5hIFNlbWljb25kdWN0b3IncyBkaXN0cmlidXRpb24NCm1hcmtldCA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MjAuQQ0KUmV2aWV3IG9mIDIwMDEgQ2hp bmEgU2VtaWNvbmR1Y3RvciBFcXVpcG1lbnQgYW5kIEluc3RydW1lbnRzIGFuZCBhIEZvcmVjYXN0 IG9uDQoyMDAyLTIwMDUgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjIyLkENClJldmlldyBvZiAyMDAxIENoaW5hIEVsZWN0cm9uaWMgcHJvZHVjdHMgYW5kIGEgRm9y ZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjIzLkENClJldmlldyBvZiAyMDAxIENoaW5hIFNlbWljb25kdWN0b3IgSW5kdXN0cnkgU3Bl Y2lhbDxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46DQp5ZXMiPiZuYnNwOyA8L3NwYW4+TWF0ZXJp YWxzICZhbXA7IEEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5z aS1mb250LWZhbWlseTrLzszlJz4yNC5BIFJldmlldw0Kb2YgMjAwMSBDaGluYSBTZW1pY29uZHVj dG9yIFBhY2thZ2luZyBtYXRlcmlhbHMgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI1LkENClJldmlldyBvZiAyMDAx IFdvcmxkIFNlbWljb25kdWN0b3IgYW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI2LlJlc2VhcmNoDQpvbiBDaGluYSBJ QyBJbmR1c3RyeSBQb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M 5Sc+MjcuMjAwMQ0KQ2hpbmEgSUMgSW5kdXN0cnkgQW5udWFsIFJlcG9ydKOoMjAwMiBFZGl0aW9u o6k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MzEuQ2hpbmENClNl bWljb25kdWN0b3IgSW5mb3JtYXRpb24gKCBvbmUgZWRpdGlvbiBwZXIgcXVhcnRlcik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MzMuMjAwMQ0KQ2hpbmEgU2VtaWNv bmR1Y3RvciBJbmR1c3RyeSBBc3NvY2lhdGlvbiAoQ1NJQSkgTWVtYmVyIERpcmVjdG9yeSA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MjEuQQ0KUmV2aWV3IG9mIDIw MDEgQ2hpbmEgTENEIGRldmljZSBhbmQgYSBGb3JlY2FzdCBvbiAyMDAyLTIwMDU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+PG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNp LWZvbnQtZmFtaWx5OsvOzOUnPjI5LkENClJldmlldyBvZiAyMDAxIENoaW5hIExFRCBkZXZpY2Ug YW5kIGEgRm9yZWNhc3Qgb24gMjAwMi0yMDA1PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OsvOzOUnPjMwLkENClJldmlldyBvZiBDaGluYSBQQ0IgSW5kdXN0cnkgYW5kIG1hcmtl dCBhbmQgZm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjMyLkENClJldmlldyBvZiBDaGluYSBDb25uZWN0b3IgSW5kdXN0cnkgYW5kIG1hcmtldCBhbmQg Zm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjEuIDIw MDENCkNoaW5hIFNNVCBEZXZpY2UgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsg QSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Mi4g MjAwMQ0KQ2hpbmEgU01UIEVxdWlwbWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz4zLiAyMDAxDQpDaGluYSBVUFMgSW5kdXN0cnk6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3Qg PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjQuIDIwMDENCkNoaW5h IFRyYW5zZm9ybWVyLCBJbmR1Y3RvciBhbmQgQmFsbGFzdCBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+NS4gMjAwMQ0KQ2hpbmEgUHJpbWFyeSBCYXR0ZXJ5IGFuZCBTdG9yYWdlIEJh dHRlcnkgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjYuPHNwYW4NCnN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIFNwZWFrZXIgYW5kIEhl YWRwaG9uZQ0KSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+Ny48c3Bhbg0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hpbmEgU3dpdGNoLCBQbHVn IGFuZCBPdXRsZXQNCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjguPHNwYW4NCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIE1hZ25ldGlj IEhlYWQgRGV2aWNlDQpJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45LiAyMDAxDQpD aGluYSBFbGV0cm9tYWduZXQgYW5kIFBlcm1hbmVudCBNYWduZXQgSW5kdXN0cnkgYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZv bnQtZmFtaWx5OsvOzOUnPjEwLg0KQ0NJRCBTZW1pY29uZHVjdG9yIEluZm9ybWF0aW9uo6hPbmUg RWRpdGlvbiBwZXIgdGhyZWUgbW9udGijqSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+MTEuIEENCnN1cnZleSBvZiAyMDAxIENoaW5hIFNwYXJraW5nIFBsdWcsIEln bml0aW9uIE1hZ25ldG9zIGFuZCBQZXJtYW5lbnQgREMNCkdlbmVyYXRvciA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTIuDQoyMDAxIENoaW5hIEJ1enplciBJbmR1 c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4xMy4NCjIwMDEgQ2hpbmEgRWxlY3RyaWMgUmVs YXkgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTQuDQoyMDAxIENoaW5hIENhdGhv ZGUgUmF5IFR1YmUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTUuDQoyMDAxIENo aW5hIGluc3VsYXRlZCB3aXJlLCBjYWJsZSBhbmQgb3B0aWNhbCBjYWJsZSBJbmR1c3RyeSBhbmQg TWFya2V0OiBBDQpSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MTYuDQoyMDAxIENoaW5hIENhcmJvbiBFbGVjdHJvZGUgYW5k IEluc3VsYXRvciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+MTcuDQoyMDAxIENo aW5hIEZpbG0gQ2FtZXJhIGFuZCBQcm9qZWN0b3IgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZp ZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OsvOzOUnPjE4LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L3NwYW4+ MjAwMSBDaGluYSBFbGVjdHJpY2FsIEZhbiwgQWlyDQpDb25kaXRpb25pbmcgYW5kIERyeWVyIElu ZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjE5Lg0KMjAwMSBDaGluYSBBdXRvIFdhc2hp bmcgTWFjaGluZSBhbmQgQ2xvdGhlcyBEcnllciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dw0KJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MjAuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4y MDAxIENoaW5hIERpc2h3YXNoaW5nIE1hY2hpbmUNCihkb21lc3RpYyBob3VzZWhvbGQpIEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjIxLg0KMjAwMSBDaGluYSBFbGVjdHJpY2FsIFNj YWxlIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjIyLg0KMjAwMSBDaGluYSBFbWJy b2lkZXIgbWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4yMy4NCjIwMDEg Q2hpbmEgQ2FsY3VsYXRpbmcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz4yNC4NCjIwMDEgQ2hpbmEgRWxlY3Ryb25pYyBFcXVpcG1lbnQgZm9yIEtpdGNoZW4gSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsNCkEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI1Lg0KMjAwMSBDaGluYSBFbGVjdHJpYyBSYXpv ciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4yNi4NCjIwMDEgQ2hpbmEgV2F0ZXIg SGVhdGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjI3Lg0KMjAwMSBDaGluYSBF bGVjdHJpY2FsIEhhaXIgRHJlc3NpbmcgVG9vbCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+MjguDQoyMDAxIENoaW5hIEVsZWN0cmljIElyb24gSW5kdXN0cnkgYW5kIE1hcmtldDog QSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1m YW1pbHk6y87M5Sc+MjkuDQoyMDAxIENoaW5hIFJhZGlvIFNldHMsIFRhcGUgUmVjb3JkZXIgYW5k IEF1ZGlvIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz4zMC4NCjIwMDEgQ2hpbmEg VkYgTWVnYXBob25lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjMxLg0KMjAwMSBD aGluYSBTYXRlbGxpdGUgR3JvdW5kIFN0YXRpb24gZm9yIFRWIEluZHVzdHJ5IGFuZCBNYXJrZXQ6 IEEgUmV2aWV3ICZhbXA7DQpBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz4zMi4NCjIwMDEgQ2hpbmEgVkNEIGFuZCBEVkQgSW5kdXN0cnkgYW5kIE1h cmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2kt Zm9udC1mYW1pbHk6y87M5Sc+MzMuDQoyMDAxIENoaW5hIFNldCBUb3AgQm94IEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM0Lg0KMjAwMSBDaGluYSBUZWxlY2FtZXJhIEluZHVzdHJ5 IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNv LWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM1LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyA8L3NwYW4+MjAwMSBDaGluYSBUZWxldmlzaW9uIFNldCBJbmR1c3RyeSBhbmQN Ck1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFu c2ktZm9udC1mYW1pbHk6y87M5Sc+MzYuDQoyMDAxIENoaW5hIENhbWVyYSBJbmR1c3RyeSBhbmQg TWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5z aS1mb250LWZhbWlseTrLzszlJz4zNy4NCjIwMDEgQ2hpbmEgQXVkaXBob25lIEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM4LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyA8L3NwYW4+MjAwMSBDaGluYSBFbGVjdHJpYyBXYXRjaCBhbmQgVGltZXINCkluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjM5Lg0KMjAwMSBDaGluYSBNdXNpY2FsIEluc3Ry dW1lbnQgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NDAuDQoyMDAxIENoaW5hIFZp ZGVvIEdhbWUgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZv cmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz40MS4NCjIw MDEgQ2hpbmEgVGFwZSBhbmQgUmVjb3JkIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZh bXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUn PjQyLg0KMjAwMSBDaGluYSBUb3lzIE1vdG9yIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3 ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjQzLg0KMjAwMSBDaGluYSBQcmludGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3 ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvO zOUnPjQ0Lg0KMjAwMSBDaGluYSBDYXNoIFJlZ2lzdGVyIGFuZCBTYWxlcyBUZXJtaW5hbCBSZWdp c3RlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBDQpSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NDUuDQoyMDAxIENoaW5hIFBv c3RhZ2UgU3RhbXBlciBhbmQgQm9va2luZyBNYWNoaW5lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40Ni4NCjIwMDEgQ2hpbmEgRGlzcGxheSBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40Ny4NCjIwMDEgQ2hpbmEgU2Nhbm5lciBJbmR1c3RyeSBhbmQgTWFya2V0OiBB IFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz40OC4NCjIwMDEgQ2hpbmEgS2V5Ym9hcmQgYW5kIE1vdXNlIEluZHVzdHJ5IGFu ZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhh bnNpLWZvbnQtZmFtaWx5OsvOzOUnPjQ5Lg0KMjAwMSBDaGluYSBEaWdpdGFsIEVxdWlwbWVudCBJ bmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41MC4NCjIwMDEgQ2hpbmEgU3RvcmFnZSBC bG9jayBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz41MS4NCjIwMDEgQ2hpbmEgSGFy ZHBhbiwgRmxvcHB5IERpc2MgYW5kIERyaXZlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOw0KQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6 y87M5Sc+NTIuDQoyMDAxIENoaW5hIE1vbmV5LURyYXcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFy a2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1m b250LWZhbWlseTrLzszlJz41My4NCjIwMDEgQ2hpbmEgVm9sdGFnZS1zdGFiaWxpemVkIFNvdXJj ZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NTQuDQoyMDAxIENoaW5hIERpc2Mg YW5kIE1hZ25ldGljIENhcmQgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0K Rm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjU1Lg0K MjAwMSBDaGluYSBDb21wdXRlciBTb2Z0d2FyZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmll dyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrL zszlJz41Ni4NCjIwMDEgQ2hpbmEgVGVsZXBob25lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2 aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OsvOzOUnPjU3Lg0KMjAwMSBDaGluYSBGQVggSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcg JmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M 5Sc+NTguDQoyMDAxIENoaW5hIFByb2dyYW0tQ29udHJvbGxlZCBFeGNoYW5nZSBJbmR1c3RyeSBh bmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28t aGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NTkuDQoyMDAxIENoaW5hIE9wdGljYWwgVHJhbnNtaXNz aW9uIEVxdWlwbWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3Jl Y2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NjAuPHNwYW4N CnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENoaW5hIElQIFRl bGVwaG9uZSBTaWduYWwgQ29udmVydGVyDQpJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszl Jz42MS48c3Bhbg0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEg Q2hpbmEgQ29uY2VudHJhdG9yIGFuZCBJbmRpY2F0b3INCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFt aWx5OsvOzOUnPjYyLg0KMjAwMSBDaGluYSBNb2RlbSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWls eTrLzszlJz42My4NCjIwMDEgQ2hpbmEgRmFjc2ltaWxlIFNpZ25hbCBTZW5zb3IgSW5kdXN0cnkg YW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNv LWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY0Lg0KMjAwMSBDaGluYSBXYWxraWUtVGFsa2llIElu ZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY1Lg0KMjAwMSBDaGluYSBNb2JpbGUgUGhv bmUgYW5kIEJlZXBlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3Jl Y2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NjYuDQoyMDAx IENoaW5hIEZpYnJlLU9wdGljYWwgQ29tbXVuaWNhdGlvbiBhbmQgRmlicmUtT3B0aWNhbCBQcm9w ZXJ0eSB0ZXN0ZXINCkluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNh c3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY3Lg0KMjAwMSBD aGluYSBEdXBsaWNhdG9yIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjY4Lg0KMjAw MSBDaGluYSBNYWlsIFByb2Nlc3NvciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1w OyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz42 OS4NCjIwMDEgQ2hpbmEgUGFwZXItY3V0dGluZyBNYWNoaW5lIEluZHVzdHJ5IGFuZCBNYXJrZXQ6 IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250 LWZhbWlseTrLzszlJz43MC4NCjIwMDEgQ2hpbmEgQXV0byBWZW5kaW5nIE1hY2hpbmUgSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+NzEuDQoyMDAxIENoaW5hIFBvcnRhbCBFbGVjdHJp YyBUb29sIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjcyLg0KMjAwMSBDaGluYSBT ZXdpbmcgTWFjaGluZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVj YXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz43My48c3Bhbg0K c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hpbmEgUGhvdG8g RW5sYXJnZXIgYW5kIFJlZHVjdGlvbg0KUHJpbnRlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWls eTrLzszlJz43NC4NCjIwMDEgQ2hpbmEgU2xpZGUgUHJvamVjdG9yIEluZHVzdHJ5IGFuZCBNYXJr ZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZv bnQtZmFtaWx5OsvOzOUnPjc1LjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L3NwYW4+MjAwMSBDaGluYSBQbG90dGVyIEVxdWlwbWVudCBJbmR1c3RyeQ0KYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9u dC1mYW1pbHk6y87M5Sc+NzYuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 IDwvc3Bhbj4yMDAxIENoaW5hIEVsZWN0cmljIExpZ2h0aW5nIGFuZCBTaWduYWwNCkVxdWlwbWVu dCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz43Ny4NCjIwMDEgQ2hpbmEgRWxlY3Ry aWMgRHJ5IE92ZW4gYW5kIEhlYXRlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1w OyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ NzguDQoyMDAxIENoaW5hIEJvYXJkaW5nIE1hY2hpbmUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBS ZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+NzkuDQoyMDAxIENoaW5hIFRyYWZmaWMgQ29udHJvbCBFcXVpcG1lbnQgSW5kdXN0 cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQQ0KRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjgwLg0KMjAwMSBDaGluYSBXYXJuaW5nIERldmlj ZSBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44MS4NCjIwMDEgQ2hpbmEgTmF2aWdh dGlvbiBSYWRpbyBGYWNpbGl0aWVzIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7 IEENCkZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44 Mi48c3Bhbg0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPjIwMDEgQ2hp bmEgTWV0YWwtTWluZSBkZXRlY3RvciBJbmR1c3RyeQ0KYW5kIE1hcmtldDogQSBSZXZpZXcgJmFt cDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ ODMuPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj4yMDAxIENo aW5hIFByZWNpcGl0YXRvciBJbmR1c3RyeSBhbmQNCk1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBG b3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODQuDQoy MDAxIENoaW5hIEluamVjdGlvbiBNYWNoaW5lLCBQbGFzdGljIENvbW1pbnV0b3IgYW5kIEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEENClJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz44NS4NCjIwMDEgQ2hpbmEgU2V0IE1pY3Jvc2Nv cGUgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODYuDQoyMDAxIENoaW5hIExvY2F0 aW5nIENvbXBhc3MgSW5kdXN0cnkgYW5kIE1hcmtldDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2Fz dCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+ODcuDQoyMDAxIENo aW5hIHJhbmdlZmluZGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjg4Lg0KMjAw MSBDaGluYSBCYXJvc3RhdCBhbmQgVGhlcm1vc3RhdCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJl dmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9udC1mYW1p bHk6y87M5Sc+ODkuDQoyMDAxIENoaW5hIE1hY2hpbmUgVG9vbHMgSW5kdXN0cnkgYW5kIE1hcmtl dDogQSBSZXZpZXcgJmFtcDsgQSBGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28taGFuc2ktZm9u dC1mYW1pbHk6y87M5Sc+OTAuDQoyMDAxIENoaW5hIEF1dG9tb2JpbGUgRXF1aXBtZW50IEluZHVz dHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9yZWNhc3QgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n bXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjkxLg0KMjAwMSBDaGluYSBNZWRpY2FsIEVxdWlw bWVudCBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBIEZvcmVjYXN0IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45Mi4NCjIwMDEgQ2hpbmEgR2Fz bWV0ZXIsIFdhdGVybWV0ZXIgYW5kIEVsZXRyb21ldGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEg UmV2aWV3DQomYW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZh bWlseTrLzszlJz45My4NCjIwMDEgQ2hpbmEgT2RvbWV0ZXIgYW5kIFZlbG9ncmFwaCBJbmR1c3Ry eSBhbmQgTWFya2V0OiBBIFJldmlldyAmYW1wOyBBDQpGb3JlY2FzdCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28taGFuc2ktZm9udC1mYW1pbHk6y87M5Sc+OTQuDQoyMDAxIENoaW5hIEFtbWV0ZXIsVm9sdG1l dGVyIGFuZCBNdWx0aW1ldGVyIEluZHVzdHJ5IGFuZCBNYXJrZXQ6PHNwYW4NCnN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5BIFJldmlldyAmYW1wOyBB IEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1oYW5zaS1mb250LWZhbWlseTrLzszlJz45NS4N CjIwMDEgQ2hpbmEgT1NDIEluZHVzdHJ5IGFuZCBNYXJrZXQ6IEEgUmV2aWV3ICZhbXA7IEEgRm9y ZWNhc3QgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWhhbnNpLWZvbnQtZmFtaWx5OsvOzOUnPjk2Lg0KMjAw MSBDaGluYSBSZXNpc3RhbmNlIFRlc3RlciBJbmR1c3RyeSBhbmQgTWFya2V0OiBBIFJldmlldyAm YW1wOyBBIEZvcmVjYXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8 IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlm XT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tdG9wOjBjbTttYXJn aW4tcmlnaHQ6MzAuMHB0O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0Og0KMTUuMHB0O21h cmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDoxNy4yNXB0O2xpbmUtaGVpZ2h0OjE1MCUn PjxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJc MDAwQgwiO2NvbG9yOm5hdnknPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5k aWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21hcmdpbi10b3A6MGNtO21h cmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6DQoxNS4wcHQ7 bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7bGluZS1oZWlnaHQ6MTUw JSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlwwMDBCDCI7Y29sb3I6bmF2eSc+TmFtZTogQzwvc3Bhbj48c3Bhbg0KbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjpu YXZ5Jz5oaW5hDQpDZW50ZXIgb2YgSW5mb3JtYXRpb24gSW5kdXN0cnkgRGV2ZWxvcG1lbnQoPC9z cGFuPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJcMDAwQgwiO2NvbG9yOm5hdnknPkNDSUQpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBz dHlsZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz48c3Bhbg0Kc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFu DQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvc3Bhbj5NaWNyb2VsZWN0cm9uaWNz IFJlc2VyY2ggRGVwYXJ0bWVudChNUkQpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHls ZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTtt YXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcu MjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5BZGRyZXNzPC9zcGFuPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYXNjaWktZm9udC1mYW1pbHk6IlwwMDBC DCI7bXNvLWhhbnNpLWZvbnQtZmFtaWx5Og0KIlwwMDBCDCI7Y29sb3I6bmF2eSc+o7o8L3NwYW4+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJc MDAwQgwiO2NvbG9yOm5hdnknPkNoaW5hIFNlbWljb25kdWN0b3IgSW5kdXN0cnkNCkFzc29jaWF0 aW9uLjI3LFJkLndhbnNob3VsdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21h cmdpbi10b3A6MGNtO21hcmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2lu LWxlZnQ6DQoxNS4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7 bGluZS1oZWlnaHQ6MTUwJSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2eSc+UEM8L3NwYW4+PHNwYW4NCnN0eWxl PSdmb250LXNpemU6MTAuMHB0O21zby1hc2NpaS1mb250LWZhbWlseToiXDAwMEIMIjttc28taGFu c2ktZm9udC1mYW1pbHk6DQoiXDAwMEIMIjtjb2xvcjpuYXZ5Jz6jujwvc3Bhbj48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29s b3I6bmF2eSc+MTAwODQ2PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2lu LXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVm dDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcuMjVwdDtsaW5l LWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5XZWJzaXRlPC9zcGFuPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdDttc28tYXNjaWktZm9udC1mYW1pbHk6IlwwMDBCDCI7bXNvLWhh bnNpLWZvbnQtZmFtaWx5Og0KIlwwMDBCDCI7Y29sb3I6bmF2eSc+o7o8L3NwYW4+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmNvbG9yOm5hdnknPjxhIGhyZWY9Imh0 dHA6Ly93d3cuY2NpZC1tcmQuY29tLmNuLyI+d3d3LmNjaWQtbXJkLmNvbS5jbjwvYT48L3NwYW4+ PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7Y29sb3I6bmF2eSc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBz dHlsZT0nbWFyZ2luLXRvcDowY207bWFyZ2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tbGVmdDoNCjE1LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAlJz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiXDAwMEIMIjtjb2xvcjpuYXZ5Jz5FTUFJTDogPGENCmhy ZWY9Im1haWx0bzpndW95aXJhbkBjY2lkLW1yZC5jb20uY24iPmd1b3lpcmFuQGNjaWQtbXJkLmNv bS5jbjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tdG9wOjBj bTttYXJnaW4tcmlnaHQ6MzAuMHB0O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0Og0KMGNt O21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDoxNTAlJz48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2 eSc+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoNCnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YQ0K aHJlZj0ibWFpbHRvOk5FV1NAY2NpZC1tcmQuY29tLmNuIj5ORVdTQGNjaWQtbXJkLmNvbS5jbjwv YT48L3NwYW4+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OiJcMDAwQgwiO2Nv bG9yOiM2NjMzMDAnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21hcmdpbi10 b3A6MGNtO21hcmdpbi1yaWdodDozMC4wcHQ7bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6 DQoxNS4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50OjE3LjI1cHQ7bGluZS1o ZWlnaHQ6MTUwJSc+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6bmF2eSc+VEVMOjxzcGFuDQpzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyA8L3NwYW4+ODYtMTAtNjgyMDg1OTIsPHNwYW4NCnN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU4OSZuYnNwOzwvc3Bhbj48 c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMw MCc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2luLXRvcDowY207bWFy Z2luLXJpZ2h0OjMwLjBwdDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDoNCjE1LjBwdDtt YXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6MTcuMjVwdDtsaW5lLWhlaWdodDoxNTAl Jz48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi XDAwMEIMIjtjb2xvcjpuYXZ5Jz5GYXg6PHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU5MCAsPHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7IDwvc3Bhbj44Ni0xMC02ODIwODU5NDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVT DQpzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMwMCc+PG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9J3RleHQtaW5kZW50OjMx LjVwdDttc28tY2hhci1pbmRlbnQtY291bnQ6My4wOw0KbXNvLWNoYXItaW5kZW50LXNpemU6MTAu NXB0Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseToiXDAwMEIMIjsNCmNvbG9y OiMzMzY2RkYnPkNvbnRhY3Q6PC9zcGFuPjxzcGFuIHN0eWxlPSdtc28tYXNjaWktZm9udC1mYW1p bHk6IlwwMDBCDCI7DQptc28taGFuc2ktZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzMzNjZG Ric+oaE8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtZmFtaWx5OiJcMDAwQgwi O2NvbG9yOiM2NjMzMDAnPkd1bzxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46DQp5ZXMiPiZuYnNw OyA8L3NwYW4+WWlyYW4gKDwvc3Bhbj48c3BhbiBzdHlsZT0nbXNvLWFzY2lpLWZvbnQtZmFtaWx5 OiJcMDAwQgwiOw0KbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiJcMDAwQgwiO2NvbG9yOiM2NjMzMDAn Prn50uPIuzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1mYW1pbHk6IlwwMDBC DCI7Y29sb3I6IzY2MzMwMCc+KSAsPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoNCnllcyI+Jm5i c3A7IDwvc3Bhbj5Mb3Vpc2EgTHYoPC9zcGFuPjxzcGFuIHN0eWxlPSdtc28tYXNjaWktZm9udC1m YW1pbHk6IlwwMDBCDCI7DQptc28taGFuc2ktZm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2 MzMwMCc+wsDV3Dwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1mYW1pbHk6Ilww MDBCDCI7Y29sb3I6IzY2MzMwMCc+KSAsIDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0n Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCmNvbG9yOiM2NjMzMDAnPkx5ZGllIExpKDwvc3Bhbj48c3BhbiBzdHlsZT0nbXNv LWFzY2lpLWZvbnQtZmFtaWx5OiJcMDAwQgwiOw0KbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiJcMDAw QgwiO2NvbG9yOiM2NjMzMDAnPsDusK67qjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0n Zm9udC1mYW1pbHk6IlwwMDBCDCI7Y29sb3I6IzY2MzMwMCc+KTwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_========_000000182_========_ From cyeoh@samba.org Wed Feb 27 05:20:40 2002 From: cyeoh@samba.org (Christopher Yeoh) Date: Wed, 27 Feb 2002 16:20:40 +1100 Subject: Extra symbols required Message-ID: <15484.27816.486875.32816@gargle.gargle.HOWL> The following symbols aren't in the LSB specification, but "bad things" (strange behaviour or segfaults) happen to some binaries if they are not present in the stub libraries (although programs still link ok). If these symbols aren't included in the shared libraries they instead appear in the static portion of the binary as just undefined symbols. Interestingly lsbappchk doesn't pick these up (I'm not sure why yet). _IO_stdin_used __cxa_finalize __deregister_frame_info __register_frame_info So I think we need to add the above to the LSB specification. Regards, Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From pthomas@suse.de Wed Feb 27 11:23:56 2002 From: pthomas@suse.de (Philipp Thomas) Date: Wed, 27 Feb 2002 12:23:56 +0100 Subject: Extra symbols required In-Reply-To: <15484.27816.486875.32816@gargle.gargle.HOWL>; from cyeoh@samba.org on Wed, Feb 27, 2002 at 04:20:40PM +1100 References: <15484.27816.486875.32816@gargle.gargle.HOWL> Message-ID: <20020227122356.F12207@jeffreys.suse.de> * Christopher Yeoh (cyeoh@samba.org) [20020227 06:24]: > __deregister_frame_info > __register_frame_info > > So I think we need to add the above to the LSB specification. These come from libgcc and are needed for exception handling. Current glibc imports them from libgcc and then reexports them again. With the upcoming gcc 3.1 and sufficiently recent binutils, gcc uses the special ELF header PT_GNU_EH_FRAME so no extra functions for registering/deregistering eh frame info are needed anymore. Given the above, I'm not sure if LSB should add them. Philipp -- Philipp Thomas Development, SuSE Linux AG, Deutscherrnstr. 15-19, D-90429 Nuremberg, Germany From cyeoh@samba.org Thu Feb 28 05:00:44 2002 From: cyeoh@samba.org (Christopher Yeoh) Date: Thu, 28 Feb 2002 16:00:44 +1100 Subject: Extra symbols required In-Reply-To: <20020227122356.F12207@jeffreys.suse.de> References: <15484.27816.486875.32816@gargle.gargle.HOWL> <20020227122356.F12207@jeffreys.suse.de> Message-ID: <15485.47484.601965.141668@gargle.gargle.HOWL> At 2002/2/27 12:23+0100 Philipp Thomas writes: > * Christopher Yeoh (cyeoh@samba.org) [20020227 06:24]: > > > __deregister_frame_info > > __register_frame_info > > > > So I think we need to add the above to the LSB specification. > > These come from libgcc and are needed for exception handling. Current glibc > imports them from libgcc and then reexports them again. Are these only needed for C++ exceptions? If so then we can happily drop them since C++ isn't in the spec yet. Regards, Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From shockwave@tlh.com.ar Thu Feb 28 12:20:37 2002 From: shockwave@tlh.com.ar (shockwave) Date: Thu, 28 Feb 2002 04:20:37 -0800 Subject: unsubscribe Message-ID: <023801c1c055$9a5ca300$89b30dd1@hard> This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C1C00F.45D4C920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0049_01C1C00F.45D4C920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
    ------=_NextPart_000_0049_01C1C00F.45D4C920-- From shockwave@tlh.com.ar Thu Feb 28 12:20:42 2002 From: shockwave@tlh.com.ar (shockwave) Date: Thu, 28 Feb 2002 04:20:42 -0800 Subject: No subject Message-ID: <023901c1c055$9ba32cc0$89b30dd1@hard> This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C1C00F.494537C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe ------=_NextPart_000_0051_01C1C00F.494537C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    unsubscribe
     
    ------=_NextPart_000_0051_01C1C00F.494537C0-- From pthomas@suse.de Thu Feb 28 10:14:00 2002 From: pthomas@suse.de (Philipp Thomas) Date: Thu, 28 Feb 2002 11:14:00 +0100 Subject: Extra symbols required In-Reply-To: <15485.47484.601965.141668@gargle.gargle.HOWL>; from cyeoh@samba.org on Thu, Feb 28, 2002 at 04:00:44PM +1100 References: <15484.27816.486875.32816@gargle.gargle.HOWL> <20020227122356.F12207@jeffreys.suse.de> <15485.47484.601965.141668@gargle.gargle.HOWL> Message-ID: <20020228111400.K12207@jeffreys.suse.de> * Christopher Yeoh (cyeoh@samba.org) [20020228 06:45]: > Are these only needed for C++ exceptions? Yes, that's the case. The only reason they're present in C libraries is that these must be compiled with -fexeptions if C++ code wants to throw through C code. Philipp -- Philipp Thomas SuSE Linux AG, Deutscherrnstr. 15-19, D-90429 Nuremberg, Germany