Bugzilla Bug 231258

There is no datatype definition for RFC822BUFFER in the
net-libs/c-client-2004g. The datatype RFC822BUFFER is used in the
dev-lang/php-5.2.6-r1. So it will fail when compiling php with
net-libs/c-client-2004g.

Update to net-libs/c-client-2006k is necessary for the successful compiling of
dev-lang/php-5.2.6-r1. Maybe we should add a dependency of c-client-2006k in
php-5.2.6-r1 ebuild.

Reproducible: Always

PHP foks, this relates to bug 231156, I missed to cc you.

(In reply to comment #1)
> PHP foks, this relates to bug 231156, I missed to cc you.
> 

Although both of them are related with c-client-2006k, there is no direct
relation  between them. In one word, this bug can be solved by adding a new
ebuild dependency.

*** Bug 231402 has been marked as a duplicate of this bug. ***

+  10 Jul 2008; Christian Hoffmann <hoffie@gentoo.org> php-5.2.6-r2.ebuild:
+  the ext/imap security patch introduced in php-5.2.6-r2 raises the
+  dependency on c-client to version 2006k, fixing DEPEND accordingly, bug
+  231258

Thanks for the reports, should be fixed now.

i don`t use net-libs/c-client i use at server: net-mail/uw-imap

If i try now update php i got error:
Calculating world dependencies... done!
[ebuild     U ] dev-lang/php-5.2.6-r2 [5.2.6_rc4] USE="apache2 berkdb cli crypt
ctype doc gd gdbm iconv imap mysql ncurses nls pcre readline reflection session
spl ssl unicode xml zlib -adabas -bcmath -birdstep -bzip2 -calendar -cdb -cgi
-cjk -concurrentmodphp -curl -curlwrappers -db2 -dbase -dbmaker -debug
-discard-path -empress -empress-bcs -esoob -exif -fastbuild -fdftk -filter
-firebird -flatfile -force-cgi-redirect -frontbase -ftp -gd-external -gmp -hash
-inifile -interbase -iodbc -ipv6 (-java-external) -json -kerberos -kolab% -ldap
-ldap-sasl -libedit -mcve -mhash -msql -mssql -mysqli -oci8
-oci8-instant-client -odbc -pcntl -pdo -pic -posix -postgres -qdbm -recode
-sapdb -sharedext -sharedmem -simplexml -snmp -soap -sockets -solid -spell
-sqlite -suhosin -sybase -sybase-ct -sysvipc -threads -tidy -tokenizer
-truetype -wddx -xmlreader -xmlrpc -xmlwriter -xpm -xsl -yaz -zip
-zip-external" 0 kB
[ebuild  N    ]  net-libs/c-client-2006k  USE="pam ssl -kolab" 2,660 kB
[blocks B     ] net-libs/c-client (is blocking net-mail/uw-imap-2004g-r2)
[blocks B     ] net-mail/uw-imap (is blocking net-libs/c-client-2006k)

> [ebuild  N    ]  net-libs/c-client-2006k  USE="pam ssl -kolab" 2,660 kB
> [blocks B     ] net-libs/c-client (is blocking net-mail/uw-imap-2004g-r2)
> [blocks B     ] net-mail/uw-imap (is blocking net-libs/c-client-2006k)
> 

I don't use uw-imap, so I don't know exactly how to deal with your problem. But
IMHO, I think you can unmerge uw-imap and try it again.

And after checking the new php-5.2.6-r2 ebuild, I think you must use c-client
for imap in php.

(In reply to comment #5)
> i don`t use net-libs/c-client i use at server: net-mail/uw-imap
If you want to use php w/ USE=imap, you need net-libs/c-client. It has always
been like that. However, the dependency on the version of c-client was raised
yesterday. Maybe this is the cause (didn't check), but it's unlikely and we
cannot do anything about it.

If you still think this is a problem, which can be fixed, please file a
seperate bug report. Your problem is different from the one which has been
discussed (and fixed) in this ticket.

c-client is an IMAP client.  uw-imap is an IMAP server.  I run uw-imap as my
IMAP server, and apache/php/squirrelmail for web mail access; therefore, I need
uw-imap for my IMAP server, and c-client is now imposed by the php that runs
squirrelmail, which creates a conflict.  Why should the c-client imap client
and the uw-imap imap server have anything in common to conflict with each
other?  Something's goofy here!

(In reply to comment #8)
> c-client is an IMAP client.  uw-imap is an IMAP server.  I run uw-imap as my
> IMAP server, and apache/php/squirrelmail for web mail access; therefore, I need
> uw-imap for my IMAP server, and c-client is now imposed by the php that runs
> squirrelmail, which creates a conflict.  Why should the c-client imap client
> and the uw-imap imap server have anything in common to conflict with each
> other?  Something's goofy here!
> 

Got this same problem. uw-imap is an IMAP server and  apache/php/squirrelmail
for web mail access - and can`t compile a new php.
For now i use -imap in php flags.

Only I need to support IMAP as my mail access for more clients than just
squirrelmail.  :-(

Well, I haven't considered uw-imap as it has no recent version in the tree.
Apparently the versions are identical to c-client, so it should be fine once
we've got it bumped.
I'll hopefully open another bug report about this issue tomorrow, as this it
not really related to this big report.

(In reply to comment #11)
> Well, I haven't considered uw-imap as it has no recent version in the tree.
> Apparently the versions are identical to c-client, so it should be fine once
> we've got it bumped.
> I'll hopefully open another bug report about this issue tomorrow, as this it
> not really related to this big report.
> 

It seems the Gentoo is seriously outdated. I think we need to update uw-imap,
c-client to the latest version, which is 2007b currently. After the update,
it's proper to change the dependency of php-5.2.6-r2 from "imap ?
(>=net-libs/c-client-2006k )" to "imap ? (virtual/imap-c-client)".

(In reply to comment #12)
> (In reply to comment #11)
> It seems the Gentoo is seriously outdated. I think we need to update uw-imap,
> c-client to the latest version, which is 2007b currently. After the update,
> it's proper to change the dependency of php-5.2.6-r2 from "imap ?
> (>=net-libs/c-client-2006k )" to "imap ? (virtual/imap-c-client)".
With approval from dertobi123 I bumped uw-imap (see bug 153281) and changed
php's dependency accordingly.

Now we need this version stable (as php is as well). CC'ing net-mail team for
that matter and hoping that we can do that in some days. At least users now
have the opportunity to easily "fix" that themselves (simply appending
net-mail/uw-imap + deps to package.keywords should work).

Target keywords for net-mail/uw-imap and net-mail/uw-mailutils are:
alpha amd64 hppa ia64 ppc ppc64 sparc x86 (~s390 ~arm ~sh ~x86-fbsd)

net-mail, feel free to request stabilization whenever you want.

(In reply to comment #13)
> net-mail, feel free to request stabilization whenever you want.

Given the fact it took almost two years to get newer uw-imap and uw-mailutils
into the tree it should be no problem to wait the usual 30 days.

*** Bug 234285 has been marked as a duplicate of this bug. ***

(In reply to comment #13)
> Target keywords for net-mail/uw-imap and net-mail/uw-mailutils are:
> alpha amd64 hppa ia64 ppc ppc64 sparc x86 (~s390 ~arm ~sh ~x86-fbsd)
> 
> net-mail, feel free to request stabilization whenever you want.

Let's get this done.

Please mark as stable:
=net-mail/uw-imap-2007b
=net-mail/uw-mailutils-2007b 

I marked both uw-imap and uw-mailutils as ~x86 in
/etc/portage/packages.keywords and get the following when I try to update
uw-imap:

[ebuild     U ] net-mail/uw-imap-2007b [2004g-r2] 
[ebuild     U ] net-mail/uw-mailutils-2007b [2004g] 
[blocks B     ] <net-mail/uw-imap-2007b (is blocking
net-mail/uw-mailutils-2007b

If I read the ebuilds correctly, uw-imap-2007b requires uw-mailutils-2007b. but
uw-mailutils-2007b has a DEPEND that excludes uw-imap:
DEPEND="virtual/libc
    !<net-mail/uw-imap-${PV}
    !<mail-client/pine-4.64-r1"

(In reply to comment #17)
> uw-mailutils-2007b has a DEPEND that excludes uw-imap:
> DEPEND="virtual/libc
>     !<net-mail/uw-imap-${PV}
>     !<mail-client/pine-4.64-r1"
> 

The dependency !<net-mail/uw-imap-${PV} just exclude uw-imap which version is
less than ${PV} (2007b), not uw-imap-2007b.

I just moved the dependency/blocker to RDEPEND in both packages, which
hopefully fixes this issue.

amd64/x86 stable

sparc stable

Stable for HPPA.

*** Bug 235471 has been marked as a duplicate of this bug. ***

(In reply to comment #19)
> I just moved the dependency/blocker to RDEPEND in both packages, which
> hopefully fixes this issue.
> 
I don't think it does, since the block is still present when emerge attempted.
As reported in bug just marked as a duplicate of this one:  Bug 235471
Your update dated 19 August, emerge -uNDpv world fails 22nd August.

ppc64 stable

Is this bug going to be fixed? It appears that people think it is, yet the
results on my latest attempt to update my system result in:

[blocks B     ] <net-mail/uw-imap-2007b (is blocking
net-mail/uw-mailutils-2007b)

emerge -C net-mail/uw-imap net-mail/uw-mailutils
emerge net-mail/uw-imap

(In reply to comment #26)
> Is this bug going to be fixed? It appears that people think it is, yet the
> results on my latest attempt to update my system result in:
Well, I see the blocker as well, but portage-2.2 automatically solves it
without user interaction. I'm pretty sure this is not a regression (i.e. it
probably happened when upgrading to 2004g as well) and there is probably really
no way to solve this without removing the blocker completely, and I won't do
that unless I know why it has been there in the first place. Any comments,
net-mail?

As a workaround, either do it as Marek Królikowski suggested in comment 27, or
like that:
  emerge --nodeps -1 uw-mailutils
  emerge --noreplace -1 uw-imap uw-mailutils

alpha/ia64 stable

ppc stable and closing.