Fails to emerge during compilation. As a side note, version 3.0.3 emerges fine. Reproducible: Always Steps to Reproduce: 1. Use vanilla-sources-2.6.31* 2. emerge lm_sensors Actual Results: make: *** No rule to make target `asm/bitsperlong.h', needed by `prog/dump/i2cbusses.rd'. Stop. Expected Results: Successful emerge. Portage 2.2_rc38 (default/linux/amd64/2008.0/desktop, gcc-4.4.1, glibc-2.10.1-r0, 2.6.31-rc6-radeon x86_64) ================================================================= System uname: Linux-2.6.31-rc6-radeon-x86_64-Intel-R-_Core-TM-2_CPU_6300_@_1.86GHz-with-gentoo-2.0.1 Timestamp of tree: Fri, 21 Aug 2009 14:15:02 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 2.4 [enabled] app-shells/bash: 4.0_p28 dev-java/java-config: 2.1.8-r1 dev-lang/python: 2.6.2-r1, 3.1.1 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.4-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox: 2.0 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=core2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -march=core2" DISTDIR="/home/portage/distfiles" FEATURES="assume-digests ccache collision-protect distlocks fixpackages parallel-fetch prelink preserve-libs protect-owned sandbox sfperms splitdebug strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://ftp.iinet.net.au/pub/Gentoo " LANG="en_AU.UTF-8" LC_ALL="en_AU.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="en_AU.UTF-8 en_AU en_GB.UTF-8 en_GB" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/home" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/sunrise /usr/local/portage/layman/x11 /usr/local/portage" SYNC="rsync://rsync.au.gentoo.org/gentoo-portage" USE="X a52 aac aalib acpi alsa amd64 ao bash-completion berkdb blas branding bzip2 cairo cddb cdr cli cracklib crypt curl dbus djvu dts dvd dvdr emboss encode exif expat fam ffmpeg fftw flac fontconfig fortran gd gdbm gif gmp gnome gnutls gphoto2 gpm graphviz gsl gstreamer gtk hal iconv icq icu imagemagick imlib ipod ipv6 isdnlog java java6 javascript jpeg jpeg2k kde lapack ldap libnotify lm_sensors lzo mad matroska mikmod mmap mmx mng mp3 mp4 mpeg mplayer msn mudflap multilib mysql mysqli ncurses nls nptl nptlonly nsplugin ntfs offensive ogg openal opengl openmp pam pch pcre pdf perl plasma png ppds pppd python qt3 qt3support qt4 quicktime readline reflection samba sdl session sharedmem smp speex spell spl sqlite sqlite3 sse sse2 ssl startup-notification subversion svg sysfs syslog tcpd theora threads tiff timidity truetype unicode usb v4l2 vcd vorbis wavpack wmf wxwindows x264 xcb xcomposite xml xorg xpm xscreensaver xulrunner xv xvid xvmc zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="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 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" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_AU.UTF-8 en_AU en_GB.UTF-8 en_GB" USERLAND="GNU" VIDEO_CARDS="radeon" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 201909 [details] Fails to compile.
I've got the same problem.
I would *NOT* expect stable lm_sensors (which has to work with stable {gentoo,vanilla}-sources to work with *latest* ~arch kernels. Assigning to maintainers, but hands are tied if 3.0.3 does not work with stable kernels (gentoo-sources-2.6.30-r4) because a stablereq cannot take place. It would greatly help if you could downgrade your kernel and give 3.0.3 a try.
(In reply to comment #3) > I would *NOT* expect stable lm_sensors (which has to work with stable > {gentoo,vanilla}-sources to work with *latest* ~arch kernels. > > Assigning to maintainers, but hands are tied if 3.0.3 does not work with stable > kernels (gentoo-sources-2.6.30-r4) because a stablereq cannot take place. It > would greatly help if you could downgrade your kernel and give 3.0.3 a try. > Hi Jeremy. :) I didn't strictly expect it (lm_sensors-2.10) to work either, so this report is really just to alert the Gentoo team that an issue exists. I figure that it's an issue of enough importance to make note of it as early as possible. Cheers.
Never mind about vanilla, it doesn't compile for gentoo-sources either. Isn't this pretty serious, since a lot of CPU temperature monitoring depends on it?
Just a quick FYI, almost all packaged ebuilds providing kernel modules fail to compile against gentoo-sources-2.6.31. :-/
Same here
And here
/usr/src/linux/include/asm/bitsperlong.h now is /usr/src/linux/include/asm-generic/bitsperlong.h in kernel-2.6.31
Wrong!!! Not all packaged ebuilds fail against 2.6.31 sources. Surprisingly, vmware-modules which are always a problem emerged on the first try. Also virtualbox modules emerged without problems. Those are the first to fail. Unfortunately, lm_sensors failed for me too. Fortunately, I still have 2.6.30 sources installed.
To have lm_sensors build you can use a symlink...albeit an icky fix. copy&paste: ln -snf /usr/src/linux/include/asm-generic/bitsperlong.h /usr/src/linux/include/asm/bitsperlong.h
Seems it's more of a problem in kernel tree, since find /usr/src/linux/ -type f -exec grep -H 'asm/bitsperlong.h' '{}' \; run at 2.6.31 kernel tree shows quite a few of files using old name.
Although I couldn't compile 2.10 on gentoo-sources-2.6.31 either, on another box I upgraded the kernel from an earlier version that already had lm_sensors-2.10.7 without problem. So a work-around would be to downgrade the kernel, install lm_sensors and re-upgrade the kernel. Not pretty, though.
#12 is partly wrong, as of more careful investigation. Well, it doesn't change the fact that most of arch-specific headers should be in include/asm by the time of make prepare. to #11, it's more correct to symlink arch/$ARCH/include/asm/bitsperlong.h to include/asm/bitsperlong.h, since bitsperlong is arch-specific.
Foolow-up: Well, kernel upstream developer said just a minute ago in linux-kernel mail list, quote "The correct fix is to include the missing bitsperlong in the asm-x86 directory. In other words your kernel headers are broken. Looking at latest kernel we do export bitsperlong.h. So see if you can find a fix for your broken kernel headers." So, it seems that either upstream kernel version was fixed in the meantime, or gentoo version was broken to begin with.
ADDENDUM 1: http://www.lm-sensors.org/wiki/FAQ/Chapter3#Mysensorshavestoppedworkinginkernel2.6.31 ADDENDUM 2: http://bugzilla.kernel.org/show_bug.cgi?id=13967
(In reply to comment #16) Example: partial success on ASUS M2N-SLI Deluxe with AMD Phenom X4: # ll /usr/src/linux/include/asm-x86/bitsperlong.h <...> bitsperlong.h -> ../../arch/x86/include/asm/bitsperlong.h This enables successful compilation; but starting (even after freshly building /etc/sensors.conf and /etc/conf.d/lm_sensors) fails :( Thus I resorted to: # grep "2.6.31" /boot/grub/grub.conf kernel /boot/vmlinuz-2.6.31-gentoo-r1 <...> acpi_enforce_resources=lax DISCLAIMER: The WARNING in above link (addendum 1) should be taken SERIOUSLY: DO NOT enable acpi_enforce_resources=lax unless you exactly know your MoBo !
saw the same issue with 2.6.31-r1 on amd64. I made a slight tweak to the ebuild and everything seems to work. I'll post the diff to the ebuild for further testing (and verification that it's the "right way" to fix the problem).
Created attachment 206031 [details, diff] patch that allows lm_sensors to build for me. tested on amd64 with 2.6.31.gentoo-r1 using gcc 4.4.1
Removing I2C_HEADERS is a bad idea, since by default lm_sensors Makefile searches in /usr/local/include (which is empty), and headers in /usr/include are outdated or at least differ substantially from ones in /usr/src/linux/... So again, I say that it's more correct to symlink /usr/src/linux/arch/$ARCH/include /asm/bitsperlong.h to /usr/src/linux/include/asm/bitsperlong.h for a workaround and that we need to fix kernel header exports, not lm_sensors in terms of long run.
I've decided that this really isn't a bug after all. The lm_sensors-2.x series is so out of date that it can't reasonably be expected to work with modern kernels -- it was last updated in December 2008. What is frustrating is that the modern lm_sensors-3.x series was first released way back in November 2007 and was only just unmasked in the portage tree in the past few days! Mobile herd, what are you doing??? Why aren't there any 3.1.x ebuilds in the tree given that it was first released in February of this year? I think lm_sensors users have the right to feel a bit neglected and angry. I realise that there are complications due to other packages (net-snmp) not supporting lm_sensors-3, but surely that doesn't mean that all lm_sensors users have to suffer for it? Although some explanation for the apparent lack of activity would be appreciated, what's more important is for the activity to resume. I don't know if Gordon is part of the mobile herd or not, but it's fantastic that he has fixed net-snmp and unmasked 3.0. Next it would be great to see a 3.1 ebuild in the tree and some extra dependencies so that users are warned/blocked from using the wrong lm_sensors series for the wrong kernel versions. I'm talking about the recent changes that appeared in 2.6.31 that Manfred posted a link to in comment 16, which says that 2.6.31 onwards depends on >=lm_sensors-3.1. It probably won't be long before 2.6.31 goes stable, and then EVERY lm_sensors user is going to be surprised and upset when they upgrade. So even though I don't think that this is a bug that can be fixed, it does reflect the problem that there is no stable lm_sensors available for modern kernels, so I'll leave it open until 3.1 goes stable. :) I should also direct you all to bug #244598 where there is a working ebuild for 3.1.1. Cheers.
(In reply to comment #21) Jeremy, there's one another candidate missing: # cd /usr/portage/ && grep -R "<sys-apps/lm_sensors-3" * | grep -v "metadata" reveals that all cpufreqd (even the latest sys-power/cpufreqd/cpufreqd-2.2.1.ebuild) contain . . . . . lm_sensors? ( <sys-apps/lm_sensors-3 ) thus resulting into a slot conflict because both: . . . . . lm_sensors-2 and . . . . . lm_sensors-3 get required. There's some work going on upon cpufreqd-2.3.3 / -2.3.4 in Bug #233481.
(In reply to comment #22) Ah, interesting. Well, I don't actually see why these issues are reasons to block or mask lm_sensors itself. It looks like they can be handled sufficiently with blocks or dependencies, etc.
(In reply to comment #23) I whole-heartedly agree ... All these findings just emphasize that until sounding a concert, the whole buch has to be (and kept) maintained in order to provide Gentoo with an adequate up-to-date sensor handling again.
3.1.1 is now in the tree. 2.10.8 wont be fixed to work with kernel 2.6.31*
*** Bug 294658 has been marked as a duplicate of this bug. ***
All working versions are still masked but gentoo-sources-2.6.31 is not
(In reply to comment #27) > All working versions are still masked but gentoo-sources-2.6.31 is not Yes indeed, and I really wonder how this bug can be marked as fixed then. It should be the broken versions 2.10.7 and 2.10.8 that are masked, not the version that actually works.
Don't forget that this is not a simple situation. lm_sensors 2.10.x are not broken, they are simply not designed to work with modern kernels and probably never will. What *is* broken is the ebuild logic that allows users to emerge 2.10.x on kernels >=2.6.31, since those kernels require version 3.1. *hint hint to the Mobile herd* I agree that this bug is not fixed, but it should be marked as "invalid" and closed so that we can move past it.
Reopening in order to mark as invalid.
Please do not forget that as long as =sys-apps/lm_sensors-3.1.1 is not stable, people keep having this bug. 2.6.31 kernel is stable; so, users need 3.1.1 stable ASAP. Where is the stablreq ? I keyworded =sys-apps/lm_sensors-3.1.1 and it worked for me. sys-apps/lm_sensors-3.1.1 STABLE REQ : bug #301474
Demaine, this bug is actually invalid. The real bug is that lm_sensors-2.* should be blocked from being emerged on a kernel >=2.6.31. This coupled with the fact that lm_sensors-3.* is still in ~arch is what is creating such a headache.
it's not INVALID, as the old version actually can be build against newer kernels.
fixed in cvs. thanks for the proposed fix! help with getting lm_sensors-3 stabilized still greatly appreciated - see bug #301474.
*** Bug 295029 has been marked as a duplicate of this bug. ***
