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.
