$ emerge --info '=app-admin/sudo-1.8.11::gentoo' Portage 2.2.14_rc1 (python 3.4.1-final-0, default/linux/amd64/13.0/desktop/kde, gcc-4.8.3, glibc-2.19-r1, 3.16.3-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.16.3-gentoo-x86_64-Intel-R-_Core-TM-_i7-4770K_CPU_@_3.50GHz-with-gentoo-2.2 KiB Mem: 16096380 total, 238260 free KiB Swap: 0 total, 0 free Timestamp of tree: Tue, 30 Sep 2014 02:15:01 +0000 ld GNU ld (Gentoo 2.24 p1.4) 2.24 app-shells/bash: 4.2_p50 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.8, 3.3.5-r1, 3.4.1 dev-util/cmake: 3.0.2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.13.1 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.13.4, 1.14.1 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.8.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2-r1 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.16 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo pg_007 stuff init6 laurentb mipl_emc ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-stack-protector" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-stack-protector" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.mcs.anl.gov/pub/gentoo/ rsync://mirror.mcs.anl.gov/gentoo/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/perfect_gentleman/overlay /var/lib/layman/stuff /var/lib/layman/init6 /var/lib/layman/laurentb /var/lib/layman/emc" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X aac acl acpi alsa amd64 avx avx2 bash-completion branding bzip2 cairo cdr cli consolekit cracklib cxx dbus declarative dri dts dvdr egl emboss encode exif fam firefox flac fontconfig gif glamor gpm iconv icq icu jabber jit jpeg kde kipi lcms libass libnotify libsamplerate lm_sensors lua mad matroska mmx mng modules multilib ncurses nls nptl opengl openmp oscar pango pcre pdf phonon plasma png policykit ppds qt3support qt4 readline sdl session smp spell sqlite sse sse2 sse3 sse4_1 ssl ssse3 svg tcpd threads tiff truetype udev udisks unicode upnp upower usb v4l vaapi wavpack wxwidgets x264 xcb xcomposite xml xv xvid zlib" ABI_X86="64 32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en ru" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python3_4 python3_3 python2_7" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="intel i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="3.4 3.3 2.7" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 385786 [details] build.log
http://forums.gentoo.org/viewtopic-t-1001062-highlight-.html
Created attachment 385792 [details, diff] Remove -lshadow From the shadow ebuild: # Remove libshadow and libmisc; see bug 37725 and the following # comment from shadow's README.linux: # Currently, libshadow.a is for internal use only, so if you see # -lshadow in a Makefile of some other package, it is safe to # remove it.
Ping? This cannot be built. Please either mask or patch.
Yep. I can't build it to.
Just when I thought gentoo mantainers could not screw things up any worse, they proved me wrong.
(In reply to Perfect Gentleman from comment #2) > http://forums.gentoo.org/viewtopic-t-1001062-highlight-.html According to this post in the above-referenced forum thread: > [ebuild U ] app-admin/sudo-1.8.11 [1.8.10_p3] USE="nls -ldap -offensive -pam (-selinux) -sendmail -skey" 2,344 KiB PAM is disabled in the above USE flags for your machine. If I build sudo with USE pam on my system, it builds fine. If I build without PAM, I get the error about -lshadow. Why is USE pam missing from your emerge --info? Are you disabling it anywhere specific? PAM support is a default in the base linux profile, so it should be enabled for you out of the box. Please check for that, and re-enable it if so, then try rebuilding sudo again and let us know if it still fails. Thanks!
(In reply to Joshua Kinard from comment #7) > (In reply to Perfect Gentleman from comment #2) > > http://forums.gentoo.org/viewtopic-t-1001062-highlight-.html > > According to this post in the above-referenced forum thread: > > [ebuild U ] app-admin/sudo-1.8.11 [1.8.10_p3] USE="nls -ldap -offensive -pam (-selinux) -sendmail -skey" 2,344 KiB > > PAM is disabled in the above USE flags for your machine. If I build sudo > with USE pam on my system, it builds fine. If I build without PAM, I get > the error about -lshadow. Why is USE pam missing from your emerge --info? > Are you disabling it anywhere specific? > > PAM support is a default in the base linux profile, so it should be enabled > for you out of the box. Please check for that, and re-enable it if so, then > try rebuilding sudo again and let us know if it still fails. > > Thanks! Ok, and what about those who choose to disable PAM for any reason?
(In reply to Joshua Kinard from comment #7) > (In reply to Perfect Gentleman from comment #2) > > http://forums.gentoo.org/viewtopic-t-1001062-highlight-.html > > According to this post in the above-referenced forum thread: > > [ebuild U ] app-admin/sudo-1.8.11 [1.8.10_p3] USE="nls -ldap -offensive -pam (-selinux) -sendmail -skey" 2,344 KiB > > PAM is disabled in the above USE flags for your machine. If I build sudo > with USE pam on my system, it builds fine. If I build without PAM, I get > the error about -lshadow. Why is USE pam missing from your emerge --info? > Are you disabling it anywhere specific? > > PAM support is a default in the base linux profile, so it should be enabled > for you out of the box. Please check for that, and re-enable it if so, then > try rebuilding sudo again and let us know if it still fails. > > Thanks! I have PAM disabled too. Being able to disable it is one of the reasons I'm using Gentoo.
Why do you disable PAM? I don't know if that would be a configuration we can support out of the box, given that PAM is tied into quite a few different things, and that it's a default in our base profile.
(In reply to Joshua Kinard from comment #10) > Why do you disable PAM? I don't know if that would be a configuration we > can support out of the box, given that PAM is tied into quite a few > different things, and that it's a default in our base profile. I disable it because I have no use for it on my personal machine. Disabling the USE flag is an allowed configuration anyway. The problem of "-lshadow" is trivial to begin with and is not an indication of there being a real problem on PAM-less systems. Also, I can't see PAM being tied into anything, actually. It seems to behave mostly as a wrapper around other things.
(In reply to Nikos Chantziaras from comment #11) > (In reply to Joshua Kinard from comment #10) > > Why do you disable PAM? I don't know if that would be a configuration we > > can support out of the box, given that PAM is tied into quite a few > > different things, and that it's a default in our base profile. > > I disable it because I have no use for it on my personal machine. > > Disabling the USE flag is an allowed configuration anyway. The problem of > "-lshadow" is trivial to begin with and is not an indication of there being > a real problem on PAM-less systems. > > Also, I can't see PAM being tied into anything, actually. It seems to behave > mostly as a wrapper around other things. PAM is the pluggable authentication modules component for Linux/BSD/Solaris. It basically allows you to easily switch between various login mechanisms, such as LDAP, passwd/shadow, NIS, RADIUS, Kerberos, etc. When dealing with basic passwd/shadow login, one could indeed view it as a superficial "wrapper", but the instant you want to switch to some other kind of authentication mechanism, you'll find yourself re-installing it pretty quickly. I've personally never had a problem with it on the 5-6 machines/VMs that I run (both amd64 and mips), so I leave it alone. And trust me, I'm a pretty hardcore minimalist myself on every OS install I've done, from Windows to NetWare to IRIX to Linux and even to FreeBSD. You're giving up a lot more than you gain by disabling something like this. Have you tried following this unofficial Gentoo Wiki site on removing PAM, and see if that solves your issue?: http://www.gentoo-wiki.info/HOWTO_Remove_PAM If not, I don't think this is a kind of change we can support without some discussion on the mailing list, and you'll need a bit more convincing evidence to support your reasoning other than just being able to flip an arbitrary USE flag. Just because you can flip a USE flag doesn't mean it's a configuration that we will support.
Please see comment #3 again: # Remove libshadow and libmisc; see bug 37725 and the following # comment from shadow's README.linux: # Currently, libshadow.a is for internal use only, so if you see # -lshadow in a Makefile of some other package, it is safe to # remove it. Note: "it is safe to remove it."
(In reply to Joshua Kinard from comment #12) > (In reply to Nikos Chantziaras from comment #11) > > (In reply to Joshua Kinard from comment #10) > > > Why do you disable PAM? I don't know if that would be a configuration we > > > can support out of the box, given that PAM is tied into quite a few > > > different things, and that it's a default in our base profile. > > > > I disable it because I have no use for it on my personal machine. > > > > Disabling the USE flag is an allowed configuration anyway. The problem of > > "-lshadow" is trivial to begin with and is not an indication of there being > > a real problem on PAM-less systems. > > > > Also, I can't see PAM being tied into anything, actually. It seems to behave > > mostly as a wrapper around other things. > > PAM is the pluggable authentication modules component for Linux/BSD/Solaris. > It basically allows you to easily switch between various login mechanisms, > such as LDAP, passwd/shadow, NIS, RADIUS, Kerberos, etc. When dealing with > basic passwd/shadow login, one could indeed view it as a superficial > "wrapper", but the instant you want to switch to some other kind of > authentication mechanism, you'll find yourself re-installing it pretty > quickly. > > I've personally never had a problem with it on the 5-6 machines/VMs that I > run (both amd64 and mips), so I leave it alone. And trust me, I'm a pretty > hardcore minimalist myself on every OS install I've done, from Windows to > NetWare to IRIX to Linux and even to FreeBSD. You're giving up a lot more > than you gain by disabling something like this. > > Have you tried following this unofficial Gentoo Wiki site on removing PAM, > and see if that solves your issue?: > http://www.gentoo-wiki.info/HOWTO_Remove_PAM > > If not, I don't think this is a kind of change we can support without some > discussion on the mailing list, and you'll need a bit more convincing > evidence to support your reasoning other than just being able to flip an > arbitrary USE flag. Just because you can flip a USE flag doesn't mean it's > a configuration that we will support. Joshua, are you dense? Are you retarded or something? Are you aware you have spent incredibly more time writing this bullshit than it requires to apply the patch above and commit the changes? Have you read that these people including me had sudo prior to 1.8.11 built and running WITHOUT PAM? Is it so hard to comprehend that you have to write to a mailing list because you cannot do it yourself?
(In reply to grey dot from comment #14) > (In reply to Joshua Kinard from comment #12) > > (In reply to Nikos Chantziaras from comment #11) > > > (In reply to Joshua Kinard from comment #10) > > > > Why do you disable PAM? I don't know if that would be a configuration we > > > > can support out of the box, given that PAM is tied into quite a few > > > > different things, and that it's a default in our base profile. > > > > > > I disable it because I have no use for it on my personal machine. > > > > > > Disabling the USE flag is an allowed configuration anyway. The problem of > > > "-lshadow" is trivial to begin with and is not an indication of there being > > > a real problem on PAM-less systems. > > > > > > Also, I can't see PAM being tied into anything, actually. It seems to behave > > > mostly as a wrapper around other things. > > > > PAM is the pluggable authentication modules component for Linux/BSD/Solaris. > > It basically allows you to easily switch between various login mechanisms, > > such as LDAP, passwd/shadow, NIS, RADIUS, Kerberos, etc. When dealing with > > basic passwd/shadow login, one could indeed view it as a superficial > > "wrapper", but the instant you want to switch to some other kind of > > authentication mechanism, you'll find yourself re-installing it pretty > > quickly. > > > > I've personally never had a problem with it on the 5-6 machines/VMs that I > > run (both amd64 and mips), so I leave it alone. And trust me, I'm a pretty > > hardcore minimalist myself on every OS install I've done, from Windows to > > NetWare to IRIX to Linux and even to FreeBSD. You're giving up a lot more > > than you gain by disabling something like this. > > > > Have you tried following this unofficial Gentoo Wiki site on removing PAM, > > and see if that solves your issue?: > > http://www.gentoo-wiki.info/HOWTO_Remove_PAM > > > > If not, I don't think this is a kind of change we can support without some > > discussion on the mailing list, and you'll need a bit more convincing > > evidence to support your reasoning other than just being able to flip an > > arbitrary USE flag. Just because you can flip a USE flag doesn't mean it's > > a configuration that we will support. > > Joshua, are you dense? Are you retarded or something? Are you aware you have > spent incredibly more time writing this bullshit than it requires to apply > the patch above and commit the changes? Have you read that these people > including me had sudo prior to 1.8.11 built and running WITHOUT PAM? Is it > so hard to comprehend that you have to write to a mailing list because you > cannot do it yourself? Pardon me. What I meant was "to add the patch above to the portage tree".
Have to agree, I'm using Gentoo without PAM on most of my machines (which I have plenty of). So I don't see any troubles here. And as Francisco Vazquez quoted -- this is safe to remove -lshadow. So what's the fuzz? Remove it let people use Gentoo the way the were using it before.
(In reply to Joshua Kinard from comment #7) > (In reply to Perfect Gentleman from comment #2) > > http://forums.gentoo.org/viewtopic-t-1001062-highlight-.html > > According to this post in the above-referenced forum thread: > > [ebuild U ] app-admin/sudo-1.8.11 [1.8.10_p3] USE="nls -ldap -offensive -pam (-selinux) -sendmail -skey" 2,344 KiB > > PAM is disabled in the above USE flags for your machine. If I build sudo > with USE pam on my system, it builds fine. If I build without PAM, I get > the error about -lshadow. Why is USE pam missing from your emerge --info? > Are you disabling it anywhere specific? > > PAM support is a default in the base linux profile, so it should be enabled > for you out of the box. Please check for that, and re-enable it if so, then > try rebuilding sudo again and let us know if it still fails. > > Thanks! Why do I need PAM ? Before that I got no problem with building sudo.
(In reply to Joshua Kinard from comment #10) > Why do you disable PAM? I don't know if that would be a configuration we > can support out of the box, given that PAM is tied into quite a few > different things, and that it's a default in our base profile. Embedded systems tend to avoid pam, so there may be a reason to support this. I don't want to create a maintenance burdon for anyone, so ping me if you need/want help with this.
[QA] sudo is an important system package, and it is unacceptable that it fails to build since almost one week now. Therefore I've package.masked sudo-1.8.11 now. # Ulrich Müller <ulm@gentoo.org> (5 Oct 2014) # Fails to build with USE="-pam", bug 524074. # Masked by QA, waiting for fix by maintainer. =app-admin/sudo-1.8.11
For reference, the bug is upstream at [1]. We might want to leave a comment that Gentoo still supports non-pam setups. [1] http://www.sudo.ws/bugs/show_bug.cgi?id=667
(In reply to Ulrich Müller from comment #19) > [QA] sudo is an important system package, and it is unacceptable that it > fails to build since almost one week now. Therefore I've package.masked > sudo-1.8.11 now. And by the way, the tone of some of the messages posted to this bug is also completely unacceptable. Please stick to the facts and don't attack maintainers. The mask is there now because IMHO there are technical reasons for it.
(In reply to grey dot from comment #15) > (In reply to grey dot from comment #14) > > (In reply to Joshua Kinard from comment #12) <snip> > > > If not, I don't think this is a kind of change we can support without some > > > discussion on the mailing list, and you'll need a bit more convincing > > > evidence to support your reasoning other than just being able to flip an > > > arbitrary USE flag. Just because you can flip a USE flag doesn't mean it's > > > a configuration that we will support. > > > > Joshua, are you dense? Are you retarded or something? Are you aware you have > > spent incredibly more time writing this bullshit than it requires to apply > > the patch above and commit the changes? Have you read that these people > > including me had sudo prior to 1.8.11 built and running WITHOUT PAM? Is it > > so hard to comprehend that you have to write to a mailing list because you > > cannot do it yourself? This tone is unacceptable in our communication mediums. > Pardon me. What I meant was "to add the patch above to the portage tree". If this was meant as a public apology, it fell short given the previous tone. If this is just to "protect yourself", it's not acceptable to use the above tone and then come up with "excuses" to avoid "consequences". Please reply to my comment to the comrel alias. Also, in the future please CC comrel if there's this type of abuse as we don't monitor everything around here.
(In reply to Ulrich Müller from comment #21) > (In reply to Ulrich Müller from comment #19) > > [QA] sudo is an important system package, and it is unacceptable that it > > fails to build since almost one week now. Therefore I've package.masked > > sudo-1.8.11 now. > > And by the way, the tone of some of the messages posted to this bug is also > completely unacceptable. Please stick to the facts and don't attack > maintainers. > > The mask is there now because IMHO there are technical reasons for it. https://bpaste.net/show/2fad84de87ec Just apply this patch to the tree, sign the manifest, and commit the changes. It should not really be that hard.
(In reply to Jorge Manuel B. S. Vicetto from comment #22) > (In reply to grey dot from comment #15) > > (In reply to grey dot from comment #14) > > > (In reply to Joshua Kinard from comment #12) > <snip> > > > > If not, I don't think this is a kind of change we can support without some > > > > discussion on the mailing list, and you'll need a bit more convincing > > > > evidence to support your reasoning other than just being able to flip an > > > > arbitrary USE flag. Just because you can flip a USE flag doesn't mean it's > > > > a configuration that we will support. > > > > > > Joshua, are you dense? Are you retarded or something? Are you aware you have > > > spent incredibly more time writing this bullshit than it requires to apply > > > the patch above and commit the changes? Have you read that these people > > > including me had sudo prior to 1.8.11 built and running WITHOUT PAM? Is it > > > so hard to comprehend that you have to write to a mailing list because you > > > cannot do it yourself? > > This tone is unacceptable in our communication mediums. Don't really care. > > Pardon me. What I meant was "to add the patch above to the portage tree". > > If this was meant as a public apology, it fell short given the previous tone. > If this is just to "protect yourself", it's not acceptable to use the above > tone and then come up with "excuses" to avoid "consequences". > Please reply to my comment to the comrel alias. It was an apology for my mistake on a technical term. It should be read as 's/to apply the patch above/to add the patch above to the portage tree/'. And what consequences are you talking about? Are you threatening me with a ban or what? Do you know how stupid it is to threaten a person with a ban when there is a completely open and unverified registration? Stop embarassing yourself with all that politeness and respect bullshit, and fix the goddamn bug already. It looks like three gentoo developers and more than a week of time is not enough to fix something that simple. > Also, in the future please CC comrel if there's this type of abuse as we > don't monitor everything around here. Sure, I will CC you everytime I encounter an outbreak of stupidity around here.
Upstream patch: http://www.sudo.ws/repos/sudo/raw-rev/fdf06757f25d Tested. Works fine for me.
(In reply to grey dot from comment #14) > > Joshua, are you dense? Are you retarded or something? Are you aware you have > spent incredibly more time writing this bullshit than it requires to apply > the patch above and commit the changes? Have you read that these people > including me had sudo prior to 1.8.11 built and running WITHOUT PAM? Is it > so hard to comprehend that you have to write to a mailing list because you > cannot do it yourself? I merely asked a question to those here that like to run systems without PAM. Filing a bug with your own solution doesn't mean that we developers are always going to accept that solution. Gentoo has a lot of users, who all run with a variety of configurations in their installs. Just because a change works for you doesn't mean it will work for everyone. That is why changes to core system packages (i.e., those maintained by base-system) sometimes require discussion among the developers to make sure we're not breaking other people's setups. What if the correct fix is not the one you originally proposed, but something different? By asking questions and understanding motivations, I can better research the cause and possibly come to the same conclusion as you. Or I might come to an entirely different conclusion. Give this some thought next time, and please refrain from launching personal attacks against others. You will find that people are more receptive to your ideas and proposals when you work with them and not when you're insulting them.
> I merely asked a question to those here that like to run systems without PAM. Really? > If not, I don't think this is a kind of change we can support without some discussion on the mailing list, and you'll need a bit more convincing evidence to support your reasoning other than just being able to flip an arbitrary USE flag. Just because you can flip a USE flag doesn't mean it's a configuration that we will support. Liar-liar, pants on fire.
(In reply to consus from comment #27) > > Liar-liar, pants on fire. Please stop spamming this bug. This is neither helpful nor wanted. There is a right way and a wrong way to debate stuff like this. Neither really belongs on bugs, and this is an example of the wrong way to go about it in any venue. See: https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct Considering that there seems to be agreement that this bug will be fixed, it is particularly counterproductive to post flames. Presumably you use Gentoo because it meets your needs. Bugging devs until they quit isn't going to improve this. I can't imagine that too many of us wake up in the morning saying, "gee, I wonder if there is a new version of sudo that I can work on migrating us to today!"
Sadly, sometimes it is the only way to get things moving. And you're right, I do like Gentoo and I understand that you guys are understaffed. As I mentioned before, I would like to help you and become a proxy(?) maintainter for this and several other packages. How do I do that?
(In reply to consus from comment #27) > > I merely asked a question to those here that like to run systems without PAM. > > Really? > >(In reply to Joshua Kinard from comment #10) > > > Why do you disable PAM? I don't know if that would be a configuration we > > > can support out of the box, given that PAM is tied into quite a few > > > different things, and that it's a default in our base profile. First sentence in that reply, I was asking why would someone want to disable PAM. I like to understand the motivations of others. Maybe someone has an idea that's better than my own. Maybe not. I won't know if I don't ask. > > If not, I don't think this is a kind of change we can support without some discussion on the mailing list, and you'll need a bit more convincing evidence to support your reasoning other than just being able to flip an arbitrary USE flag. Just because you can flip a USE flag doesn't mean it's a configuration that we will support. > > Liar-liar, pants on fire. Per quoting my own comment above, by "support", I mean that we default to enabling PAM in the base linux profile at profiles/default/linux/make.defaults" > # Default starting set of USE flags for all default/linux profiles. > USE="berkdb crypt ipv6 ncurses nls pam readline ssl tcpd zlib" It doesn't mean we prohibit users from disabling PAM, but that it's not a configuration that we support out-of-the-box in the default linux profiles. And it's not a configuration we can support in the default linux profiles unless there's compelling evidence to support such a change and a discussion can be had to evaluate what the impact of that change might be. Base system packages can potentially affect thousands of users using a variety of configurations. We have to be careful in making changes to those packages so as to not go breaking a lot of other systems that might otherwise work fine with PAM. But in this case, it appears to have been a problem upstream and should be resolved shortly. (In reply to consus from comment #29) > Sadly, sometimes it is the only way to get things moving. And you're right, > I do like Gentoo and I understand that you guys are understaffed. As I > mentioned before, I would like to help you and become a proxy(?) maintainter > for this and several other packages. How do I do that? This URL should have the info you're looking for if you're interested in becoming a proxy maintainer: http://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
(In reply to consus from comment #29) > Sadly, sometimes it is the only way to get things moving. And you're right, > I do like Gentoo and I understand that you guys are understaffed. As I > mentioned before, I would like to help you and become a proxy(?) maintainter > for this and several other packages. How do I do that? You were banned for the abuse on this bug. While looking clearly, since your account is a dupe of an already banned account (for prior abuse), this ban is now indefinite.
(In reply to Jorge Manuel B. S. Vicetto from comment #31) > (In reply to consus from comment #29) <snip> ... While looking clearly, since your <snip> I meant to say "while looking closer".
Two words: open registration.
So really, stop making yourself look stupid, unban my account and let me help you. I really want to :)
Restricting this bug to developers, for obvious reasons.
(In reply to Ulrich Müller from comment #35) > Restricting this bug to developers, for obvious reasons. Thanks, we need to have a sane discussion of this. I would argue we need to have this fixed because I was just bitten by this bug on multiple systems: 1) all my uclibc and musl stages have pam masked because it doesn't build. Also, its unclear if pam is desireable for embedded. 2) this also hit my lemote yeelong desktop where I had to mask pam because of some strange chain of dependencies leading back to the kernel (which I cannot remeber now.) 3) I haven't looked yet, but isn't the fix just a matter of patching the build system?
(In reply to Anthony Basile from comment #36) > (In reply to Ulrich Müller from comment #35) > > Restricting this bug to developers, for obvious reasons. > > Thanks, we need to have a sane discussion of this. > > I would argue we need to have this fixed because I was just bitten by this > bug on multiple systems: > > 1) all my uclibc and musl stages have pam masked because it doesn't build. > Also, its unclear if pam is desireable for embedded. Well, PAM is enabled as a default in profiles/default/linux/make.defaults. The problem is, I believe those defaults apply regardless of libc choice, so you might want to disable PAM via uclibc/musl profiles make.defaults, if you have those. IMHO, a better re-org of the profiles would handle this better, along with a lot of other problems, but that's a topic for another day... > 2) this also hit my lemote yeelong desktop where I had to mask pam because > of some strange chain of dependencies leading back to the kernel (which I > cannot remeber now.) Could it have been a MIPS-specific issue? PAM can be a bit cryptic to configure when you have to fiddle with alternate login mechanisms (like specific, weird brands of smartcards), but it's worked fine out of the box on all of my systems with just the basic passwd/shadow drivers. > 3) I haven't looked yet, but isn't the fix just a matter of patching the > build system? It looks like this was caused by a change upstream. Reportedly, sudo-1.8.10 worked fine on systems w/o PAM, but the build broke in 1.8.11. See here: http://www.sudo.ws/bugs/show_bug.cgi?id=667 So I guess they'll patch it upstream first, then we'll just pick up their changes in a new version or such.
(In reply to Joshua Kinard from comment #37) > (In reply to Anthony Basile from comment #36) > > (In reply to Ulrich Müller from comment #35) > > > Restricting this bug to developers, for obvious reasons. > > > > Thanks, we need to have a sane discussion of this. > > > > I would argue we need to have this fixed because I was just bitten by this > > bug on multiple systems: > > > > 1) all my uclibc and musl stages have pam masked because it doesn't build. > > Also, its unclear if pam is desireable for embedded. > > Well, PAM is enabled as a default in profiles/default/linux/make.defaults. > The problem is, I believe those defaults apply regardless of libc choice, so > you might want to disable PAM via uclibc/musl profiles make.defaults, if you > have those. IMHO, a better re-org of the profiles would handle this better, > along with a lot of other problems, but that's a topic for another day... Yes I agree a reorganization might be in order, but it seems that everything something breaks we "should" reorganize profiles. Its not a good design, and while we're not stuck with it, it is a steep valley to get out of. Back to the point, I do have PAM disalbe properly, but the point is that sudo now fails with USE=-pam. We should fix that. > > > > 2) this also hit my lemote yeelong desktop where I had to mask pam because > > of some strange chain of dependencies leading back to the kernel (which I > > cannot remeber now.) > > Could it have been a MIPS-specific issue? PAM can be a bit cryptic to > configure when you have to fiddle with alternate login mechanisms (like > specific, weird brands of smartcards), but it's worked fine out of the box > on all of my systems with just the basic passwd/shadow drivers. It had something to do with USE=pam pulling in polkit which now fails on mips because the kernel doesn't support AUDITSYSCALL or soemthing like that. It was easier to remove pam than try to get the syscall implemented in mips :( > > > > 3) I haven't looked yet, but isn't the fix just a matter of patching the > > build system? > > It looks like this was caused by a change upstream. Reportedly, sudo-1.8.10 > worked fine on systems w/o PAM, but the build broke in 1.8.11. See here: > http://www.sudo.ws/bugs/show_bug.cgi?id=667 > > So I guess they'll patch it upstream first, then we'll just pick up their > changes in a new version or such. Yeah, this is a perfectly reasonable solution. I'll just mask 1.8.11 on the uclibc/musl profiles. Let's just leave the earlier working versions of sudo (working with -pam I mean) on the tree until the fixed version gets pushed out so I have a working sudo for those systems. Thanks guys.
(In reply to Joshua Kinard from comment #37) > It looks like this was caused by a change upstream. Reportedly, sudo-1.8.10 > worked fine on systems w/o PAM, but the build broke in 1.8.11. See here: > http://www.sudo.ws/bugs/show_bug.cgi?id=667 > > So I guess they'll patch it upstream first, then we'll just pick up their > changes in a new version or such. Upstream had already commited the fix. Please see comment 25.
(In reply to Anthony Basile from comment #38) > Yeah, this is a perfectly reasonable solution. I'll just mask 1.8.11 on the > uclibc/musl profiles. Shouldn't be necessary since there's a global mask. See comment #19.
(In reply to Ulrich Müller from comment #40) > (In reply to Anthony Basile from comment #38) > > Yeah, this is a perfectly reasonable solution. I'll just mask 1.8.11 on the > > uclibc/musl profiles. > > Shouldn't be necessary since there's a global mask. See comment #19. Thanks Ulrich. I didn't read the bug carefullly because of all the noise. Reading it now, I'm confused about why there was so much commotion over something so routine.
Working on it. A bit disappointed that this got masked rather than fixed, when I said I had no time for it at the moment, but okay. Anthony, it also seems a tempest in a teapot for me, and it's the main reason why I no longer read bugmail.
Fixed and unmasked.
Thanks Diego.
Upstream has released sudo 1.8.11p1 containing a fix: http://www.sudo.ws/sudo/stable.html#1.8.11p1
(In reply to Joshua Kinard from comment #10) to be clear, USE=-pam is fully supported in Gentoo and will continue to be so
