>>> Emerging (10 of 13) sys-libs/pam-1.0.1 to / * Linux-PAM-1.0.1.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking Linux-PAM-1.0.1.tar.bz2 ;-) ... [ ok ] * * Your current setup is using one or more of the following modules, * that are not built or supported anymore: * pam_pwdb, pam_radius, pam_timestamp, pam_console * If you are in real need for these modules, please contact the maintainers * of PAM through http://bugs.gentoo.org/ providing information about its * use cases. * Please also make sure to read the PAM Upgrade guide at the following URL: * http://www.gentoo.org/proj/en/base/pam/upgrade-0.99.xml * >>> Unpacking source... >>> Unpacking Linux-PAM-1.0.1.tar.bz2 to /var/tmp/portage/sys-libs/pam-1.0.1/work ... pam_console is not in my USE flags in make.conf; still, it is mentionned in emerge --info, thus, I conclude that, directly or indirectly, it has been put in by a dependency; thus, in any case, there is at some place, either in portage, or in an ebuild, a package that puts it in. Thus, this is not a case where *I* need that flag, and this is a double reason to report the problem (the message says that even if *I* wanted it, I should report). I hope maint will not consider this as a dup of bug #219558 , but maybe rather make 219558 blocking this one, and maybe mark this one as tracker ? Maybe you want to rename this bug as "[tracker] packages that IUSE depercated pam_pwdb, pam_radius, pam_timestamp, pam_console" ?
Created attachment 156891 [details] /tmp/emerge--info
This looks like not a bug for me at all. I made sure that all the packages in the tree using the old setup were gone, and I removed pam_console from packages were gone. You _might_ have something brought in that comes from a third party overlay but I cannot be responsible for that.
how can i determine which ebuilds inject those flags ? something like "equery depends" for flags ... I understand that, if the problem is due to an alternative overlay, this BTS is the wrong place to report; but would you be kind enough to help me proove this ? the answer to this question would of course tell me which maint I shall contact to ask for a fix, for the happyness of other users. I do use some overlays, but very few of them. Likely to be in layman/enlightenment ... cause I am 99% sure it's not due to my local private one. Still: moon-gen-3 ~ # cd /opt/doublehp/usr/portage/ moon-gen-3 portage # grep -nri pam_console * moon-gen-3 portage # cd /usr/portage/local/layman/enlightenment moon-gen-3 enlightenment # grep -nri pam_console * moon-gen-3 enlightenment # cd /usr/portage/ moon-gen-3 portage # for i in `ls |grep -v distfil` ; do grep -nr pam_console $i/ ; done the last command is very verbose; most of it mentions about the flag removal, but, there is a part that seems to still use it "actively": sys-apps/shadow/files/login.pamd.1:23:# If you want to enable pam_console, uncomment the following line sys-apps/shadow/files/login.pamd.1:24:# and read carefully README.pam_console in /usr/share/doc/pam* sys-apps/shadow/files/login.pamd.1:25:#session optional pam_console.so sys-apps/shadow/files/login.pamd:24:# If you want to enable pam_console, uncomment the following line sys-apps/shadow/files/login.pamd:25:# and read carefully README.pam_console in /usr/share/doc/pam* sys-apps/shadow/files/login.pamd:26:#session optional pam_console.so sys-apps/shadow/files/pam.d-include/login:12:session optional pam_console.so sys-apps/shadow/ChangeLog:498: move the login pam.d file there. Remove the pam_console comments from sys-auth/consolekit/ChangeLog:123: New package, needed for GDM, but will hopefully soon replace pam_console sys-fs/devfsd/files/devfsd.conf:70:#REGISTER .* CFUNCTION /lib/security/pam_console_apply_devfsd.so pam_console_apply_single $devpath ls -l in respectively sys-libs/pam and sys-apps/shadow reveals that there is no ebuild for shadow that is younger than pam-1.0.1 => is shadow is really sensitive to pam_console, then you forgot to make a revision. I may be wrong, because I dont have knowledge to dig deeper. moon-gen-3 portage # cd /etc/ moon-gen-3 etc # grep -nr pam_console * [...] dont show any explicit reason to me to insert IUSE="pam_console". Still, I have this to emerge since one week, and it failed again this morning: moon-gen-3 ~ # emerge -DaNuv world These are the packages that would be merged, in order: Calculating world dependencies... done! [ebuild U ] sys-libs/pam-1.0.1 [0.99.9.0] USE="cracklib nls vim-syntax -audit (-selinux) -test" 0 kB [ebuild N ] sys-auth/pambase-20080318 USE="cracklib -consolekit -debug -gnome-keyring -mktemp -passwdqc (-selinux)" 0 kB [ebuild U ] app-admin/sudo-1.6.9_p16 [1.6.9_p13] USE="offensive pam -ldap (-selinux) -skey" 0 kB [ebuild U ] app-office/openoffice-2.4.1 <SNIP we dont mind> Total: 4 packages (3 upgrades, 1 new), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] Since I use overlays, you _may_ be right :) still, I am stuck on emerging an ordinary portage ebuild ... and I am not convienced yet it's my fault. Last check, last chance to know who ever talked about this flag in my box, the place where "had been installed ebuild" is stored, even when ebuilds are removed from trees: moon-gen-3 portage # cd /var/cache/ moon-gen-3 cache # grep -nr pam_console * moon-gen-3 cache #
Fixed. File /etc/pam.d/entrance mentionned pam_console; this file is owned by Entrance, a component of E17 that belongs to an overlay. Entrance is a CVS/9999 ebuild that is never updated by emerge -DaNuv world. Since build fails for now, I just removed it. Pam compiled fine. Problem fixed for me. Still, I think this message could be improoved. To understand the reason of the problem, I had to read the ebuild. It would be more convinient if the message had mentionned at least a static message like "some file in /etc/pam.d/ is not pam-1 compatible", or better, give the list of files causing the problem ...
