<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>4698</bug_id>
          
          <creation_ts>2002-07-08 09:45 0000</creation_ts>
          <short_desc>emerge world or system does not update all slots</short_desc>
          <delta_ts>2008-01-30 16:47:39 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Portage Development</product>
          <component>Unclassified (old)</component>
          <version>unspecified</version>
          <rep_platform>x86</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <keywords>InSVN</keywords>
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          <dependson>93469</dependson>
          <blocked>19409</blocked>
    
    <blocked>28423</blocked>
    
    <blocked>28471</blocked>
    
    <blocked>48719</blocked>
    
    <blocked>147007</blocked>
    
    <blocked>155723</blocked>
          
          <everconfirmed>1</everconfirmed>
          <reporter>phil@thenexusproject.org</reporter>
          <assigned_to>dev-portage@gentoo.org</assigned_to>
          <cc>anakin.skyw@gmx.de</cc>
    
    <cc>andre.hinrichs@gmx.de</cc>
    
    <cc>ansla80@yahoo.com</cc>
    
    <cc>azarah@gentoo.org</cc>
    
    <cc>betelgeuse@gentoo.org</cc>
    
    <cc>bgo@kunst-lichter.de</cc>
    
    <cc>bugs.gentoo.org@lukas-graf.ch</cc>
    
    <cc>carpaski@gentoo.org</cc>
    
    <cc>caster@gentoo.org</cc>
    
    <cc>chris@novazur.fr</cc>
    
    <cc>chutz@gg3.net</cc>
    
    <cc>david@chanial.com</cc>
    
    <cc>drobbins@gentoo.org</cc>
    
    <cc>gentoo-a7x@scientician.org</cc>
    
    <cc>gentoo@phong.org</cc>
    
    <cc>gentoo@schirmeier.com</cc>
    
    <cc>greg_g@gentoo.org</cc>
    
    <cc>hannes@gentoo.org</cc>
    
    <cc>isaachanson@omnidox.com</cc>
    
    <cc>jmachowinski@gmx.de</cc>
    
    <cc>jochen.eisinger@gmx.de</cc>
    
    <cc>kgw@mineralien-verkauf.de</cc>
    
    <cc>Klaus.Kusche@inode.at</cc>
    
    <cc>m.debruijne@matrict.nl</cc>
    
    <cc>martin.zwickel@technotrend.de</cc>
    
    <cc>mholzer@gentoo.org</cc>
    
    <cc>moixa@gmx.ch</cc>
    
    <cc>mrfree@infinito.it</cc>
    
    <cc>news@derived-software.ltd.uk</cc>
    
    <cc>nikolas@garofil.be</cc>
    
    <cc>oldium.pro@seznam.cz</cc>
    
    <cc>piezza@evil-corporation.com</cc>
    
    <cc>pookey@pookey.co.uk</cc>
    
    <cc>r.s.a.vandomburg@student.utwente.nl</cc>
    
    <cc>radek@podgorny.cz</cc>
    
    <cc>robbat2@gentoo.org</cc>
    
    <cc>rossi.f@inwind.it</cc>
    
    <cc>scsichen@gmail.com</cc>
    
    <cc>seemant@gentoo.org</cc>
    
    <cc>sllewbj@blueyonder.co.uk</cc>
    
    <cc>sven.koehler@gmail.com</cc>
    
    <cc>theo@crazygreek.co.uk</cc>
    
    <cc>tom@tomaw.net</cc>
    
    <cc>toralf.foerster@gmx.de</cc>
    
    <cc>utx@penguin.cz</cc>
    
    <cc>vhata-gentoo@rucus.ru.ac.za</cc>
    
    <cc>wschlich@gentoo.org</cc>
    
    <cc>ykoehler@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>phil@thenexusproject.org</who>
            <bug_when>2002-07-08 09:45:25 0000</bug_when>
            <thetext>Me and drobbins were talking about this earlier this morning.  When you do an
&apos;emerge --update foo-pkg&apos; and foo-pkg has a number of different versions, all
slotted, it only updates the &apos;latest&apos; slot--i.e. 2 instead of 1.2.  This is a
problem, since the existence of a SLOTted 1.2 version on the machine implies
that it is being used and should be updated regularly.  You can still explicitly
state the updated version, of course, but &apos;emerge --update&apos; should catch all of
the updates of all of the SLOTs.

I also tentatively suggest that &apos;emerge --update&apos; NOT work on packages with
SLOT=&quot;&quot; if other SLOTs are present.  This is to enforce the current standard of
making sure that SLOT has a value other than NULL, and is another quick check
that can get rid of some developer error.  If other SLOTs are not present,
however, it should do an update as normal, since it&apos;s assumed that we simply
haven&apos;t gotten around to SLOTting those ebuilds yet.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>phil@thenexusproject.org</who>
            <bug_when>2002-07-08 09:46:14 0000</bug_when>
            <thetext>cc&apos;ing drobbins per our conversation.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>Klaus.Kusche@inode.at</who>
            <bug_when>2002-11-02 12:47:28 0000</bug_when>
            <thetext>Me, too, suffered from it today.
If one relies on &quot;update world&quot; only, it is very hard to find out which packages
are really affected and need manual updating to keep the system current (there
were four of them on my system, among them glib and gtk+).

Please make &quot;emerge world&quot; work on all slots!</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>azarah@gentoo.org</who>
            <bug_when>2002-12-03 04:29:56 0000</bug_when>
            <thetext>Nick, not sure if this is still an issue.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>azarah@gentoo.org</who>
            <bug_when>2002-12-25 14:45:46 0000</bug_when>
            <thetext>Seems fine to me with portage-2.0.46, although it does have a small cosmetic
error ...

-----------
nosferatu env.d # emerge -up --deep world

These are the packages that I would merge, in order:

Calculating world dependencies ...done!

[ebuild    UD] x11-libs/gtk+-1.2.10-r10 [2.2.0-r0]
[ebuild    U ] x11-libs/gtk+-2.2.0-r1 [2.2.0-r0]

nosferatu env.d # 
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>Klaus.Kusche@inode.at</who>
            <bug_when>2002-12-25 14:58:29 0000</bug_when>
            <thetext>What&apos;s --deep?

I&apos;ve 2.0.46, but it is neither in the man page nor in the usage message of emerge.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>azarah@gentoo.org</who>
            <bug_when>2002-12-26 13:26:12 0000</bug_when>
            <thetext>Nick, I thought you added the &apos;--deep&apos; switch to the docs?
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>phil@thenexusproject.org</who>
            <bug_when>2002-12-26 14:34:28 0000</bug_when>
            <thetext>I just added --deep to the man page; someone can gladly add it to the actual
internal executable documentation.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2003-02-25 15:15:54 0000</bug_when>
            <thetext>*** Bug 13968 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>hannes@gentoo.org</who>
            <bug_when>2003-03-03 18:10:59 0000</bug_when>
            <thetext>*** Bug 16639 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2003-04-27 15:47:10 0000</bug_when>
            <thetext>*** Bug 20061 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>mholzer@gentoo.org</who>
            <bug_when>2003-05-22 13:46:27 0000</bug_when>
            <thetext>*** Bug 11888 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>utx@penguin.cz</who>
            <bug_when>2003-06-05 10:54:28 0000</bug_when>
            <thetext>There should be also a way to merge only specific slot - e.g. using
emerge x11-libs/gtk+:1
or
x11-libs/gtk+/1
or something similar.

This is needed for my script revdep-debuild (gentoolkit) (see comment for bug 22161).</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>p.lietz@gmx.de</who>
            <bug_when>2003-07-10 11:40:06 0000</bug_when>
            <thetext>I have the following problem with portage 2.0.48-r1:

The output of &quot;emerge -up --deep world&quot; correctly suggests that I update the &quot;slot 1&quot; version of gnome-base/gconf:

...
[ebuild    U ] gnome-base/gconf-1.0.8-r5 [2.2.0]
...

The output of &quot;etcat -v ^gconf$&quot; supports that as well:

*  gnome-base/gconf :
        [  I] gnome-base/gconf-1.0.8-r3 (1)
        [M~ ] gnome-base/gconf-1.0.8-r4 (1)
        [   ] gnome-base/gconf-1.0.8-r5 (1)
        [  I] gnome-base/gconf-2.2.0 (2)
        [M~ ] gnome-base/gconf-2.2.1 (2)

However, if I issue &quot;emerge -up gconf&quot; I get:

These are the packages that I would merge, in order:
 
Calculating dependencies ...done!

So I take it that update world acts correctly while updating a single, slotted version of a package does not.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2003-07-16 15:04:59 0000</bug_when>
            <thetext>*** Bug 24612 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>mholzer@gentoo.org</who>
            <bug_when>2003-07-17 07:58:18 0000</bug_when>
            <thetext>*** Bug 24672 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>David.Huff@computer-critters.com</who>
            <bug_when>2003-07-17 14:22:27 0000</bug_when>
            <thetext>Apache was the last thing I wanted to have this problem.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vericgar@gentoo.org</who>
            <bug_when>2003-07-20 23:11:03 0000</bug_when>
            <thetext>This seems related, I&apos;m not sure if it warrents a new bug or not.

The SLOT mechanism seems to be causing confusion in many packages (Apache is an example) where you have one SLOT installed, and portage when doing an emerge -p world is wanting to install another SLOT due to a higher version number (not upgrade, but install beside it). Different SLOTs should be different upgrade paths, and that&apos;s what the documentation seems to imply:

http://www.gentoo.org/doc/en/portage-manual.xml
&quot;Most distributions and ports systems tend to have a &quot;freetype&quot; package for freetype 1.x and &quot;freetype2&quot; for 2.x. We consider this approach a sign of a fundamentally broken package management system. We simply assigned the SLOT number 1 to the first and number 2 to the second. With this information Portage can track both versions and upgrade both versions if updates to the respective upstream branches are made.&quot;</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2003-07-22 20:50:06 0000</bug_when>
            <thetext>*** Bug 25040 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2003-07-25 15:17:18 0000</bug_when>
            <thetext>*** Bug 23034 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>nakano@gentoo.org</who>
            <bug_when>2003-08-03 15:29:10 0000</bug_when>
            <thetext>I made a patch for fixing this bug.
But I&apos;m not sure it&apos;s correct because SLOT is very complicated ;)

Please test it and do feedback.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>nakano@gentoo.org</who>
            <bug_when>2003-08-03 15:30:40 0000</bug_when>
            <thetext>Created an attachment (id=15446)
the patch for emerge/portage.py
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2003-08-07 16:14:54 0000</bug_when>
            <thetext>*** Bug 26139 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genone@gentoo.org</who>
            <bug_when>2003-08-07 19:54:33 0000</bug_when>
            <thetext>I have some problems with the patch, I&apos;ll show you some examples (only the important parts):

Without patch:

# emerge -p =sys-devel/gcc-2.95.3-r7
!!! all ebuilds that could satisfy &quot;=sys-devel/gcc-2.95.3-r7&quot; have been masked.

# emerge -p /usr/portage/sys-devel/gcc/gcc-2.95.3-r7.ebuild
[ebuild     U ] sys-devel/gcc-2.95.3-r7 [3.2.3-r1] 

# emerge -p apache
[ebuild  N    ] net-www/apache-2.0.47  

With patch:
# emerge -p =sys-devel/gcc-2.95.3-r7
(nothing)

# emerge /usr/portage/sys-devel/gcc/gcc-2.95.3-r7.ebuild
[ebuild     U-] sys-devel/gcc-2.95.3-r7  

# emerge -p apache
[ebuild  N    ] net-www/apache-1.3.28  
[ebuild  N    ] net-www/apache-2.0.47  

So the output for the gcc thing is wrong and inconsistent, and I don&apos;t like behavior for apache:
It is nice to show that there are two SLOTs available, but IMO there are few people actually using both versions parallel and the behavior is not consistent with dependency handling. I&apos;d prefer portage to abort in such a situation (when two SLOTs are available with no preference) and print a message that the user has to choose a specific version. It would also confuse people that don&apos;t know about SLOT as there is no indication in the output.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>nakano@gentoo.org</who>
            <bug_when>2003-08-07 22:15:04 0000</bug_when>
            <thetext>hi, Marius
Thank you for reply.

I fixed a bug that emerge is normal end when a package doesn&apos;t exist.

And I modified as you said about second problem, which i don&apos;t think problem.
I&apos;m not sure which is best solution.

Examples, (English message is just sample. I&apos;m not native English, as you know)
# emerge -p apache

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[multi B     ] net-www/apache-1.3.28 [1]
[multi B     ] net-www/apache-2.0.47 [2]

You need to select one version
Example, &quot;emerge =net-www/apache-2.0.47&quot;
You can install both of them, if you emerge twice.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>nakano@gentoo.org</who>
            <bug_when>2003-08-07 22:15:35 0000</bug_when>
            <thetext>Created an attachment (id=15727)
patch for portage.py/emerge
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genone@gentoo.org</who>
            <bug_when>2003-08-09 17:55:06 0000</bug_when>
            <thetext>hmm, the blocking stuff is nice, but there are still several problems:
- all kernel versions are slotted, so we get the blocking message for every kernel emerge
- the gcc problem in my last post still exists
- when I want to emerge a SLOTed without -p, the error message uses tha lowest available version
- I get a traceback on emerge -ep world:
\Traceback (most recent call last):
  File &quot;/usr/bin/emerge&quot;, line 2065, in ?
    if not mydepgraph.xcreate(myaction):
  File &quot;/usr/bin/emerge&quot;, line 989, in xcreate
    if not self.create(myk):
  File &quot;/usr/bin/emerge&quot;, line 682, in create
    if not self.select_dep(&quot;/&quot;,mydep[&quot;/&quot;],myparent=mp):
  File &quot;/usr/bin/emerge&quot;, line 885, in select_dep
    if not self.create(myk,myparent):
  File &quot;/usr/bin/emerge&quot;, line 682, in create
    if not self.select_dep(&quot;/&quot;,mydep[&quot;/&quot;],myparent=mp):
  File &quot;/usr/bin/emerge&quot;, line 885, in select_dep
    if not self.create(myk,myparent):
  File &quot;/usr/bin/emerge&quot;, line 695, in create
    if not self.select_dep(myroot,edepend[&quot;PDEPEND&quot;]):
  File &quot;/usr/bin/emerge&quot;, line 805, in select_dep
    print &quot;\nemerge: there are no masked or unmasked ebuilds to satisfy &quot;+arg+&quot;.&quot;
TypeError: cannot concatenate &apos;str&apos; and &apos;NoneType&apos; objects
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>utx@penguin.cz</who>
            <bug_when>2003-08-10 05:42:29 0000</bug_when>
            <thetext>Please make also possible to update specific slot only, for example by:
emerge -n -u net-www/apache:1

This feature will be very useful for revdep-rebuild.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>mholzer@gentoo.org</who>
            <bug_when>2003-08-10 06:30:59 0000</bug_when>
            <thetext>*** Bug 26210 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2003-08-10 12:27:35 0000</bug_when>
            <thetext>i dont see how doing :1 and -1* is any easier ... 
plus, i dont really see how revdep-rebuild would benefit from the change ... </thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>nakano@gentoo.org</who>
            <bug_when>2003-08-10 14:11:11 0000</bug_when>
            <thetext>Created an attachment (id=15866)
patch for portage.py/emerge

&gt;- all kernel versions are slotted, so we get the blocking message for every
kernel emerge

Is this a problem?

&gt;- the gcc problem in my last post still exists
Fixed

&gt;- when I want to emerge a SLOTed without -p, the error message uses tha lowest
available version

Which package is it?

&gt;- I get a traceback on emerge -ep world:
Fixed
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>nakano@gentoo.org</who>
            <bug_when>2003-08-11 23:47:35 0000</bug_when>
            <thetext>hi, Stanislav

I thought a way to specify SLOT by emerge before.
example
# emerge apache:1
DEPEND=&quot;net-www/apache:1&quot;
etc...

But if we discuss it here, this bug will be complicated.
I think we should discuss about this in another new bug.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>utx@penguin.cz</who>
            <bug_when>2003-08-14 13:52:51 0000</bug_when>
            <thetext>emerge apache:1 does not work for me:
Calculating dependencies
emerge: there are no masked or unmasked ebuilds to satisfy &quot;apache:1&quot;.
 
!!! Error calculating dependencies. Please correct.

Separate bug, which explains, why revdep-rebuild needs SLOTted emerge command: see bug 22161. I have added new comment.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genone@gentoo.org</who>
            <bug_when>2003-08-15 00:03:46 0000</bug_when>
            <thetext>&gt;&gt;- all kernel versions are slotted, so we get the blocking message for every
&gt;&gt;  kernel emerge
&gt; Is this a problem?

It is a problem as either world updates would not include kernel updates anymore or world updates will break unless you update your kernel before. Both cases would be very irritating and annoying for users. The main issue is that EVERY single version is in its own SLOT.
Ok, that&apos;s the theory, the actual results are even more confusing. See the attachment of the output of emerge -upvD world with patched and unpatched portage. Why is it upgrading ac-sources to a different SLOT, downgrading nautilus and gdm and upgrading gdm later?

&gt;&gt;- when I want to emerge a SLOTed package without -p, the error message uses
&gt;&gt;  the lowest available version
&gt; Which package is it?

Tested with mm-sources and other packages (don&apos;t remember all of them).</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genone@gentoo.org</who>
            <bug_when>2003-08-15 00:05:38 0000</bug_when>
            <thetext>Created an attachment (id=16126)
output of emerge -upvD world
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>nakano@gentoo.org</who>
            <bug_when>2003-08-30 15:01:59 0000</bug_when>
            <thetext>I think it&apos;s this story.

1. You already installed gnome-1.4.
2. There is gnome-1.4-r3 in Portage tree.
3. emerge will install gnome-1.4-r3 even if gnome-2.* is installed.
4. gnome-base/gnome-1.4-r3 depends on &quot;&lt;gnome-base/gdm-2.4&quot;
5. you already installed gdm-2.4.1.4
6. gdm has no SLOT(all SLOT=&quot;0&quot;)
7. then emerge will merge gdm-2.2.5.4 and unmerge gdm-2.4.1.4

The patched emerge is correct, I think. The unpatched ebuild will not do No3-7.

And I think it&apos;s also gnome ebuilds bug because gnome-base/gnome
has SLOT but gnome-base/{gdm,nautilus} have no SLOT.

What do you think?
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genone@gentoo.org</who>
            <bug_when>2003-09-11 13:53:55 0000</bug_when>
            <thetext>I think you&apos;re right about the gnome/gdm stuff, a lot of the gnome/gtk stuff doesn&apos;t use SLOTs where it should. The kernel thing is still confusing me though, why does it upgrade to a different SLOT ?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>drobbins@gentoo.org</who>
            <bug_when>2003-09-11 16:10:56 0000</bug_when>
            <thetext>kernel sources? because kernel sources can co-exist on disk. Slots are for packages that can co-exist with other versions of the same package on disk (and still function correctly.)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genone@gentoo.org</who>
            <bug_when>2003-09-11 16:31:51 0000</bug_when>
            <thetext>Sure they can, I&apos;m wondering how the patch affects kernels or other things were each version is in a different SLOT. As I understand it packages should only be upgraded in their own slot. But I&apos;ve found a possible explanation for this: Maybe the kernel ws an exception because it was in the world file. But on the contrary mm-sources was upgraded without the patch, but not with the patch :-/ So I have one kernel package upgraded and one not upgraded which is clearly incorrect.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dirk.heinrichs.ext@nsn.com</who>
            <bug_when>2004-06-17 01:32:54 0000</bug_when>
            <thetext>While you&apos;re at it: IMHO emerge -update also should _not_ install packages from currently not installed slots. i.e. I use ~x86 and &quot;emerge -DUu world&quot; wants to upgrade KDE 3.2.2 -&gt; 3.2.3 in slot 3.2 and install new kde 3.3.0_alpha1 packages in slot 3.3. The latter shouldn&apos;t only happen if the version from the new slot is a dependency of a new version of an allready installed package.

</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jstubbs@gentoo.org</who>
            <bug_when>2005-04-11 07:02:21 0000</bug_when>
            <thetext>*** Bug 88495 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>carlo@gentoo.org</who>
            <bug_when>2005-07-14 05:26:56 0000</bug_when>
            <thetext>Please take into account that there can be slot issues with one and the same
package and it&apos;s slotted (second level) dependencies, too. &gt;&gt; Bug 98425</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jstubbs@gentoo.org</who>
            <bug_when>2005-10-07 08:10:44 0000</bug_when>
            <thetext>*** Bug 28380 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jstubbs@gentoo.org</who>
            <bug_when>2005-10-07 09:10:07 0000</bug_when>
            <thetext>*** Bug 47345 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jstubbs@gentoo.org</who>
            <bug_when>2005-10-23 04:05:55 0000</bug_when>
            <thetext>*** Bug 97886 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2005-11-18 10:04:05 0000</bug_when>
            <thetext>*** Bug 112933 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>sllewbj@blueyonder.co.uk</who>
            <bug_when>2006-01-05 15:15:55 0000</bug_when>
            <thetext>What is the status of this bug?  Is there any plan to ever fix it?

Because &quot;emerge --update --deep world&quot; doesn&apos;t seem to update older slots,
is there any alternative command that will find all such older slots that
need updating and update them?  (Or maybe also determine that some older
slots are no longer needed and recommend their removal?)
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>antarus@gentoo.org</who>
            <bug_when>2006-01-05 19:47:32 0000</bug_when>
            <thetext>(In reply to comment #46)
&gt; What is the status of this bug?  Is there any plan to ever fix it?
&gt; 
&gt; Because &quot;emerge --update --deep world&quot; doesn&apos;t seem to update older slots,
&gt; is there any alternative command that will find all such older slots that
&gt; need updating and update them?  (Or maybe also determine that some older
&gt; slots are no longer needed and recommend their removal?)
&gt; 

There is no alternative and it depends on a new resolver.  We have plans for a new resolver, but no code yet.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genone@gentoo.org</who>
            <bug_when>2006-01-16 09:38:22 0000</bug_when>
            <thetext>*** Bug 119210 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>news@derived-software.ltd.uk</who>
            <bug_when>2006-01-17 11:25:00 0000</bug_when>
            <thetext>Just got tripped up with this with gcc (slots 3.4 and 4.0).  Sigh.  That&apos;ll teach me to not read up on known slot problems.

I only realised there was a problem when I did &quot;equery l gcc&quot; and found that my 3.4 gcc installation was actually masked (or, more precisely, didn&apos;t exist in portage any more).</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2006-03-30 09:07:23 0000</bug_when>
            <thetext>*** Bug 128118 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>oldium.pro@seznam.cz</who>
            <bug_when>2006-03-30 09:10:48 0000</bug_when>
            <thetext>Is there some new status of this item in new portage? I cannot see any difference - for example sun-jdk 1.4 is still ignored in updates, if you have 1.5 installed. Some plans to have it?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2006-04-03 08:43:57 0000</bug_when>
            <thetext>*** Bug 128644 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2006-04-11 09:15:02 0000</bug_when>
            <thetext>*** Bug 129600 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>pookey@pookey.co.uk</who>
            <bug_when>2006-06-17 15:07:25 0000</bug_when>
            <thetext>I&apos;ve just had this problem - I have a KDE installed in slot 7, and found that slot 3.5 hasn&apos;t been updated for sometime. attempting to move to GCC 4.1.1 resulting in revdep-rebuilt trying to emerge --oneshot a whole load of KDE-3.5 packages that are no longer in portage, despite the fact I&apos;ve been regular with my emerge --update&apos;s.

The fact that this problem with slots not being upgraded isn&apos;t mentioned at all in the emerge man page worries me a little - this issue could result in outdated packages on your system, and this in turn surely could result in security issues being present. (take for example in my case, the various security issues in KDM -  the KDE login manager).

Anyway, I solved my problem doing this (i&apos;m sure htis command could be improved upon, effeciency wans&apos;t in mind here, I just wanted to get it done ;) )

# equery list --duplicates | grep &quot;\(3.5\)&quot; | grep kde-base | sed &quot;s/\(.*-3.5\).*/\1/&quot; | sed &quot;s/\(.*\)/=\1*/&quot; | xargs emerge --update -pv 
 </thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>caster@gentoo.org</who>
            <bug_when>2006-07-13 15:59:11 0000</bug_when>
            <thetext>Missed the bug&apos;s fourth birthday :(</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>richard@garandnet.net</who>
            <bug_when>2006-07-13 16:44:54 0000</bug_when>
            <thetext>(In reply to comment #55)
&gt; Missed the bug&apos;s fourth birthday :(

Fear not, there will be many more to come... it&apos;s still a &quot;new&quot; bug.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2006-07-14 02:53:58 0000</bug_when>
            <thetext>*** Bug 140293 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>phil@thenexusproject.org</who>
            <bug_when>2006-07-14 15:36:30 0000</bug_when>
            <thetext>Surely one of the portage developers would love to take on this delightful task?  If only in honour of its fourth birthday?  I really /did/ have a conversation with drobbins back then about how it was incorrect behaviour ... :)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genone@gentoo.org</who>
            <bug_when>2006-07-14 19:07:02 0000</bug_when>
            <thetext>dep resolver donations are welcome.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>zmedico@gentoo.org</who>
            <bug_when>2006-07-15 00:39:19 0000</bug_when>
            <thetext>In the case of `emerge -uD world`, it seems like we&apos;d need support for slot deps in the world set. The alternative would be to simply use an &quot;all&quot; package set (bug 96088) to pull in the lower slots.

The case of `emerge -u &lt;atom&gt;` is relatively easy to support since it only needs to see which slots are matched by the command (depending on which slots are installed) and pull in the appropriate updates.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2006-07-16 00:21:48 0000</bug_when>
            <thetext>*** Bug 140591 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2006-08-21 04:17:10 0000</bug_when>
            <thetext>*** Bug 144622 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2006-08-29 10:19:18 0000</bug_when>
            <thetext>*** Bug 145497 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2006-09-10 12:31:33 0000</bug_when>
            <thetext>*** Bug 147093 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cardoe@gentoo.org</who>
            <bug_when>2006-09-18 08:40:20 0000</bug_when>
            <thetext>According to Brian Harring, it&apos;s not the highest SLOT it&apos;s the highest package version.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cardoe@gentoo.org</who>
            <bug_when>2006-09-18 08:44:11 0000</bug_when>
            <thetext>Enjoy your bug spam. (Sorry)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gentoo@schirmeier.com</who>
            <bug_when>2006-09-19 11:39:25 0000</bug_when>
            <thetext>Just curious, when is this going to be fixed? This &quot;feature&quot; is a PITA on my current revdep-rebuild run (due to libssl/libcrypto ABI breakage), _many_

emerge: there are no ebuilds to satisfy &quot;=foo/bar-1.2.3-r4&quot;.

to be resolved manually by emerging the newest ebuild in that slot (and having to re-run revdep-rebuild each time, or manually edit the .revdep-rebuild tmp files).

This bug is really annoying, and as it is in bugzilla for more than four years(!) now, I wonder whether it will be adressed some day (there were already patches for earlier Portage versions, see attachment list!) or whether the Portage team&apos;s efforts continue going into groundbreaking features like configurable colouring (see current GWN).</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>zmedico@gentoo.org</who>
            <bug_when>2006-09-19 11:54:56 0000</bug_when>
            <thetext>For those wondering when this bug will be fixed, please note that bug 93469 is a dependency that is blocking progress on this bug.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>news@derived-software.ltd.uk</who>
            <bug_when>2006-09-19 12:18:20 0000</bug_when>
            <thetext>Hmm, wrt Comment #68: I can see that the two are related, but I can&apos;t see that SLOT dependencies *have* to be done first.

If I have SLOT a and SLOT b of a package installed (b &gt; a), then this bug is (as far as my understanding, and also fitting in with the new exciting summary line) all about the fact that updates to SLOT a do not get picked up properly.  That has got nothing to do with SLOT dependencies (although having SLOT dependencies may make this problem go away).</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>zmedico@gentoo.org</who>
            <bug_when>2006-09-19 12:52:30 0000</bug_when>
            <thetext>(In reply to comment #69)
&gt; Hmm, wrt Comment #68: I can see that the two are related, but I can&apos;t see that
&gt; SLOT dependencies *have* to be done first.

The problem is that packages are pulled into the dependency graph as dependency atoms.  Without slot support in the dependency atoms, it&apos;s impossible to restrict an upgrade to a specific slot.  This results in the highest slot being pulled in when the highest version within a lower slot would have been the desired behavior.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>zmedico@gentoo.org</who>
            <bug_when>2006-10-04 23:51:16 0000</bug_when>
            <thetext>This is fixed in svn r4595.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>zmedico@gentoo.org</who>
            <bug_when>2006-10-05 16:18:32 0000</bug_when>
            <thetext>This has been released in 2.1.2_pre2-r4.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>phil@thenexusproject.org</who>
            <bug_when>2006-10-05 16:22:46 0000</bug_when>
            <thetext>And it only took a little over four years!  Yeah!  Thanks, guys.  You rock.  (I&apos;m not being sarcastic with that; this has been a personal pet peeve of mine since I was a dev, hence the bug.)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>caster@gentoo.org</who>
            <bug_when>2006-10-06 11:36:59 0000</bug_when>
            <thetext>Sorry to spoil the fun, but doesn&apos;t seem 100% fixed to me.
World looks fine:
# emerge -up world
Calculating world dependencies... done!
[ebuild     U ] dev-java/sun-jdk-1.6.0.0_beta101 [1.6.0.0_beta100]

But package directly...

# emerge -p sun-jdk
Calculating dependencies... done!
[ebuild   Rf  ] dev-java/sun-jdk-1.7.0.0_alpha01

# emerge -up sun-jdk
Calculating dependencies... done!
(nothing to merge)

Tested with 2.1.2_pre2-r4 and -r5.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>zmedico@gentoo.org</who>
            <bug_when>2006-10-06 11:50:03 0000</bug_when>
            <thetext>(In reply to comment #74)
&gt; # emerge -up sun-jdk
&gt; Calculating dependencies... done!
&gt; (nothing to merge)

I think that behavior is fine.  Otherwise we&apos;d be treating sun-jdk as a &quot;greedy&quot; atom (matching all slots instead of the highest version).  If you&apos;re not using the world or system set, then you should run a command like `emerge -up sun-jdk:1.6`.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>zmedico@gentoo.org</who>
            <bug_when>2006-10-06 12:35:43 0000</bug_when>
            <thetext>We could add a --greedy option to enable greedy matches on atoms, but that would be a separate bug.  The world and system sets are greedy by nature.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>caster@gentoo.org</who>
            <bug_when>2006-10-06 12:47:32 0000</bug_when>
            <thetext>Well, I don&apos;t see why not make it greedy by default? Original comment 0 talks about &apos;emerge --update foo-pkg&apos; and you in comment 60 say it&apos;s easy :)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>zmedico@gentoo.org</who>
            <bug_when>2006-10-06 13:04:30 0000</bug_when>
            <thetext>(In reply to comment #77)
&gt; Well, I don&apos;t see why not make it greedy by default? Original comment 0 talks
&gt; about &apos;emerge --update foo-pkg&apos; and you in comment 60 say it&apos;s easy :)

So, --update should imply --greedy?  It&apos;s never been greedy like that before, so it will probably catch lots of people by surprise.  We&apos;ll have to provide a way for them to disable the greedy behavior, as well.  We could make it an option similar to --with-bdeps, having y and n choices.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>caster@gentoo.org</who>
            <bug_when>2006-10-06 14:46:46 0000</bug_when>
            <thetext>(In reply to comment #78)
&gt; So, --update should imply --greedy?  It&apos;s never been greedy like that before,
&gt; so it will probably catch lots of people by surprise.

So? World update also wasn&apos;t greedy before, and now it is. So why not make package update consistent. I honestly don&apos;t believe anybody would mind or be badly surprised that package updates properly when he asks it to update.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>zmedico@gentoo.org</who>
            <bug_when>2006-10-06 15:01:37 0000</bug_when>
            <thetext>The meaning of this bug has become too overloaded over the years.  I&apos;m closing this as fixed via the greedy behavior of system and world sets.  Any additional greedy behavior should be treated as a separate feature request (a different bug).</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>m.debruijne@matrict.nl</who>
            <bug_when>2006-10-07 02:34:47 0000</bug_when>
            <thetext>(In reply to comment #80)
&gt; Any additional greedy behavior should be treated as a separate feature request (a different bug).

Your wish is my command ;-) bug #150361

</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2007-01-01 11:08:32 0000</bug_when>
            <thetext>*** Bug 159626 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jakub@gentoo.org</who>
            <bug_when>2007-01-31 08:43:12 0000</bug_when>
            <thetext>*** Bug 164634 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>15446</attachid>
            <date>2003-08-03 15:30 0000</date>
            <desc>the patch for emerge/portage.py</desc>
            <filename>bugs.4698.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIGVtZXJnZS5vcmcJMjAwMy0wOC0wMyAwMzoyNToxMy4wMDAwMDAwMDAgKzAxMDAKKysrIGVt
ZXJnZQkyMDAzLTA4LTAzIDIzOjIyOjQyLjAwMDAwMDAwMCArMDEwMApAQCAtNzUzLDYgKzc1Myw3
IEBACiAJCXZhcmRiYXBpPXBvcnRhZ2UuZGJbbXlyb290XVsidmFydHJlZSJdLmRiYXBpCiAKIAkJ
bXlzbG90PXBvcnRhZ2UucG9ydGRiLmF1eF9nZXQocGtndmVyLFsiU0xPVCJdKVswXQorCQlwa2c9
cG9ydGFnZS5kZXBfZ2V0a2V5KHBrZykKIAkJYWxsZWI9cG9ydGFnZS5wb3J0ZGIueG1hdGNoKCJt
YXRjaC1hbGwiLHBrZykKIAkJd2hpbGUgYWxsZWI6CiAJCQljYW5kPXBvcnRhZ2UucG9ydGRiLnht
YXRjaCgiYmVzdG1hdGNoLWxpc3QiLHBrZyxteWxpc3Q9YWxsZWIpCkBAIC03ODAsNyArNzgxLDE0
IEBACiAJCQlteW1lcmdlPW15Y2hlY2tbMV0KIAkJZWxzZToKIAkJCSN3ZSdyZSBwcm9jZXNzaW5n
IGEgY29tbWFuZC1saW5lIGFyZ3VtZW50OyB1bmNvbmRpdGlvbmFsbHkgbWVyZ2UgaXQgZXZlbiBp
ZiBpdCdzIGFscmVhZHkgbWVyZ2VkCi0JCQlteW1lcmdlPVtkZXBzdHJpbmddCisJCQlteW1lcmdl
PXBvcnRhZ2UucG9ydGRiLnhtYXRjaCgic2xvdG1hdGNoLXZpc2libGUiLGRlcHN0cmluZykKKwkJ
CWlmICItLXVwZGF0ZSIgaW4gbXlvcHRzOgorCQkJCW5ld21lcmdlPVtdCisJCQkJZm9yIHggaW4g
bXltZXJnZToKKwkJCQkJbXlzbG90PXBvcnRhZ2UuZGJbIi8iXVsicG9ydHRyZWUiXS5kYmFwaS5h
dXhfZ2V0KHhbMTpdLFsiU0xPVCJdKVswXQorCQkJCQlpZiBwb3J0YWdlLmRiWyIvIl1bInZhcnRy
ZWUiXS5oYXNzbG90KHhbMTpdLCBteXNsb3QpOgorCQkJCQkJbmV3bWVyZ2UuYXBwZW5kKHgpCisJ
CQkJbXltZXJnZT1uZXdtZXJnZQogCQlpZiAiLS1kZWJ1ZyIgaW4gbXlvcHRzOgogCQkJcHJpbnQg
IkNhbmRpZGF0ZXM6IixteW1lcmdlCiAJCWZvciB4IGluIG15bWVyZ2U6CkBAIC05MjksNiArOTM3
LDE0IEBACiAJCQlmb3IgeCBpbiBzeXNkaWN0LmtleXMoKToKIAkJCQlteWxpc3QuYXBwZW5kKHN5
c2RpY3RbeF0pCiAKKwkJbmV3bGlzdD1bXQorCQlmb3IgeCBpbiBteWxpc3Q6CisJCQlmb3IgeSBp
biBwb3J0YWdlLnBvcnRkYi54bWF0Y2goInNsb3RtYXRjaC12aXNpYmxlIix4KToKKwkJCQlteXNs
b3Q9cG9ydGFnZS5kYlsiLyJdWyJwb3J0dHJlZSJdLmRiYXBpLmF1eF9nZXQoeVsxOl0sWyJTTE9U
Il0pWzBdCisJCQkJaWYgcG9ydGFnZS5kYlsiLyJdWyJ2YXJ0cmVlIl0uaGFzc2xvdCh5WzE6XSwg
bXlzbG90KToKKwkJCQkJbmV3bGlzdC5hcHBlbmQoeSkKKwkJbXlsaXN0PW5ld2xpc3QKKwogCQlm
b3IgbXlkZXAgaW4gbXlsaXN0OgkKIAkJCW15ZWI9cG9ydGFnZS5wb3J0ZGIueG1hdGNoKCJiZXN0
bWF0Y2gtdmlzaWJsZSIsbXlkZXApCiAJCQlpZiBub3QgbXllYjoKQEAgLTEwMjYsMTMgKzEwNDIs
MTYgQEAKIAkJCQlpZiAobm90ICItLWVtcHR5dHJlZSIgaW4gbXlvcHRzKSBhbmQgcG9ydGFnZS5k
Ylt4WzFdXVsidmFydHJlZSJdLmV4aXN0c19zcGVjaWZpYyh4WzJdKToKIAkJCQkJYWRkbD0iICAi
K3llbGxvdygiUiIpK2ZldGNoKyIgICIKIAkJCQllbGlmIChub3QgIi0tZW1wdHl0cmVlIiBpbiBt
eW9wdHMpIGFuZCBwb3J0YWdlLmRiW3hbMV1dWyJ2YXJ0cmVlIl0uZXhpc3RzX3NwZWNpZmljX2Nh
dCh4WzJdKToKLQkJCQkJbXlvbGRiZXN0PXBvcnRhZ2UuYmVzdChwb3J0YWdlLmRiW3hbMV1dWyJ2
YXJ0cmVlIl0uZGJhcGkubWF0Y2gocG9ydGFnZS5wa2dzcGxpdCh4WzJdKVswXSkpCi0KLQkJCQkJ
dHJ5OgotCQkJCQkJbXlvbGRzbG90PXBvcnRhZ2UuZGJbcG9ydGFnZS5yb290XVsidmFydHJlZSJd
LmdldHNsb3QobXlvbGRiZXN0KQotCQkJCQlleGNlcHQ6Ci0JCQkJCQlteW9sZHNsb3Q9Tm9uZQog
CQkJCQlteW5ld3Nsb3Q9cG9ydGFnZS5wb3J0ZGIuYXV4X2dldCh4WzJdLFsiU0xPVCJdKVswXQor
CQkJCQlteXBrZz1wb3J0YWdlLmNhdHBrZ3NwbGl0KHhbMl0pCisJCQkJCW15b2xkYmVzdD1wb3J0
YWdlLnNsb3RtYXRjaChwb3J0YWdlLmRiW3hbMV1dWyJ2YXJ0cmVlIl0uZGJhcGkubWF0Y2gocG9y
dGFnZS5wa2dzcGxpdCh4WzJdKVswXSksbXluZXdzbG90KQorCQkJCQlpZiBteW9sZGJlc3Q6CisJ
CQkJCQl0cnk6CisJCQkJCQkJbXlvbGRzbG90PXBvcnRhZ2UuZGJbcG9ydGFnZS5yb290XVsidmFy
dHJlZSJdLmdldHNsb3QobXlvbGRiZXN0KQorCQkJCQkJZXhjZXB0OgorCQkJCQkJCW15b2xkc2xv
dD1Ob25lCisJCQkJCWVsc2U6CisJCQkJCQkJbXlvbGRzbG90PU5vbmUKIAogCQkJCQlhZGRsPSIg
ICAiK2ZldGNoCiAJCQkJCWlmIChteW9sZHNsb3Q9PW15bmV3c2xvdCkgYW5kIHBvcnRhZ2UucGtn
Y21wKHBvcnRhZ2UucGtnc3BsaXQoeFsyXSksIHBvcnRhZ2UucGtnc3BsaXQobXlvbGRiZXN0KSkg
PCAwOgotLS0gcG9ydGFnZS5weS5vcmcJMjAwMy0wOC0wMiAyMjo0Mzo0Ny4wMDAwMDAwMDAgKzAx
MDAKKysrIHBvcnRhZ2UucHkJMjAwMy0wOC0wMyAyMzoyNDoxMC4wMDAwMDAwMDAgKzAxMDAKQEAg
LTI2NzksNiArMjY3OSw0MSBAQAogCQkJcDI9Y2F0cGtnc3BsaXQoYmVzdG1hdGNoKVsxOl0KIAly
ZXR1cm4gYmVzdG1hdGNoCQkKIAorZGVmIHNsb3RtYXRjaChteW1hdGNoZXMsc2xvdD1Ob25lKToK
KwkiYWNjZXB0cyBOb25lIGFyZ3VtZW50czsgYXNzdW1lcyBtYXRjaGVzIGFyZSB2YWxpZC4iCisK
KwlpZiBteW1hdGNoZXM9PU5vbmU6CisJCXJldHVybiAiIiAKKwlpZiBub3QgbGVuKG15bWF0Y2hl
cyk6CisJCXJldHVybiAiIgorCisJdG1wbWF0Y2g9e30KKwlmb3IgeCBpbiBteW1hdGNoZXM6CisJ
CWlmIHNsb3Q6CisJCQlteXNsb3Q9ZGJbIi8iXVsidmFydHJlZSJdLmdldHNsb3QoeCkKKwkJZWxz
ZToKKwkJCW15c2xvdD1kYlsiLyJdWyJwb3J0dHJlZSJdLmRiYXBpLmF1eF9nZXQoeCxbIlNMT1Qi
XSlbMF0KKwkJaWYgbm90IHRtcG1hdGNoLmhhc19rZXkobXlzbG90KToKKwkJCXRtcG1hdGNoW215
c2xvdF09eAorCQllbHNlOgorCQkJcDE9Y2F0cGtnc3BsaXQoeClbMTpdCisJCQlwMj1jYXRwa2dz
cGxpdCh0bXBtYXRjaFtteXNsb3RdKVsxOl0KKwkJCWlmIHBrZ2NtcChwMSxwMik+MDoKKwkJCQl0
bXBtYXRjaFtteXNsb3RdPXgKKworCWlmIHNsb3Q6CisJCWlmIHRtcG1hdGNoLmhhc19rZXkoc2xv
dCk6CisJCQlyZXR1cm4gdG1wbWF0Y2hbc2xvdF0KKwkJZWxzZToKKwkJCXJldHVybiAiIgorCisJ
c2xvdG1hdGNoPVtdCisJZm9yIHggaW4gdG1wbWF0Y2g6CisJCXNsb3RtYXRjaC5hcHBlbmQoIj0i
K3RtcG1hdGNoW3hdKQorCisJc2xvdG1hdGNoLnNvcnQoKQorCXJldHVybiBzbG90bWF0Y2gJCQor
CiBjbGFzcyBwb3J0YWdldHJlZToKIAlkZWYgX19pbml0X18oc2VsZixyb290PSIvIix2aXJ0dWFs
PU5vbmUsY2xvbmU9Tm9uZSk6CiAJCWdsb2JhbCBwb3J0ZGIKQEAgLTMyNDgsNiArMzI4MywyMCBA
QAogCQlleGNlcHQ6CiAJCQlwYXNzCiAJCXJldHVybiAiIgorCisJZGVmIGhhc3Nsb3Qoc2VsZixt
eWNhdHBrZyxteXNsb3QpOgorCQkiSGFzIGEgc2xvdCBmb3IgYSBjYXRwa2c7IGFzc3VtZSBpdCBl
eGlzdHMuIgorCQlteXNwbGl0PWNhdHBrZ3NwbGl0KG15Y2F0cGtnKQorCQlteWRpcmxpc3Q9bGlz
dGRpcihzZWxmLnJvb3QrInZhci9kYi9wa2cvIitteXNwbGl0WzBdKQorCQlmb3IgeCBpbiBteWRp
cmxpc3Q6CisJCQlpZiB4WzpsZW4obXlzcGxpdFsxXSkrMV09PW15c3BsaXRbMV0rIi0iOgorCQkJ
CXNsb3RmaWxlPW9wZW4oc2VsZi5yb290KyJ2YXIvZGIvcGtnLyIrbXlzcGxpdFswXSsiLyIreCsi
L1NMT1QiLCJyIikKKwkJCQlzbG90dmFyPXN0cmluZy5zcGxpdChzbG90ZmlsZS5yZWFkbGluZSgp
KVswXQorCQkJCXNsb3RmaWxlLmNsb3NlKCkKKwkJCQlpZiAoc2xvdHZhcj09bXlzbG90KToKKwkJ
CQkJcmV0dXJuIDEKKworCQlyZXR1cm4gMAogCQogCWRlZiBoYXNub2RlKHNlbGYsbXlrZXkpOgog
CQkiIiJEb2VzIHRoZSBwYXJ0aWN1bGFyIG5vZGUgKGNhdC9wa2cga2V5KSBleGlzdD8iIiIKQEAg
LTM3MTMsMTAgKzM3NjIsMTMgQEAKIAkJZWxpZiBsZXZlbD09Im1hdGNoLWFsbCI6CiAJCQkjbWF0
Y2ggKmFsbCogdmlzaWJsZSAqYW5kKiBtYXNrZWQgcGFja2FnZXMKIAkJCW15dmFsPXNlbGYubWF0
Y2gyKG15ZGVwLG15a2V5LHNlbGYuY3BfbGlzdChteWtleSkpCisJCWVsaWYgbGV2ZWw9PSJzbG90
bWF0Y2gtdmlzaWJsZSI6CisJCQkjbWF0Y2ggKmFsbCogdmlzaWJsZSBlYWNoIFNMT1QKKwkJCW15
dmFsPXNsb3RtYXRjaChzZWxmLnhtYXRjaCgibWF0Y2gtdmlzaWJsZSIsTm9uZSxteWRlcCxteWtl
eSkpCiAJCWVsc2U6CiAJCQlwcmludCAiRVJST1I6IHhtYXRjaCBkb2Vzbid0IGhhbmRsZSIsbGV2
ZWwsInF1ZXJ5ISIKIAkJCXJhaXNlIEtleUVycm9yCi0JCWlmIHNlbGYuZnJvemVuIGFuZCAobGV2
ZWwgbm90IGluIFsibWF0Y2gtbGlzdCIsImJlc3RtYXRjaC1saXN0Il0pOgorCQlpZiBzZWxmLmZy
b3plbiBhbmQgKGxldmVsIG5vdCBpbiBbIm1hdGNoLWxpc3QiLCJiZXN0bWF0Y2gtbGlzdCIsInNs
b3RtYXRjaC12aXNpYmxlIl0pOgogCQkJc2VsZi54Y2FjaGVbbGV2ZWxdW215ZGVwXT1teXZhbAog
CQlyZXR1cm4gbXl2YWwKIAo=
</data>        

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>15727</attachid>
            <date>2003-08-07 22:15 0000</date>
            <desc>patch for portage.py/emerge</desc>
            <filename>bugs.4698.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIGVtZXJnZS5vcmcJMjAwMy0wOC0wMyAwMzoyNToxMy4wMDAwMDAwMDAgKzAxMDAKKysrIGVt
ZXJnZQkyMDAzLTA4LTA4IDA2OjAyOjE0LjAwMDAwMDAwMCArMDEwMApAQCAtNjA5LDYgKzYwOSw5
IEBACiAJCQkJCSMgc2luY2Ugb3VyIGJsb2NrcyBkb2Vzbid0IG1hdGNoIGFueSBpbnN0YWxsZWQg
cGFja2FnZXMsCiAJCQkJCSMgaXQgZG9lc24ndCBhcHBseSB0byB1cyBhbmQgd2UgY2FuIGlnbm9y
ZSBpdC4KIAkJCQlyZXR1cm4gMQorCQkJaWYgbXl0eXBlPT0ibXVsdGkiOgorCQkJCXNlbGYuZGln
cmFwaC5hZGRub2RlKHN0cmluZy5qb2luKG15Ymlna2V5KSxteXBhcmVudCkKKwkJCQlyZXR1cm4g
MQogCQkJaWYgbm90IG15cGFyZW50OgogCQkJCSMgY29tbWFuZC1saW5lIHNwZWNpZmllZCBvciBw
YXJ0IG9mIGEgd29ybGQgbGlzdC4uLgogCQkJCWlmICgic2VsZiIgbm90IGluIG15cGFyYW1zKSBv
ciAoKCJzZWxlY3RpdmUiIGluIG15cGFyYW1zKSBhbmQgdmFyZGJhcGkuY3B2X2V4aXN0cyhteWtl
eSkpOgpAQCAtNzUzLDYgKzc1Niw3IEBACiAJCXZhcmRiYXBpPXBvcnRhZ2UuZGJbbXlyb290XVsi
dmFydHJlZSJdLmRiYXBpCiAKIAkJbXlzbG90PXBvcnRhZ2UucG9ydGRiLmF1eF9nZXQocGtndmVy
LFsiU0xPVCJdKVswXQorCQlwa2c9cG9ydGFnZS5kZXBfZ2V0a2V5KHBrZykKIAkJYWxsZWI9cG9y
dGFnZS5wb3J0ZGIueG1hdGNoKCJtYXRjaC1hbGwiLHBrZykKIAkJd2hpbGUgYWxsZWI6CiAJCQlj
YW5kPXBvcnRhZ2UucG9ydGRiLnhtYXRjaCgiYmVzdG1hdGNoLWxpc3QiLHBrZyxteWxpc3Q9YWxs
ZWIpCkBAIC03NzIsNiArNzc2LDcgQEAKIAkJCXByaW50CiAJCQlwcmludCAiUGFyZW50OiAgICIs
bXlwYXJlbnQKIAkJCXByaW50ICJEZXBzdHJpbmc6IixkZXBzdHJpbmcKKwkJbXVsdGlmbGc9RmFs
c2UKIAkJaWYgbm90IGFyZzoKIAkJCSNwcm9jZXNzaW5nIGRlcGVuZGVuY2llcwogCQkJbXljaGVj
az1wb3J0YWdlLmRlcF9jaGVjayhkZXBzdHJpbmcsc2VsZi5teWRiYXBpW215cm9vdF0pCkBAIC03
ODAsMTMgKzc4NSwzMiBAQAogCQkJbXltZXJnZT1teWNoZWNrWzFdCiAJCWVsc2U6CiAJCQkjd2Un
cmUgcHJvY2Vzc2luZyBhIGNvbW1hbmQtbGluZSBhcmd1bWVudDsgdW5jb25kaXRpb25hbGx5IG1l
cmdlIGl0IGV2ZW4gaWYgaXQncyBhbHJlYWR5IG1lcmdlZAotCQkJbXltZXJnZT1bZGVwc3RyaW5n
XQorCQkJbXltZXJnZT1wb3J0YWdlLnBvcnRkYi54bWF0Y2goInNsb3RtYXRjaC12aXNpYmxlIixk
ZXBzdHJpbmcpCisJCQlpZiAiLS11cGRhdGUiIGluIG15b3B0czoKKwkJCQluZXdtZXJnZT1bXQor
CQkJCWZvciB4IGluIG15bWVyZ2U6CisJCQkJCW15c2xvdD1wb3J0YWdlLmRiWyIvIl1bInBvcnR0
cmVlIl0uZGJhcGkuYXV4X2dldCh4WzE6XSxbIlNMT1QiXSlbMF0KKwkJCQkJaWYgcG9ydGFnZS5k
YlsiLyJdWyJ2YXJ0cmVlIl0uaGFzc2xvdCh4WzE6XSwgbXlzbG90KToKKwkJCQkJCW5ld21lcmdl
LmFwcGVuZCh4KQorCQkJCW15bWVyZ2U9bmV3bWVyZ2UKKworCQkJaWYgIi0tdXBkYXRlIiBub3Qg
aW4gbXlvcHRzOgorCQkJCWlmIGxlbihteW1lcmdlKT4xIGFuZCBub3QgbXlwYXJlbnQ6CisJCQkJ
CW11bHRpZmxnPVRydWUKKwogCQlpZiAiLS1kZWJ1ZyIgaW4gbXlvcHRzOgogCQkJcHJpbnQgIkNh
bmRpZGF0ZXM6IixteW1lcmdlCisKKwkJaWYgbm90IG15bWVyZ2UgYW5kIG5vdCBteXBhcmVudDoK
KwkJCXByaW50ICJcbmVtZXJnZTogdGhlcmUgYXJlIG5vIG1hc2tlZCBvciB1bm1hc2tlZCBlYnVp
bGRzIHRvIHNhdGlzZnkgIithcmcrIi4iCisJCQlyZXR1cm4gMAorCiAJCWZvciB4IGluIG15bWVy
Z2U6CiAJCQlpZiB4WzBdPT0iISI6CiAJCQkJI2FkZCBvdXIgYmxvY2tlcjsgaXQgd2lsbCBiZSBp
Z25vcmVkIGxhdGVyIGlmIG5lY2Vzc2FyeSAoaWYgd2UgYXJlIHJlbWVyZ2luZyB0aGUgc2FtZSBw
a2csIGZvciBleGFtcGxlKQogCQkJCW15az1bImJsb2NrcyIsbXlyb290LHhbMTpdXQorCQkJZWxp
ZiBtdWx0aWZsZzoKKwkJCQlteWs9WyJtdWx0aSIsbXlyb290LHhbMTpdXQogCQkJZWxzZToKIAkJ
CQkjV2UgYXJlIG5vdCBwcm9jZXNzaW5nIGEgYmxvY2tlciBidXQgYSBub3JtYWwgZGVwZW5kZW5j
eQogCQkJCW15ZWJfcGtnPU5vbmUKQEAgLTkyOSw2ICs5NTMsMTMgQEAKIAkJCWZvciB4IGluIHN5
c2RpY3Qua2V5cygpOgogCQkJCW15bGlzdC5hcHBlbmQoc3lzZGljdFt4XSkKIAorCQluZXdsaXN0
PVtdCisJCWZvciB4IGluIG15bGlzdDoKKwkJCWZvciB5IGluIHBvcnRhZ2UucG9ydGRiLnhtYXRj
aCgic2xvdG1hdGNoLXZpc2libGUiLHgpOgorCQkJCW15c2xvdD1wb3J0YWdlLmRiWyIvIl1bInBv
cnR0cmVlIl0uZGJhcGkuYXV4X2dldCh5WzE6XSxbIlNMT1QiXSlbMF0KKwkJCQlpZiBwb3J0YWdl
LmRiWyIvIl1bInZhcnRyZWUiXS5oYXNzbG90KHlbMTpdLCBteXNsb3QpOgorCQkJCQluZXdsaXN0
LmFwcGVuZCh5KQorCQlteWxpc3Q9bmV3bGlzdAogCQlmb3IgbXlkZXAgaW4gbXlsaXN0OgkKIAkJ
CW15ZWI9cG9ydGFnZS5wb3J0ZGIueG1hdGNoKCJiZXN0bWF0Y2gtdmlzaWJsZSIsbXlkZXApCiAJ
CQlpZiBub3QgbXllYjoKQEAgLTk5NSw2ICsxMDI2LDcgQEAKIAkKIAlkZWYgZGlzcGxheShzZWxm
LG15bGlzdCk6CiAJCWNoYW5nZWxvZ3M9W10KKwkJZXJyb3I9Tm9uZQogCQlmb3IgeCBpbiBteWxp
c3Q6CiAJCQkjcHJpbnQgeAogCQkJZmV0Y2g9IiAiCkBAIC0xMDEzLDYgKzEwNDUsMTIgQEAKIAkJ
CQkJCXByaW50IHJlZCgiKGZyb20gcGtnICIreFszXSsiKSIpCiAJCQkJCWVsc2U6CiAJCQkJCQlw
cmludAorCQkJZWxpZiB4WzBdPT0ibXVsdGkiOgorCQkJCWVycm9yPSJtdWx0aSIKKwkJCQlhZGRs
PSIiK3JlZCgiQiIpKyIgICIrZmV0Y2grIiAgIgorCQkJCXJlc29sdmVkPXBvcnRhZ2UuZGJbeFsx
XV1bInZhcnRyZWUiXS5yZXNvbHZlX2tleSh4WzJdKQorCQkJCW15c2xvdD1wb3J0YWdlLnBvcnRk
Yi5hdXhfZ2V0KHhbMl0sWyJTTE9UIl0pWzBdCisJCQkJcHJpbnQgIlsiK3hbMF0rIiAiK2FkZGwr
Il0iLHJlZChyZXNvbHZlZCksIlsiK215c2xvdCsiXSIKIAkJCWVsc2U6CiAJCQkJaWYgeFszXT09
Im5vbWVyZ2UiOgogCQkJCQljb250aW51ZQpAQCAtMTAyNiwxMyArMTA2NCwxNiBAQAogCQkJCWlm
IChub3QgIi0tZW1wdHl0cmVlIiBpbiBteW9wdHMpIGFuZCBwb3J0YWdlLmRiW3hbMV1dWyJ2YXJ0
cmVlIl0uZXhpc3RzX3NwZWNpZmljKHhbMl0pOgogCQkJCQlhZGRsPSIgICIreWVsbG93KCJSIikr
ZmV0Y2grIiAgIgogCQkJCWVsaWYgKG5vdCAiLS1lbXB0eXRyZWUiIGluIG15b3B0cykgYW5kIHBv
cnRhZ2UuZGJbeFsxXV1bInZhcnRyZWUiXS5leGlzdHNfc3BlY2lmaWNfY2F0KHhbMl0pOgotCQkJ
CQlteW9sZGJlc3Q9cG9ydGFnZS5iZXN0KHBvcnRhZ2UuZGJbeFsxXV1bInZhcnRyZWUiXS5kYmFw
aS5tYXRjaChwb3J0YWdlLnBrZ3NwbGl0KHhbMl0pWzBdKSkKLQotCQkJCQl0cnk6Ci0JCQkJCQlt
eW9sZHNsb3Q9cG9ydGFnZS5kYltwb3J0YWdlLnJvb3RdWyJ2YXJ0cmVlIl0uZ2V0c2xvdChteW9s
ZGJlc3QpCi0JCQkJCWV4Y2VwdDoKLQkJCQkJCW15b2xkc2xvdD1Ob25lCiAJCQkJCW15bmV3c2xv
dD1wb3J0YWdlLnBvcnRkYi5hdXhfZ2V0KHhbMl0sWyJTTE9UIl0pWzBdCisJCQkJCW15cGtnPXBv
cnRhZ2UuY2F0cGtnc3BsaXQoeFsyXSkKKwkJCQkJbXlvbGRiZXN0PXBvcnRhZ2Uuc2xvdG1hdGNo
KHBvcnRhZ2UuZGJbeFsxXV1bInZhcnRyZWUiXS5kYmFwaS5tYXRjaChwb3J0YWdlLnBrZ3NwbGl0
KHhbMl0pWzBdKSxteW5ld3Nsb3QpCisJCQkJCWlmIG15b2xkYmVzdDoKKwkJCQkJCXRyeToKKwkJ
CQkJCQlteW9sZHNsb3Q9cG9ydGFnZS5kYltwb3J0YWdlLnJvb3RdWyJ2YXJ0cmVlIl0uZ2V0c2xv
dChteW9sZGJlc3QpCisJCQkJCQlleGNlcHQ6CisJCQkJCQkJbXlvbGRzbG90PU5vbmUKKwkJCQkJ
ZWxzZToKKwkJCQkJCQlteW9sZHNsb3Q9Tm9uZQogCiAJCQkJCWFkZGw9IiAgICIrZmV0Y2gKIAkJ
CQkJaWYgKG15b2xkc2xvdD09bXluZXdzbG90KSBhbmQgcG9ydGFnZS5wa2djbXAocG9ydGFnZS5w
a2dzcGxpdCh4WzJdKSwgcG9ydGFnZS5wa2dzcGxpdChteW9sZGJlc3QpKSA8IDA6CkBAIC0xMDU4
LDcgKzEwOTksOSBAQAogCQkJCQlteW9sZGJlc3Q9Ymx1ZSgiWyIrbXlvbGRiZXN0KyJdIikKIAog
CQkJCWl1c2U9IiIKKwkJCQlzbG90PScnCiAJCQkJaWYgIi0tdmVyYm9zZSIgaW4gbXlvcHRzOgor
CQkJCQlzbG90PSJbIitwb3J0YWdlLnBvcnRkYi5hdXhfZ2V0KHhbMl0sWyJTTE9UIl0pWzBdKyJd
IgogCQkJCQlmb3IgZWJ1aWxkX2l1c2UgaW4gc3RyaW5nLnNwbGl0KHBvcnRhZ2UucG9ydGRiLmF1
eF9nZXQoeFsyXSxbIklVU0UiXSlbMF0sICIgIik6CiAJCQkJCQl0cnk6CiAJCQkJCQkJaWYgKHBv
cnRhZ2UudXNlc3BsaXQuaW5kZXgoZWJ1aWxkX2l1c2UpID49IDApIDoKQEAgLTEwODksOSArMTEz
Miw5IEBACiAJCQkJCQlpZiAob2xkbHAtbGVuKG15cHJpbnQpKSA+IDA6CiAJCQkJCQkJbXlwcmlu
dD1teXByaW50KyIgIioob2xkbHAtbGVuKG15cHJpbnQpKQogCQkJCQkJbXlwcmludD1teXByaW50
K215b2xkYmVzdAotCQkJCQkJbXlwcmludD1teXByaW50K2RhcmtncmVlbigiICB0byAiK3hbMV0p
KyIgIitpdXNlCisJCQkJCQlteXByaW50PW15cHJpbnQrZGFya2dyZWVuKCIgIHRvICIreFsxXSkr
IiAiK3Nsb3QrIiAiK2l1c2UKIAkJCQkJZWxzZToKLQkJCQkJCW15cHJpbnQ9IlsiK3hbMF0rIiAi
K2FkZGwrIl0gIitkYXJrZ3JlZW4oeFsyXSkrIiAiK215b2xkYmVzdCsiICIrZGFya2dyZWVuKCJ0
byAiK3hbMV0pKyIgIitpdXNlCisJCQkJCQlteXByaW50PSJbIit4WzBdKyIgIithZGRsKyJdICIr
ZGFya2dyZWVuKHhbMl0pKyIgIitteW9sZGJlc3QrIiAiK2RhcmtncmVlbigidG8gIit4WzFdKSsi
ICIrc2xvdCsiICIraXVzZQogCQkJCWVsc2U6CiAJCQkJCWlmICItLWNvbHVtbnMiIGluIG15b3B0
czoKIAkJCQkJCW15cHJpbnQ9IlsiK3hbMF0rIiAiK2FkZGwrIl0gIitkYXJrZ3JlZW4oeHNbMF0p
CkBAIC0xMTAwLDkgKzExNDMsOSBAQAogCQkJCQkJbXlwcmludD1teXByaW50K2dyZWVuKCIgWyIr
eHNbMV0reHNbMl0rIl0gIikKIAkJCQkJCWlmIChvbGRscC1sZW4obXlwcmludCkpID4gMDoKIAkJ
CQkJCQlteXByaW50PW15cHJpbnQrKCIgIioob2xkbHAtbGVuKG15cHJpbnQpKSkKLQkJCQkJCW15
cHJpbnQ9bXlwcmludCtteW9sZGJlc3QrIiAgIitpdXNlCisJCQkJCQlteXByaW50PW15cHJpbnQr
bXlvbGRiZXN0KyIgIitzbG90KyIgIitpdXNlCiAJCQkJCWVsc2U6Ci0JCQkJCQlteXByaW50PSJb
Iit4WzBdKyIgIithZGRsKyJdICIrZGFya2dyZWVuKHhbMl0pKyIgIitteW9sZGJlc3QrIiAiK2l1
c2UKKwkJCQkJCW15cHJpbnQ9IlsiK3hbMF0rIiAiK2FkZGwrIl0gIitkYXJrZ3JlZW4oeFsyXSkr
IiAiK215b2xkYmVzdCsiICIrc2xvdCsiICIraXVzZQogCQkJCXByaW50IG15cHJpbnQKIAogCQkJ
bXlzcGxpdD1wb3J0YWdlLnBrZ3NwbGl0KHhbMl0pCkBAIC0xMTI2LDYgKzExNjksMTQgQEAKIAkJ
CQkJCQlwcmludAogCQkJZGVsIG15c3BsaXQKIAorCQlpZiBlcnJvcjoKKwkJCWlmIGVycm9yPT0i
bXVsdGkiOgorCQkJCXByaW50IAorCQkJCXByaW50ICJZb3UgbmVlZCB0byBzZWxlY3Qgb25lIHZl
cnNpb24iCisJCQkJcHJpbnQgIkV4YW1wbGUsIFwiZW1lcmdlID0iK3hbMl0rIlwiIgorCQkJCXBy
aW50ICJZb3UgY2FuIGluc3RhbGwgYm90aCBvZiB0aGVtLCBpZiB5b3UgZW1lcmdlIHR3aWNlLiIK
KworCQkKICAJCWlmICItLWNoYW5nZWxvZyIgaW4gbXlvcHRzOgogIAkJCXByaW50CiAgCQkJZm9y
IHJldmlzaW9uLHRleHQgaW4gY2hhbmdlbG9nczoKQEAgLTExOTYsNiArMTI0NywxNSBAQAogCQkJ
CQlpZiAoIi0tcHJldGVuZCIgbm90IGluIG15b3B0cyk6CiAJCQkJCQlzeXMuZXhpdCgxKQogCisJ
CQkJaWYgeFswXT09Im11bHRpIjoKKwkJCQkJcHJpbnQgIlxuISEhIEVycm9yOiB0aGUgIit4WzJd
KyIgcGFja2FnZSBjb25mbGljdHMgd2l0aCBhbm90aGVyIHBhY2thZ2UuIgorCQkJCQlwcmludCAg
ICIhISEgICAgICAgIEl0IGlzIG5lY2Vzc2FyeSB0byBzcGVjaWZ5IGEgdmVyc2lvbi4iCisJCQkJ
CXByaW50ICAgIiEhISAgICAgICAgRXhhbXBsZSwgXCJlbWVyZ2UgPSIreFsyXSsiXCIiCisJCQkJ
CXByaW50ICAgIiEhISAgICAgICAgUGxlYXNlIHVzZSAnZW1lcmdlIC0tcHJldGVuZCcgdG8gZGV0
ZXJtaW5lIHBhY2thZ2VzLiIKKwkJCQkJcHJpbnQKKwkJCQkJaWYgKCItLXByZXRlbmQiIG5vdCBp
biBteW9wdHMpOgorCQkJCQkJc3lzLmV4aXQoMSkKKwogCQlpZiAoIi0tcmVzdW1lIiBpbiBteW9w
dHMpOgogCQkJIyBXZSdyZSByZXN1bWluZy4KIAkJCXByaW50IGdyZWVuKCIqKiogUmVzdW1pbmcg
bWVyZ2UuLi4iKQotLS0gcG9ydGFnZS5weS5vcmcJMjAwMy0wOC0wMiAyMjo0Mzo0Ny4wMDAwMDAw
MDAgKzAxMDAKKysrIHBvcnRhZ2UucHkJMjAwMy0wOC0wOCAwMzo1ODoxNS4wMDAwMDAwMDAgKzAx
MDAKQEAgLTI2NzksNiArMjY3OSw0MSBAQAogCQkJcDI9Y2F0cGtnc3BsaXQoYmVzdG1hdGNoKVsx
Ol0KIAlyZXR1cm4gYmVzdG1hdGNoCQkKIAorZGVmIHNsb3RtYXRjaChteW1hdGNoZXMsc2xvdD1O
b25lKToKKwkiYWNjZXB0cyBOb25lIGFyZ3VtZW50czsgYXNzdW1lcyBtYXRjaGVzIGFyZSB2YWxp
ZC4iCisKKwlpZiBteW1hdGNoZXM9PU5vbmU6CisJCXJldHVybiAiIiAKKwlpZiBub3QgbGVuKG15
bWF0Y2hlcyk6CisJCXJldHVybiAiIgorCisJdG1wbWF0Y2g9e30KKwlmb3IgeCBpbiBteW1hdGNo
ZXM6CisJCWlmIHNsb3Q6CisJCQlteXNsb3Q9ZGJbIi8iXVsidmFydHJlZSJdLmdldHNsb3QoeCkK
KwkJZWxzZToKKwkJCW15c2xvdD1kYlsiLyJdWyJwb3J0dHJlZSJdLmRiYXBpLmF1eF9nZXQoeCxb
IlNMT1QiXSlbMF0KKwkJaWYgbm90IHRtcG1hdGNoLmhhc19rZXkobXlzbG90KToKKwkJCXRtcG1h
dGNoW215c2xvdF09eAorCQllbHNlOgorCQkJcDE9Y2F0cGtnc3BsaXQoeClbMTpdCisJCQlwMj1j
YXRwa2dzcGxpdCh0bXBtYXRjaFtteXNsb3RdKVsxOl0KKwkJCWlmIHBrZ2NtcChwMSxwMik+MDoK
KwkJCQl0bXBtYXRjaFtteXNsb3RdPXgKKworCWlmIHNsb3Q6CisJCWlmIHRtcG1hdGNoLmhhc19r
ZXkoc2xvdCk6CisJCQlyZXR1cm4gdG1wbWF0Y2hbc2xvdF0KKwkJZWxzZToKKwkJCXJldHVybiAi
IgorCisJc2xvdG1hdGNoPVtdCisJZm9yIHggaW4gdG1wbWF0Y2g6CisJCXNsb3RtYXRjaC5hcHBl
bmQoIj0iK3RtcG1hdGNoW3hdKQorCisJc2xvdG1hdGNoLnNvcnQoKQorCXJldHVybiBzbG90bWF0
Y2gJCQorCiBjbGFzcyBwb3J0YWdldHJlZToKIAlkZWYgX19pbml0X18oc2VsZixyb290PSIvIix2
aXJ0dWFsPU5vbmUsY2xvbmU9Tm9uZSk6CiAJCWdsb2JhbCBwb3J0ZGIKQEAgLTMyNDgsNiArMzI4
MywyMCBAQAogCQlleGNlcHQ6CiAJCQlwYXNzCiAJCXJldHVybiAiIgorCisJZGVmIGhhc3Nsb3Qo
c2VsZixteWNhdHBrZyxteXNsb3QpOgorCQkiSGFzIGEgc2xvdCBmb3IgYSBjYXRwa2c7IGFzc3Vt
ZSBpdCBleGlzdHMuIgorCQlteXNwbGl0PWNhdHBrZ3NwbGl0KG15Y2F0cGtnKQorCQlteWRpcmxp
c3Q9bGlzdGRpcihzZWxmLnJvb3QrInZhci9kYi9wa2cvIitteXNwbGl0WzBdKQorCQlmb3IgeCBp
biBteWRpcmxpc3Q6CisJCQlpZiB4WzpsZW4obXlzcGxpdFsxXSkrMV09PW15c3BsaXRbMV0rIi0i
OgorCQkJCXNsb3RmaWxlPW9wZW4oc2VsZi5yb290KyJ2YXIvZGIvcGtnLyIrbXlzcGxpdFswXSsi
LyIreCsiL1NMT1QiLCJyIikKKwkJCQlzbG90dmFyPXN0cmluZy5zcGxpdChzbG90ZmlsZS5yZWFk
bGluZSgpKVswXQorCQkJCXNsb3RmaWxlLmNsb3NlKCkKKwkJCQlpZiAoc2xvdHZhcj09bXlzbG90
KToKKwkJCQkJcmV0dXJuIDEKKworCQlyZXR1cm4gMAogCQogCWRlZiBoYXNub2RlKHNlbGYsbXlr
ZXkpOgogCQkiIiJEb2VzIHRoZSBwYXJ0aWN1bGFyIG5vZGUgKGNhdC9wa2cga2V5KSBleGlzdD8i
IiIKQEAgLTM3MTMsMTAgKzM3NjIsMTMgQEAKIAkJZWxpZiBsZXZlbD09Im1hdGNoLWFsbCI6CiAJ
CQkjbWF0Y2ggKmFsbCogdmlzaWJsZSAqYW5kKiBtYXNrZWQgcGFja2FnZXMKIAkJCW15dmFsPXNl
bGYubWF0Y2gyKG15ZGVwLG15a2V5LHNlbGYuY3BfbGlzdChteWtleSkpCisJCWVsaWYgbGV2ZWw9
PSJzbG90bWF0Y2gtdmlzaWJsZSI6CisJCQkjbWF0Y2ggKmFsbCogdmlzaWJsZSBlYWNoIFNMT1QK
KwkJCW15dmFsPXNsb3RtYXRjaChzZWxmLnhtYXRjaCgibWF0Y2gtdmlzaWJsZSIsTm9uZSxteWRl
cCxteWtleSkpCiAJCWVsc2U6CiAJCQlwcmludCAiRVJST1I6IHhtYXRjaCBkb2Vzbid0IGhhbmRs
ZSIsbGV2ZWwsInF1ZXJ5ISIKIAkJCXJhaXNlIEtleUVycm9yCi0JCWlmIHNlbGYuZnJvemVuIGFu
ZCAobGV2ZWwgbm90IGluIFsibWF0Y2gtbGlzdCIsImJlc3RtYXRjaC1saXN0Il0pOgorCQlpZiBz
ZWxmLmZyb3plbiBhbmQgKGxldmVsIG5vdCBpbiBbIm1hdGNoLWxpc3QiLCJiZXN0bWF0Y2gtbGlz
dCIsInNsb3RtYXRjaC12aXNpYmxlIl0pOgogCQkJc2VsZi54Y2FjaGVbbGV2ZWxdW215ZGVwXT1t
eXZhbAogCQlyZXR1cm4gbXl2YWwKIAo=
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>15866</attachid>
            <date>2003-08-10 14:11 0000</date>
            <desc>patch for portage.py/emerge</desc>
            <filename>bugs.4698.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIGVtZXJnZS5vcmcJMjAwMy0wOC0xMCAyMToxMDo0OS4wMDAwMDAwMDAgKzAxMDAKKysrIGVt
ZXJnZQkyMDAzLTA4LTEwIDIxOjU3OjE5LjAwMDAwMDAwMCArMDEwMApAQCAtNjA5LDYgKzYwOSw5
IEBACiAJCQkJCSMgc2luY2Ugb3VyIGJsb2NrcyBkb2Vzbid0IG1hdGNoIGFueSBpbnN0YWxsZWQg
cGFja2FnZXMsCiAJCQkJCSMgaXQgZG9lc24ndCBhcHBseSB0byB1cyBhbmQgd2UgY2FuIGlnbm9y
ZSBpdC4KIAkJCQlyZXR1cm4gMQorCQkJaWYgbXl0eXBlPT0ibXVsdGkiOgorCQkJCXNlbGYuZGln
cmFwaC5hZGRub2RlKHN0cmluZy5qb2luKG15Ymlna2V5KSxteXBhcmVudCkKKwkJCQlyZXR1cm4g
MQogCQkJaWYgbm90IG15cGFyZW50OgogCQkJCSMgY29tbWFuZC1saW5lIHNwZWNpZmllZCBvciBw
YXJ0IG9mIGEgd29ybGQgbGlzdC4uLgogCQkJCWlmICgic2VsZiIgbm90IGluIG15cGFyYW1zKSBv
ciAoKCJzZWxlY3RpdmUiIGluIG15cGFyYW1zKSBhbmQgdmFyZGJhcGkuY3B2X2V4aXN0cyhteWtl
eSkpOgpAQCAtNjg5LDcgKzY5Miw3IEBACiAJCWlmIGVkZXBlbmQuaGFzX2tleSgiUERFUEVORCIp
IGFuZCBlZGVwZW5kWyJQREVQRU5EIl06CiAJCQkjIFBvc3QgRGVwZW5kIC0tIEFkZCB0byB0aGUg
bGlzdCB3aXRob3V0IGEgcGFyZW50LCBhcyBpdCBkZXBlbmRzCiAJCQkjIG9uIGEgcGFja2FnZSBi
ZWluZyBwcmVzZW50IEFORCBtdXN0IGJlIGJ1aWx0IGFmdGVyIHRoYXQgcGFja2FnZS4KLQkJCWlm
IG5vdCBzZWxmLnNlbGVjdF9kZXAobXlyb290LGVkZXBlbmRbIlBERVBFTkQiXSk6CisJCQlpZiBu
b3Qgc2VsZi5zZWxlY3RfZGVwKG15cm9vdCxlZGVwZW5kWyJQREVQRU5EIl0scGRlcGVuZD1UcnVl
KToKIAkJCQlyZXR1cm4gMAogCQkJCiAJCXJldHVybiAxCkBAIC03NTMsNiArNzU2LDcgQEAKIAkJ
dmFyZGJhcGk9cG9ydGFnZS5kYltteXJvb3RdWyJ2YXJ0cmVlIl0uZGJhcGkKIAogCQlteXNsb3Q9
cG9ydGFnZS5wb3J0ZGIuYXV4X2dldChwa2d2ZXIsWyJTTE9UIl0pWzBdCisJCXBrZz1wb3J0YWdl
LmRlcF9nZXRrZXkocGtnKQogCQlhbGxlYj1wb3J0YWdlLnBvcnRkYi54bWF0Y2goIm1hdGNoLWFs
bCIscGtnKQogCQl3aGlsZSBhbGxlYjoKIAkJCWNhbmQ9cG9ydGFnZS5wb3J0ZGIueG1hdGNoKCJi
ZXN0bWF0Y2gtbGlzdCIscGtnLG15bGlzdD1hbGxlYikKQEAgLTc2NiwxMiArNzcwLDEzIEBACiAJ
CQkJYnJlYWsKIAkJCWFsbGViLnJlbW92ZShjYW5kKQogCi0JZGVmIHNlbGVjdF9kZXAoc2VsZixt
eXJvb3QsZGVwc3RyaW5nLG15cGFyZW50PU5vbmUsYXJnPU5vbmUpOgorCWRlZiBzZWxlY3RfZGVw
KHNlbGYsbXlyb290LGRlcHN0cmluZyxteXBhcmVudD1Ob25lLGFyZz1Ob25lLHBkZXBlbmQ9Tm9u
ZSk6CiAJCSJnaXZlbiBhIGRlcGVuZGVuY3kgc3RyaW5nLCBjcmVhdGUgdGhlIGFwcHJvcHJpYXRl
IGRlcGdyYXBoIGFuZCByZXR1cm4gMSBvbiBzdWNjZXNzIGFuZCAwIG9uIGZhaWx1cmUiCiAJCWlm
ICItLWRlYnVnIiBpbiBteW9wdHM6CiAJCQlwcmludAogCQkJcHJpbnQgIlBhcmVudDogICAiLG15
cGFyZW50CiAJCQlwcmludCAiRGVwc3RyaW5nOiIsZGVwc3RyaW5nCisJCW11bHRpZmxnPUZhbHNl
CiAJCWlmIG5vdCBhcmc6CiAJCQkjcHJvY2Vzc2luZyBkZXBlbmRlbmNpZXMKIAkJCW15Y2hlY2s9
cG9ydGFnZS5kZXBfY2hlY2soZGVwc3RyaW5nLHNlbGYubXlkYmFwaVtteXJvb3RdKQpAQCAtNzgw
LDEzICs3ODUsMzUgQEAKIAkJCW15bWVyZ2U9bXljaGVja1sxXQogCQllbHNlOgogCQkJI3dlJ3Jl
IHByb2Nlc3NpbmcgYSBjb21tYW5kLWxpbmUgYXJndW1lbnQ7IHVuY29uZGl0aW9uYWxseSBtZXJn
ZSBpdCBldmVuIGlmIGl0J3MgYWxyZWFkeSBtZXJnZWQKLQkJCW15bWVyZ2U9W2RlcHN0cmluZ10K
KwkJCWlmIGRlcHN0cmluZ1swXSBpbiBbJz4nLCc8JywnPSddOgorCQkJCW15bWVyZ2U9W2RlcHN0
cmluZ10KKwkJCWVsc2U6CisJCQkJbXltZXJnZT1wb3J0YWdlLnBvcnRkYi54bWF0Y2goInNsb3Rt
YXRjaC12aXNpYmxlIixkZXBzdHJpbmcpCisJCQlpZiAiLS11cGRhdGUiIGluIG15b3B0czoKKwkJ
CQluZXdtZXJnZT1bXQorCQkJCWZvciB4IGluIG15bWVyZ2U6CisJCQkJCW15c2xvdD1wb3J0YWdl
LmRiWyIvIl1bInBvcnR0cmVlIl0uZGJhcGkuYXV4X2dldCh4WzE6XSxbIlNMT1QiXSlbMF0KKwkJ
CQkJaWYgcG9ydGFnZS5kYlsiLyJdWyJ2YXJ0cmVlIl0uaGFzc2xvdCh4WzE6XSwgbXlzbG90KToK
KwkJCQkJCW5ld21lcmdlLmFwcGVuZCh4KQorCQkJCW15bWVyZ2U9bmV3bWVyZ2UKKworCQkJaWYg
Ii0tdXBkYXRlIiBub3QgaW4gbXlvcHRzOgorCQkJCWlmIGxlbihteW1lcmdlKT4xIGFuZCBub3Qg
bXlwYXJlbnQ6CisJCQkJCW11bHRpZmxnPVRydWUKKwogCQlpZiAiLS1kZWJ1ZyIgaW4gbXlvcHRz
OgogCQkJcHJpbnQgIkNhbmRpZGF0ZXM6IixteW1lcmdlCisKKwkJaWYgbm90IG15bWVyZ2UgYW5k
IG5vdCBteXBhcmVudCBhbmQgbm90IHBkZXBlbmQ6CisJCQlwcmludCAiXG5lbWVyZ2U6IHRoZXJl
IGFyZSBubyBtYXNrZWQgb3IgdW5tYXNrZWQgZWJ1aWxkcyB0byBzYXRpc2Z5ICIrYXJnKyIuIgor
CQkJcmV0dXJuIDAKKwogCQlmb3IgeCBpbiBteW1lcmdlOgogCQkJaWYgeFswXT09IiEiOgogCQkJ
CSNhZGQgb3VyIGJsb2NrZXI7IGl0IHdpbGwgYmUgaWdub3JlZCBsYXRlciBpZiBuZWNlc3Nhcnkg
KGlmIHdlIGFyZSByZW1lcmdpbmcgdGhlIHNhbWUgcGtnLCBmb3IgZXhhbXBsZSkKIAkJCQlteWs9
WyJibG9ja3MiLG15cm9vdCx4WzE6XV0KKwkJCWVsaWYgbXVsdGlmbGc6CisJCQkJbXlrPVsibXVs
dGkiLG15cm9vdCx4WzE6XV0KIAkJCWVsc2U6CiAJCQkJI1dlIGFyZSBub3QgcHJvY2Vzc2luZyBh
IGJsb2NrZXIgYnV0IGEgbm9ybWFsIGRlcGVuZGVuY3kKIAkJCQlteWViX3BrZz1Ob25lCkBAIC05
MjksNiArOTU2LDEzIEBACiAJCQlmb3IgeCBpbiBzeXNkaWN0LmtleXMoKToKIAkJCQlteWxpc3Qu
YXBwZW5kKHN5c2RpY3RbeF0pCiAKKwkJbmV3bGlzdD1bXQorCQlmb3IgeCBpbiBteWxpc3Q6CisJ
CQlmb3IgeSBpbiBwb3J0YWdlLnBvcnRkYi54bWF0Y2goInNsb3RtYXRjaC12aXNpYmxlIix4KToK
KwkJCQlteXNsb3Q9cG9ydGFnZS5kYlsiLyJdWyJwb3J0dHJlZSJdLmRiYXBpLmF1eF9nZXQoeVsx
Ol0sWyJTTE9UIl0pWzBdCisJCQkJaWYgcG9ydGFnZS5kYlsiLyJdWyJ2YXJ0cmVlIl0uaGFzc2xv
dCh5WzE6XSwgbXlzbG90KToKKwkJCQkJbmV3bGlzdC5hcHBlbmQoeSkKKwkJbXlsaXN0PW5ld2xp
c3QKIAkJZm9yIG15ZGVwIGluIG15bGlzdDoJCiAJCQlteWViPXBvcnRhZ2UucG9ydGRiLnhtYXRj
aCgiYmVzdG1hdGNoLXZpc2libGUiLG15ZGVwKQogCQkJaWYgbm90IG15ZWI6CkBAIC05OTUsNiAr
MTAyOSw3IEBACiAJCiAJZGVmIGRpc3BsYXkoc2VsZixteWxpc3QpOgogCQljaGFuZ2Vsb2dzPVtd
CisJCWVycm9yPU5vbmUKIAkJZm9yIHggaW4gbXlsaXN0OgogCQkJI3ByaW50IHgKIAkJCWZldGNo
PSIgIgpAQCAtMTAxMyw2ICsxMDQ4LDEyIEBACiAJCQkJCQlwcmludCByZWQoIihmcm9tIHBrZyAi
K3hbM10rIikiKQogCQkJCQllbHNlOgogCQkJCQkJcHJpbnQKKwkJCWVsaWYgeFswXT09Im11bHRp
IjoKKwkJCQllcnJvcj0ibXVsdGkiCisJCQkJYWRkbD0iIityZWQoIkIiKSsiICAiK2ZldGNoKyIg
ICIKKwkJCQlyZXNvbHZlZD1wb3J0YWdlLmRiW3hbMV1dWyJ2YXJ0cmVlIl0ucmVzb2x2ZV9rZXko
eFsyXSkKKwkJCQlteXNsb3Q9cG9ydGFnZS5wb3J0ZGIuYXV4X2dldCh4WzJdLFsiU0xPVCJdKVsw
XQorCQkJCXByaW50ICJbIit4WzBdKyIgIithZGRsKyJdIixyZWQocmVzb2x2ZWQpLCJbIitteXNs
b3QrIl0iCiAJCQllbHNlOgogCQkJCWlmIHhbM109PSJub21lcmdlIjoKIAkJCQkJY29udGludWUK
QEAgLTEwMjYsMTMgKzEwNjcsMTYgQEAKIAkJCQlpZiAobm90ICItLWVtcHR5dHJlZSIgaW4gbXlv
cHRzKSBhbmQgcG9ydGFnZS5kYlt4WzFdXVsidmFydHJlZSJdLmV4aXN0c19zcGVjaWZpYyh4WzJd
KToKIAkJCQkJYWRkbD0iICAiK3llbGxvdygiUiIpK2ZldGNoKyIgICIKIAkJCQllbGlmIChub3Qg
Ii0tZW1wdHl0cmVlIiBpbiBteW9wdHMpIGFuZCBwb3J0YWdlLmRiW3hbMV1dWyJ2YXJ0cmVlIl0u
ZXhpc3RzX3NwZWNpZmljX2NhdCh4WzJdKToKLQkJCQkJbXlvbGRiZXN0PXBvcnRhZ2UuYmVzdChw
b3J0YWdlLmRiW3hbMV1dWyJ2YXJ0cmVlIl0uZGJhcGkubWF0Y2gocG9ydGFnZS5wa2dzcGxpdCh4
WzJdKVswXSkpCi0KLQkJCQkJdHJ5OgotCQkJCQkJbXlvbGRzbG90PXBvcnRhZ2UuZGJbcG9ydGFn
ZS5yb290XVsidmFydHJlZSJdLmdldHNsb3QobXlvbGRiZXN0KQotCQkJCQlleGNlcHQ6Ci0JCQkJ
CQlteW9sZHNsb3Q9Tm9uZQogCQkJCQlteW5ld3Nsb3Q9cG9ydGFnZS5wb3J0ZGIuYXV4X2dldCh4
WzJdLFsiU0xPVCJdKVswXQorCQkJCQlteXBrZz1wb3J0YWdlLmNhdHBrZ3NwbGl0KHhbMl0pCisJ
CQkJCW15b2xkYmVzdD1wb3J0YWdlLnNsb3RtYXRjaChwb3J0YWdlLmRiW3hbMV1dWyJ2YXJ0cmVl
Il0uZGJhcGkubWF0Y2gocG9ydGFnZS5wa2dzcGxpdCh4WzJdKVswXSksbXluZXdzbG90KQorCQkJ
CQlpZiBteW9sZGJlc3Q6CisJCQkJCQl0cnk6CisJCQkJCQkJbXlvbGRzbG90PXBvcnRhZ2UuZGJb
cG9ydGFnZS5yb290XVsidmFydHJlZSJdLmdldHNsb3QobXlvbGRiZXN0KQorCQkJCQkJZXhjZXB0
OgorCQkJCQkJCW15b2xkc2xvdD1Ob25lCisJCQkJCWVsc2U6CisJCQkJCQkJbXlvbGRzbG90PU5v
bmUKIAogCQkJCQlhZGRsPSIgICAiK2ZldGNoCiAJCQkJCWlmIChteW9sZHNsb3Q9PW15bmV3c2xv
dCkgYW5kIHBvcnRhZ2UucGtnY21wKHBvcnRhZ2UucGtnc3BsaXQoeFsyXSksIHBvcnRhZ2UucGtn
c3BsaXQobXlvbGRiZXN0KSkgPCAwOgpAQCAtMTA1OCw3ICsxMTAyLDkgQEAKIAkJCQkJbXlvbGRi
ZXN0PWJsdWUoIlsiK215b2xkYmVzdCsiXSIpCiAKIAkJCQlpdXNlPSIiCisJCQkJc2xvdD0nJwog
CQkJCWlmICItLXZlcmJvc2UiIGluIG15b3B0czoKKwkJCQkJc2xvdD0iU1siK3BvcnRhZ2UucG9y
dGRiLmF1eF9nZXQoeFsyXSxbIlNMT1QiXSlbMF0rIl0iCiAJCQkJCWZvciBlYnVpbGRfaXVzZSBp
biBzdHJpbmcuc3BsaXQocG9ydGFnZS5wb3J0ZGIuYXV4X2dldCh4WzJdLFsiSVVTRSJdKVswXSwg
IiAiKToKIAkJCQkJCXRyeToKIAkJCQkJCQlpZiAocG9ydGFnZS51c2VzcGxpdC5pbmRleChlYnVp
bGRfaXVzZSkgPj0gMCkgOgpAQCAtMTA4OSw5ICsxMTM1LDkgQEAKIAkJCQkJCWlmIChvbGRscC1s
ZW4obXlwcmludCkpID4gMDoKIAkJCQkJCQlteXByaW50PW15cHJpbnQrIiAiKihvbGRscC1sZW4o
bXlwcmludCkpCiAJCQkJCQlteXByaW50PW15cHJpbnQrbXlvbGRiZXN0Ci0JCQkJCQlteXByaW50
PW15cHJpbnQrZGFya2dyZWVuKCIgIHRvICIreFsxXSkrIiAiK2l1c2UKKwkJCQkJCW15cHJpbnQ9
bXlwcmludCtkYXJrZ3JlZW4oIiAgdG8gIit4WzFdKSsiICIrc2xvdCsiICIraXVzZQogCQkJCQll
bHNlOgotCQkJCQkJbXlwcmludD0iWyIreFswXSsiICIrYWRkbCsiXSAiK2RhcmtncmVlbih4WzJd
KSsiICIrbXlvbGRiZXN0KyIgIitkYXJrZ3JlZW4oInRvICIreFsxXSkrIiAiK2l1c2UKKwkJCQkJ
CW15cHJpbnQ9IlsiK3hbMF0rIiAiK2FkZGwrIl0gIitkYXJrZ3JlZW4oeFsyXSkrIiAiK215b2xk
YmVzdCsiICIrZGFya2dyZWVuKCJ0byAiK3hbMV0pKyIgIitzbG90KyIgIitpdXNlCiAJCQkJZWxz
ZToKIAkJCQkJaWYgIi0tY29sdW1ucyIgaW4gbXlvcHRzOgogCQkJCQkJbXlwcmludD0iWyIreFsw
XSsiICIrYWRkbCsiXSAiK2RhcmtncmVlbih4c1swXSkKQEAgLTExMDAsOSArMTE0Niw5IEBACiAJ
CQkJCQlteXByaW50PW15cHJpbnQrZ3JlZW4oIiBbIit4c1sxXSt4c1syXSsiXSAiKQogCQkJCQkJ
aWYgKG9sZGxwLWxlbihteXByaW50KSkgPiAwOgogCQkJCQkJCW15cHJpbnQ9bXlwcmludCsoIiAi
KihvbGRscC1sZW4obXlwcmludCkpKQotCQkJCQkJbXlwcmludD1teXByaW50K215b2xkYmVzdCsi
ICAiK2l1c2UKKwkJCQkJCW15cHJpbnQ9bXlwcmludCtteW9sZGJlc3QrIiAiK3Nsb3QrIiAiK2l1
c2UKIAkJCQkJZWxzZToKLQkJCQkJCW15cHJpbnQ9IlsiK3hbMF0rIiAiK2FkZGwrIl0gIitkYXJr
Z3JlZW4oeFsyXSkrIiAiK215b2xkYmVzdCsiICIraXVzZQorCQkJCQkJbXlwcmludD0iWyIreFsw
XSsiICIrYWRkbCsiXSAiK2RhcmtncmVlbih4WzJdKSsiICIrbXlvbGRiZXN0KyIgIitzbG90KyIg
IitpdXNlCiAJCQkJcHJpbnQgbXlwcmludAogCiAJCQlteXNwbGl0PXBvcnRhZ2UucGtnc3BsaXQo
eFsyXSkKQEAgLTExMjYsNiArMTE3MiwxNCBAQAogCQkJCQkJCXByaW50CiAJCQlkZWwgbXlzcGxp
dAogCisJCWlmIGVycm9yOgorCQkJaWYgZXJyb3I9PSJtdWx0aSI6CisJCQkJcHJpbnQgCisJCQkJ
cHJpbnQgIllvdSBuZWVkIHRvIHNlbGVjdCBvbmUgdmVyc2lvbiIKKwkJCQlwcmludCAiRXhhbXBs
ZSwgXCJlbWVyZ2UgPSIreFsyXSsiXCIiCisJCQkJcHJpbnQgIllvdSBjYW4gaW5zdGFsbCBib3Ro
IG9mIHRoZW0sIGlmIHlvdSBlbWVyZ2UgdHdpY2UuIgorCisJCQogIAkJaWYgIi0tY2hhbmdlbG9n
IiBpbiBteW9wdHM6CiAgCQkJcHJpbnQKICAJCQlmb3IgcmV2aXNpb24sdGV4dCBpbiBjaGFuZ2Vs
b2dzOgpAQCAtMTE5Niw2ICsxMjUwLDE1IEBACiAJCQkJCWlmICgiLS1wcmV0ZW5kIiBub3QgaW4g
bXlvcHRzKToKIAkJCQkJCXN5cy5leGl0KDEpCiAKKwkJCQlpZiB4WzBdPT0ibXVsdGkiOgorCQkJ
CQlwcmludCAiXG4hISEgRXJyb3I6IHRoZSAiK3hbMl0rIiBwYWNrYWdlIGNvbmZsaWN0cyB3aXRo
IGFub3RoZXIgcGFja2FnZS4iCisJCQkJCXByaW50ICAgIiEhISAgICAgICAgSXQgaXMgbmVjZXNz
YXJ5IHRvIHNwZWNpZnkgYSB2ZXJzaW9uLiIKKwkJCQkJcHJpbnQgICAiISEhICAgICAgICBFeGFt
cGxlLCBcImVtZXJnZSA9Iit4WzJdKyJcIiIKKwkJCQkJcHJpbnQgICAiISEhICAgICAgICBQbGVh
c2UgdXNlICdlbWVyZ2UgLS1wcmV0ZW5kJyB0byBkZXRlcm1pbmUgcGFja2FnZXMuIgorCQkJCQlw
cmludAorCQkJCQlpZiAoIi0tcHJldGVuZCIgbm90IGluIG15b3B0cyk6CisJCQkJCQlzeXMuZXhp
dCgxKQorCiAJCWlmICgiLS1yZXN1bWUiIGluIG15b3B0cyk6CiAJCQkjIFdlJ3JlIHJlc3VtaW5n
LgogCQkJcHJpbnQgZ3JlZW4oIioqKiBSZXN1bWluZyBtZXJnZS4uLiIpCi0tLSBwb3J0YWdlLnB5
Lm9yZwkyMDAzLTA4LTAyIDIyOjQzOjQ3LjAwMDAwMDAwMCArMDEwMAorKysgcG9ydGFnZS5weQky
MDAzLTA4LTEwIDIxOjI4OjIwLjAwMDAwMDAwMCArMDEwMApAQCAtMjY3OSw2ICsyNjc5LDQxIEBA
CiAJCQlwMj1jYXRwa2dzcGxpdChiZXN0bWF0Y2gpWzE6XQogCXJldHVybiBiZXN0bWF0Y2gJCQog
CitkZWYgc2xvdG1hdGNoKG15bWF0Y2hlcyxzbG90PU5vbmUpOgorCSJhY2NlcHRzIE5vbmUgYXJn
dW1lbnRzOyBhc3N1bWVzIG1hdGNoZXMgYXJlIHZhbGlkLiIKKworCWlmIG15bWF0Y2hlcz09Tm9u
ZToKKwkJcmV0dXJuICIiIAorCWlmIG5vdCBsZW4obXltYXRjaGVzKToKKwkJcmV0dXJuICIiCisK
Kwl0bXBtYXRjaD17fQorCWZvciB4IGluIG15bWF0Y2hlczoKKwkJaWYgc2xvdDoKKwkJCW15c2xv
dD1kYlsiLyJdWyJ2YXJ0cmVlIl0uZ2V0c2xvdCh4KQorCQllbHNlOgorCQkJbXlzbG90PWRiWyIv
Il1bInBvcnR0cmVlIl0uZGJhcGkuYXV4X2dldCh4LFsiU0xPVCJdKVswXQorCQlpZiBub3QgdG1w
bWF0Y2guaGFzX2tleShteXNsb3QpOgorCQkJdG1wbWF0Y2hbbXlzbG90XT14CisJCWVsc2U6CisJ
CQlwMT1jYXRwa2dzcGxpdCh4KVsxOl0KKwkJCXAyPWNhdHBrZ3NwbGl0KHRtcG1hdGNoW215c2xv
dF0pWzE6XQorCQkJaWYgcGtnY21wKHAxLHAyKT4wOgorCQkJCXRtcG1hdGNoW215c2xvdF09eAor
CisJaWYgc2xvdDoKKwkJaWYgdG1wbWF0Y2guaGFzX2tleShzbG90KToKKwkJCXJldHVybiB0bXBt
YXRjaFtzbG90XQorCQllbHNlOgorCQkJcmV0dXJuICIiCisKKwlzbG90bWF0Y2g9W10KKwlmb3Ig
eCBpbiB0bXBtYXRjaDoKKwkJc2xvdG1hdGNoLmFwcGVuZCgiPSIrdG1wbWF0Y2hbeF0pCisKKwlz
bG90bWF0Y2guc29ydCgpCisJcmV0dXJuIHNsb3RtYXRjaAkJCisKIGNsYXNzIHBvcnRhZ2V0cmVl
OgogCWRlZiBfX2luaXRfXyhzZWxmLHJvb3Q9Ii8iLHZpcnR1YWw9Tm9uZSxjbG9uZT1Ob25lKToK
IAkJZ2xvYmFsIHBvcnRkYgpAQCAtMzI0OCw2ICszMjgzLDIwIEBACiAJCWV4Y2VwdDoKIAkJCXBh
c3MKIAkJcmV0dXJuICIiCisKKwlkZWYgaGFzc2xvdChzZWxmLG15Y2F0cGtnLG15c2xvdCk6CisJ
CSJIYXMgYSBzbG90IGZvciBhIGNhdHBrZzsgYXNzdW1lIGl0IGV4aXN0cy4iCisJCW15c3BsaXQ9
Y2F0cGtnc3BsaXQobXljYXRwa2cpCisJCW15ZGlybGlzdD1saXN0ZGlyKHNlbGYucm9vdCsidmFy
L2RiL3BrZy8iK215c3BsaXRbMF0pCisJCWZvciB4IGluIG15ZGlybGlzdDoKKwkJCWlmIHhbOmxl
bihteXNwbGl0WzFdKSsxXT09bXlzcGxpdFsxXSsiLSI6CisJCQkJc2xvdGZpbGU9b3BlbihzZWxm
LnJvb3QrInZhci9kYi9wa2cvIitteXNwbGl0WzBdKyIvIit4KyIvU0xPVCIsInIiKQorCQkJCXNs
b3R2YXI9c3RyaW5nLnNwbGl0KHNsb3RmaWxlLnJlYWRsaW5lKCkpWzBdCisJCQkJc2xvdGZpbGUu
Y2xvc2UoKQorCQkJCWlmIChzbG90dmFyPT1teXNsb3QpOgorCQkJCQlyZXR1cm4gMQorCisJCXJl
dHVybiAwCiAJCiAJZGVmIGhhc25vZGUoc2VsZixteWtleSk6CiAJCSIiIkRvZXMgdGhlIHBhcnRp
Y3VsYXIgbm9kZSAoY2F0L3BrZyBrZXkpIGV4aXN0PyIiIgpAQCAtMzcxMywxMCArMzc2MiwxMyBA
QAogCQllbGlmIGxldmVsPT0ibWF0Y2gtYWxsIjoKIAkJCSNtYXRjaCAqYWxsKiB2aXNpYmxlICph
bmQqIG1hc2tlZCBwYWNrYWdlcwogCQkJbXl2YWw9c2VsZi5tYXRjaDIobXlkZXAsbXlrZXksc2Vs
Zi5jcF9saXN0KG15a2V5KSkKKwkJZWxpZiBsZXZlbD09InNsb3RtYXRjaC12aXNpYmxlIjoKKwkJ
CSNtYXRjaCAqYWxsKiB2aXNpYmxlIGVhY2ggU0xPVAorCQkJbXl2YWw9c2xvdG1hdGNoKHNlbGYu
eG1hdGNoKCJtYXRjaC12aXNpYmxlIixOb25lLG15ZGVwLG15a2V5KSkKIAkJZWxzZToKIAkJCXBy
aW50ICJFUlJPUjogeG1hdGNoIGRvZXNuJ3QgaGFuZGxlIixsZXZlbCwicXVlcnkhIgogCQkJcmFp
c2UgS2V5RXJyb3IKLQkJaWYgc2VsZi5mcm96ZW4gYW5kIChsZXZlbCBub3QgaW4gWyJtYXRjaC1s
aXN0IiwiYmVzdG1hdGNoLWxpc3QiXSk6CisJCWlmIHNlbGYuZnJvemVuIGFuZCAobGV2ZWwgbm90
IGluIFsibWF0Y2gtbGlzdCIsImJlc3RtYXRjaC1saXN0Iiwic2xvdG1hdGNoLXZpc2libGUiXSk6
CiAJCQlzZWxmLnhjYWNoZVtsZXZlbF1bbXlkZXBdPW15dmFsCiAJCXJldHVybiBteXZhbAogCg==
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>16126</attachid>
            <date>2003-08-15 00:05 0000</date>
            <desc>output of emerge -upvD world</desc>
            <filename>emerge.output</filename>
            <type>text/plain</type>
            <data encoding="base64">bm9ybWFsIHBvcnRhZ2UgKDIuMC40OV9wcmUxNik6CgpUaGVzZSBhcmUgdGhlIHBhY2thZ2VzIHRo
YXQgSSB3b3VsZCBtZXJnZSwgaW4gb3JkZXI6CgpDYWxjdWxhdGluZyB3b3JsZCBkZXBlbmRlbmNp
ZXMgIC4uLmRvbmUhCltlYnVpbGQgICAgIFUgXSBtZWRpYS1saWJzL25ldHBibS0xMC4xMS4xMCBb
MTAuMTEuNS1yMl0gLXN2Z2EgCltlYnVpbGQgICAgIFUgXSBtZWRpYS1zb3VuZC9lc291bmQtMC4y
LjMxIFswLjIuMjktcjFdICt0Y3BkICthbHNhIApbZWJ1aWxkICAgICBVIF0gZ25vbWUtYmFzZS9i
b25vYm8tYWN0aXZhdGlvbi0yLjIuNCBbMi4yLjNdIC1kb2MgCltlYnVpbGQgICAgIFUgXSBkZXYt
ZGIvbXlzcWwtNC4wLjE0LXIxIFs0LjAuMTRdIC1zdGF0aWMgK3JlYWRsaW5lICtpbm5vZGIgK2Jl
cmtkYiArdGNwZCArc3NsICtwZXJsIC1kZWJ1ZyAKW2VidWlsZCAgICAgVSBdIG1lZGlhLWxpYnMv
Z2RrLXBpeGJ1Zi0wLjIyLjAtcjEgWzAuMjIuMF0gLWRvYyAKW2VidWlsZCAgICAgVSBdIG5ldC1s
aWJzL25zc19sZGFwLTIxMCBbMjA5LjFdICtiZXJrZGIgLWRlYnVnICtzc2wgCltlYnVpbGQgICAg
IFUgXSBzeXMtYXBwcy9hdHRyLTIuNC43IFsyLjQuMV0gLW5scyAtZGVidWcgCltlYnVpbGQgICAg
IFUgXSBzeXMtYXBwcy9hY2wtMi4yLjEzIFsyLjEuMS1yMV0gCltlYnVpbGQgICAgIFUgXSBzeXMt
a2VybmVsL2FjLXNvdXJjZXMtMi40LjIyX3JjMi1yMSBbMi40LjIyX3ByZTEwLXIxXSAtYnVpbGQg
LWRvYyArdGNsdGsgCltlYnVpbGQgICAgIFUgXSBtZWRpYS1saWJzL2xpYnZvcmJpcy0xLjAtcjQg
WzEuMC1yM10gK3NzZSAtM2Rub3cgCltlYnVpbGQgICAgIFUgXSBhcHAtYWRtaW4vbWlycm9yc2Vs
ZWN0LTAuODEgWzAuOF0gCltlYnVpbGQgICAgIFUgXSBhcHAtYWRtaW4vdWZlZC0wLjM0IFswLjMz
XSAKW2VidWlsZCAgICAgVSBdIHN5cy1rZXJuZWwvbW0tc291cmNlcy0yLjYuMF9iZXRhMy1yMiBb
Mi42LjBfYmV0YTMtcjFdIC1kb2MgK3RjbHRrIApbZWJ1aWxkICAgICBVIF0gZ25vbWUtYmFzZS9s
aWJndG9wLTIuMC4zIFsyLjAuMi1yMV0gCltlYnVpbGQgICAgIFUgXSBnbm9tZS1iYXNlL2dkbS0y
LjQuMS42IFsyLjQuMS40XSAKW2VidWlsZCAgTiAgICBdIG1lZGlhLWxpYnMvc3BlZXgtMS4wLjEg
ICtvZ2d2b3JiaXMgK3NzZSAKW2VidWlsZCAgICAgVSBdIG1lZGlhLWxpYnMveGluZS1saWItMV9y
YzAtcjIgWzFfYmV0YTEyLXIxXSArYXJ0cyArZXNkICthdmkgLW5scyArZHZkICthYWxpYiArWCAr
ZGlyZWN0ZmIgK29nZ3ZvcmJpcyArYWxzYSArZ25vbWUgCltlYnVpbGQgICAgIFUgXSBtZWRpYS12
aWRlby94aW5lLXVpLTAuOS4yMiBbMC45LjIxXSArWCArYWFsaWIgK2dub21lIC1ubHMgK2RpcmVj
dGZiIC1saXJjIApbZWJ1aWxkICAgICBVIF0gc3lzLWxpYnMvbGliY2FwLTEuMTAtcjEgWzEuMTBd
ICtweXRob24gCgoKUGF0Y2hlZCBwb3J0YWdlOgoKVGhlc2UgYXJlIHRoZSBwYWNrYWdlcyB0aGF0
IEkgd291bGQgbWVyZ2UsIGluIG9yZGVyOgoKQ2FsY3VsYXRpbmcgd29ybGQgZGVwZW5kZW5jaWVz
ICAuLi5kb25lIQpbZWJ1aWxkICAgICBVIF0gbWVkaWEtbGlicy9uZXRwYm0tMTAuMTEuMTAgWzEw
LjExLjUtcjJdIFNbMF0gLXN2Z2EgCltlYnVpbGQgICAgIFUgXSBtZWRpYS1zb3VuZC9lc291bmQt
MC4yLjMxIFswLjIuMjktcjFdIFNbMF0gK3RjcGQgK2Fsc2EgCltlYnVpbGQgICAgIFUgXSBnbm9t
ZS1iYXNlL2Jvbm9iby1hY3RpdmF0aW9uLTIuMi40IFsyLjIuM10gU1swXSAtZG9jIApbZWJ1aWxk
ICAgICBVIF0gZGV2LWRiL215c3FsLTQuMC4xNC1yMSBbNC4wLjE0XSBTWzBdIC1zdGF0aWMgK3Jl
YWRsaW5lICtpbm5vZGIgK2JlcmtkYiArdGNwZCArc3NsICtwZXJsIC1kZWJ1ZyAKW2VidWlsZCAg
ICAgVSBdIG1lZGlhLWxpYnMvZ2RrLXBpeGJ1Zi0wLjIyLjAtcjEgWzAuMjIuMF0gU1swXSAtZG9j
IApbZWJ1aWxkICAgICBVIF0gbmV0LWxpYnMvbnNzX2xkYXAtMjEwIFsyMDkuMV0gU1swXSArYmVy
a2RiIC1kZWJ1ZyArc3NsIApbZWJ1aWxkICAgICBVIF0gc3lzLWFwcHMvYXR0ci0yLjQuNyBbMi40
LjFdIFNbMF0gLW5scyAtZGVidWcgCltlYnVpbGQgICAgIFUgXSBzeXMtYXBwcy9hY2wtMi4yLjEz
IFsyLjEuMS1yMV0gU1swXSAKW2VidWlsZCAgICAgVS1dIHN5cy1rZXJuZWwvYWMtc291cmNlcy0y
LjQuMjJfcmMyLXIxICBTWzIuNC4yMi1yYzItYWMxXSAtYnVpbGQgLWRvYyArdGNsdGsgCltlYnVp
bGQgICAgIFUgXSBtZWRpYS1saWJzL2xpYnZvcmJpcy0xLjAtcjQgWzEuMC1yM10gU1swXSArc3Nl
IC0zZG5vdyAKW2VidWlsZCAgICAgVSBdIGFwcC1hZG1pbi9taXJyb3JzZWxlY3QtMC44MSBbMC44
XSBTWzBdIApbZWJ1aWxkICAgICBVIF0gYXBwLWFkbWluL3VmZWQtMC4zNCBbMC4zM10gU1swXSAK
W2Jsb2NrcyBCICAgICBdIGdub21lLWJhc2UvZ25vbWUtc2Vzc2lvbiAoZnJvbSBwa2cgZ25vbWUt
YmFzZS9nbm9tZS1jb3JlLTEuNC4yLXIxKQpbYmxvY2tzIEIgICAgIF0gZ25vbWUtYmFzZS9nbm9t
ZS1kZXNrdG9wIChmcm9tIHBrZyBnbm9tZS1iYXNlL2dub21lLWNvcmUtMS40LjItcjEpCltibG9j
a3MgQiAgICAgXSB4MTEtdGVybXMvZ25vbWUtdGVybWluYWwgKGZyb20gcGtnIGdub21lLWJhc2Uv
Z25vbWUtY29yZS0xLjQuMi1yMSkKW2VidWlsZCAgTiAgICBdIGdub21lLWJhc2UvZ25vbWUtY29y
ZS0xLjQuMi1yMSAgU1swXSAta2RlIC1ubHMgK2N1cHMgCltlYnVpbGQgIE4gICAgXSBkZXYtdXRp
bC9ndWlsZS0xLjYuNCAgU1sxMl0gCltlYnVpbGQgICAgIFUtXSBnbm9tZS1iYXNlL2xpYmd0b3At
MS4wLjEzLXIyICBTWzFdIC1ubHMgCltlYnVpbGQgICAgIFUtXSBnbm9tZS1iYXNlL2dub21lLWFw
cGxldHMtMS40LjAuNSAgU1sxXSAtbmxzIApbZWJ1aWxkICBOICAgIF0gZGV2LWxpYnMvbGlicmVw
LTAuMTYuMiAgU1swXSArcmVhZGxpbmUgCltlYnVpbGQgIE4gICAgXSB4MTEtbGlicy9yZXAtZ3Rr
LTAuMTUtcjMgIFNbMS4yXSArZ25vbWUgCltlYnVpbGQgIE4gICAgXSB4MTEtd20vc2F3ZmlzaC0x
LjAuMS1yNiAgU1swXSArZ3RrIC1ubHMgK2VzZCArZ25vbWUgCltlYnVpbGQgIE4gICAgXSBnbm9t
ZS1leHRyYS9tZWR1c2EtMC41LjEtcjMgIFNbMF0gLW5scyAKW2VidWlsZCAgICAgVS1dIGdub21l
LWJhc2UvbGlicnN2Zy0xLjAuMyAgU1sxXSAKW2VidWlsZCAgICAgVS1dIGdub21lLWJhc2UvZWVs
LTEuMC4yLXIzICBTWzFdIC1ubHMgCltlYnVpbGQgICAgIFVEXSBnbm9tZS1iYXNlL25hdXRpbHVz
LTEuMC42LXI5IFsyLjIuNF0gU1swXSAtbmxzICttb3ppbGxhIApbZWJ1aWxkICAgICBVRF0gZ25v
bWUtYmFzZS9nZG0tMi4yLjUuNC1yNSBbMi40LjEuNF0gU1swXSAtbmxzICtnbm9tZSAKW2VidWls
ZCAgICAgVS1dIGdub21lLWJhc2UvZ25vbWUtMS40LXIzICBTWzEuNF0gCltlYnVpbGQgICAgIFUg
XSBnbm9tZS1iYXNlL2xpYmd0b3AtMi4wLjMgWzIuMC4yLXIxXSBTWzJdIApbZWJ1aWxkICAgICBV
IF0gZ25vbWUtYmFzZS9nZG0tMi40LjEuNiBbMi40LjEuNF0gU1swXSAKW2VidWlsZCAgTiAgICBd
IG1lZGlhLWxpYnMvc3BlZXgtMS4wLjEgIFNbMF0gK29nZ3ZvcmJpcyArc3NlIApbZWJ1aWxkICAg
ICBVIF0gbWVkaWEtbGlicy94aW5lLWxpYi0xX3JjMC1yMiBbMV9iZXRhMTItcjFdIFNbMF0gK2Fy
dHMgK2VzZCArYXZpIC1ubHMgK2R2ZCArYWFsaWIgK1ggK2RpcmVjdGZiICtvZ2d2b3JiaXMgK2Fs
c2EgK2dub21lIApbZWJ1aWxkICAgICBVIF0gbWVkaWEtdmlkZW8veGluZS11aS0wLjkuMjIgWzAu
OS4yMV0gU1swXSArWCArYWFsaWIgK2dub21lIC1ubHMgK2RpcmVjdGZiIC1saXJjIApbZWJ1aWxk
ICAgICBVIF0gc3lzLWxpYnMvbGliY2FwLTEuMTAtcjEgWzEuMTBdIFNbMF0gK3B5dGhvbiAKCg==
</data>        

          </attachment>
    </bug>

</bugzilla>