Hello, i spent a full week to upgrade all the gentoo packages i have installed of my box in order to use the new -mtune flag amdfam10. I applied many changes in 33 ebuilds. They need probably a lot of improvements to be gentoo compliant and probably won't work on any other architecture or with earlier gcc but i lack of time to make them compliant. Please, don't blame me :) Only 33 of more than 1700 installed packages were not compatible with gcc 4.3 like uclibc 0.9.92 when cross-compiling with vapier crossdev ebuild for instance. Namely, most of them are from the gentoo instable tree. The compatible-gcc4.3-differences.diff.bz2 file contains the differences with the current portage tree. I'm not sure it is relevant as the tree changes every day. gcc-4.3-compatible.tar.bz2 contains all the ebuilds modified. They are part of my "not really nicely maintainable" local overlay and some are not in the gentoo tree ;) My box has not failed since... That's a good news isnt'it ? Jj Reproducible: Always
Created attachment 159007 [details] lot of ebuilds compatible gcc 4.3
Created attachment 159009 [details] differences with same current portage ebuilds
Please file separate bug reports so that each problem can be assigned to the proper maintainers of said ebuilds. Handling of many ebuilds by many maintainers in a single bug is known to end in tears. Bug wranglers will help you assign these bugs and we can probably use this very bug report itself as "tracker" bug, which means you set up the other bugs to block this one, and this bug is only closed when all the others are.
dev-lang/mono/files/mono-1.1.13-pathfix.diff dev-lang/mono/files/mono-1.2.4-make-check.patch dev-lang/mono/files/mono-1.2.4-pic.patch dev-lang/mono/files/mono-1.2.5-make-check.patch dev-lang/mono/files/mono-1.2.5-remoting.patch dev-lang/mono/files/mono-1.2.6-bug-347359.patch dev-lang/mono/files/mono-1.2.6-threads-types-private-prototypes.patch dev-lang/mono/files/mono-1.9.1-glibc-2.8-deprecated-arg-max.patch dev-lang/mono/files/mono-biginteger_overflow.diff dev-lang/mono/mono-1.9.1.ebuild net-nds/openldap/files/openldap-2.4-disable-bdb46.patch net-nds/openldap/files/openldap-2.4-ppolicy.patch net-nds/openldap/openldap-2.4.10.ebuild x11-wm/compiz/files/compiz-0.7.6.patch x11-wm/compiz/compiz-0.7.6.ebuild x11-wm/emerald/emerald-0.7.6.ebuild x11-wm/compiz-fusion/compiz-fusion-0.7.6.ebuild x11-base/xorg-server/files/1.4.2-unbreak-endianess.patch media-tv/miro/files/miro-gcc.4.3.patch media-tv/miro/miro-1.2.4_p20080625.ebuild sys-apps/util-linux/files/util-linux-ng-2.14-20080624.diff sys-apps/util-linux/util-linux-2.14.ebuild media-video/cinepaint/cinepaint-0.22.1.ebuild media-video/cinepaint/files/icc_helfer_fltk.patch media-video/cinepaint/files/multiple_parameters_named.patch media-video/cinepaint/files/icc_examin.patch media-video/cinepaint/files/Makefile.patch media-video/istanbul/istanbul-0.2.2.ebuild app-emulation/wine/wine-1.1.0.ebuild sys-libs/uclibc/files/uclibc-0.9.29-net-tools_compile.patch sys-libs/uclibc/files/fenv.h sys-libs/uclibc/files/uclibc-0.9.29-multi-definition.patch sys-libs/uclibc/uclibc-0.9.29.ebuild dev-python/compizconfig-python/compizconfig-python-0.7.6.ebuild media-libs/libgfx/libgfx-1.1.0.ebuild app-office/texmaker/files/texmaker-1.71-hunspell.patch app-office/texmaker/texmaker-1.71-r1.ebuild media-sound/sox/sox-14.0.1.ebuild app-i18n/scim-m17n/scim-m17n-0.2.2.ebuild app-i18n/scim-m17n/files/scim_m17n_imengine.patch app-i18n/scim-pinyin/files/scim-pinyin-0.5.91-gcc43.patch app-i18n/scim-pinyin/scim-pinyin-0.5.91-r2.ebuild dev-db/mysql-gui-tools/files/mysql-gui-tools-5.0_p12-gcc-4.3.patch dev-db/mysql-gui-tools/files/mysql-gui-tools-5.0_p12-libsigc++-2.2.patch dev-db/mysql-gui-tools/mysql-gui-tools-5.0_p12-r2.ebuild app-dicts/verbiste/files/c-api.patch app-dicts/verbiste/verbiste-0.1.21.ebuild x11-plugins/compiz-fusion-plugins-main/compiz-fusion-plugins-main-0.7.6.ebuild x11-plugins/compiz-fusion-plugins-extra/compiz-fusion-plugins-extra-0.7.6.ebuild x11-plugins/compiz-fusion-plugins-unsupported/compiz-fusion-plugins-unsupported-0.7.6.ebuild gnome-extra/gnome-system-monitor/gnome-system-monitor-2.23.3.ebuild gnome-base/libgtop/libgtop-2.23.2.ebuild net-www/netscape-flash/netscape-flash-10_beta20080515.ebuild x11-libs/compiz-bcop/compiz-bcop-0.7.6.ebuild x11-libs/compizconfig-backend-gconf/compizconfig-backend-gconf-0.7.6.ebuild x11-libs/libcompizconfig/libcompizconfig-0.7.6.ebuild x11-misc/rss-glx/rss-glx-0.8.1-r4.ebuild x11-misc/fireflies/files/fireflies-2.06-Make.include.in.patch x11-misc/fireflies/fireflies-2.07-r1.ebuild app-text/hunspell/files/hunspell-1.1.5-renameexes.patch app-text/hunspell/files/hunspell-1.2.2-libtool-2.22.patch app-text/hunspell/files/hunspell-1.2.2-renameexes.patch app-text/hunspell/hunspell-1.2.4-r1.ebuild x11-apps/ccsm/ccsm-0.7.6.ebuild dev-lisp/sbcl/files/sbcl-1.0.17-GNU_SOURCE.patch dev-lisp/sbcl/sbcl-1.0.17.ebuild
(In reply to comment #3) > Bug wranglers will help > you assign these bugs and we can probably use this very bug report itself as > "tracker" bug, which means you set up the other bugs to block this one, and > this bug is only closed when all the others are. Better yet, these new bugs should all block bug #198121, the tracker bug for GCC 4.3 porting. https://bugs.gentoo.org/showdependencytree.cgi?id=198121 should help you figure out if some of your patches are redundant or whether bug reports already exist for the packages you have patches for.
Last but not least, only the files changed are in the archives and not the unmodified patches already present in the ${FILESDIR} directory (I hope so). You need to check if they are in your tree before building the binaries.
(In reply to comment #5) > (In reply to comment #3) > > Bug wranglers will help > > you assign these bugs and we can probably use this very bug report itself as > > "tracker" bug, which means you set up the other bugs to block this one, and > > this bug is only closed when all the others are. > > Better yet, these new bugs should all block bug #198121, the tracker bug for > GCC 4.3 porting. https://bugs.gentoo.org/showdependencytree.cgi?id=198121 > should help you figure out if some of your patches are redundant or whether bug > reports already exist for the packages you have patches for. > Thank you for your fast reply. I will try to do my best but as you guess that has already taken me a lot of time. Please, don't blame me if I don't take my word for it.
desktop-misc herd ones are already reported: x11-misc/fireflies bug #228219. x11-misc/rss-glx bug #227071
(In reply to comment #7) > I will try to do my best but as you guess that has already taken me a lot of > time. Please, don't blame me if I don't take my word for it. I am saddened to say that this happens a lot in the open source world. :) Once every now and then, someone comes up with weeks to months of work as one big patch against an already establish volume of work, and the huge patch gets rejected simply because it is too large to review. In this case, however, the several patches you propose apply against packages that are maintained (exclusively) by different developers or groups of developers. Providing a single patch against the whole tree is not useful, both because of the rapid changes to the tree itself and because of the many voices that would need to be heard in order to get approval for the one huge patch. It's not that your work isn't appreciated - it's just that it is too much at once. :)
(In reply to comment #9) ... In this case, however, the > several patches you propose apply against packages that are maintained > (exclusively) by different developers or groups of developers. Providing a > single patch against the whole tree is not useful, both because of the rapid > changes to the tree itself and because of the many voices that would need to be > heard in order to get approval for the one huge patch. I agree with you. I did a lazy find of the last 7 days changes of my overlay directory, because that way was easier for me. I thought it would be more helpful to send it as early as possible so everyone could have a look at it even users like me, so they won't be stuck with gcc 4.2.x. Just don't bother about the diff file. As you said well, the portage tree is moving too fast. The tar file is the most relevant, especially the ebuild files. Many ebuilds just needs to be upgraded to the latest version and don't need a lot of work but others like cinepaint and uclibc took me more time. I will then concentrate to them and inform the maintainers. Don't be afraid about the lot of ${FILESDIR}s patches in the tar file. For example, "mono" was not in my overlay tree before. So they were picked up from portage tree even if I changed nothing. Better is to concentrate to the ebuild directly.
Sorry i forgot to say, many packages like gnome-system-monitor 2.22.2, paman 0.9.4 paprefs 0.9.6, inkscape, etc need to have the unstable libsig++ 2.2.2 in order to be compiled with gcc 4.3. tail /etc/portage/package.keyword libwpd libebml libsig++ are most welcome.
(In reply to comment #11) > Sorry i forgot to say, many packages like > > gnome-system-monitor 2.22.2, paman 0.9.4 paprefs 0.9.6, inkscape, etc need to > have the unstable libsig++ 2.2.2 in order to be compiled with gcc 4.3. If you mean dev-libs/libsigc++, that is being handled in bug #227679. > tail /etc/portage/package.keyword /etc/portage/package.keyword_s_ > libwpd > libebml > libsig++ I don't think having those in /etc/portage/package.keywords would work. In /etc/portage/package.keyword of course, they wouldn't do a thing. ;-)
Let's get bug-wranglers out of the loop.
?! Sorry, but you have to file a separate bug for pkgs.
