* +390861426 8747 /var/tmp/portage/media-libs/libv4l-1.12.3/image/usr/include/libdvbv5/nit.h * +533948328 9077 /var/tmp/portage/media-libs/libv4l-1.12.3/image/usr/include/libdvbv5/dvb-v5-std.h * ERROR: media-libs/libv4l-1.12.3::gentoo failed (install phase): * Header checksum mismatch, aborting. * * Call stack: ----------------------------------------------------------------- This is an unstable amd64 chroot image (named plasma-systemd-abi32+64_20170423-124403) at a hardened host acting as a tinderbox. ----------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-5.4.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback) Available Ruby profiles: [1] ruby21 (with Rubygems) * [2] ruby22 (with Rubygems) java-config: The following VMs are available for generation-2:
Created attachment 470892 [details] emerge-info.txt
Created attachment 470894 [details] config.log.tbz2
Created attachment 470896 [details] emerge-history.txt
Created attachment 470898 [details] environment
Created attachment 470900 [details] etc.portage.tbz2
Created attachment 470902 [details] media-libs:libv4l-1.12.3:20170425-163704.log
Created attachment 470904 [details] temp.tbz2
Same issue with media-libs/libv4l-1.12.5
*** Bug 626012 has been marked as a duplicate of this bug. ***
same issue with libv4l-1.12.5 on ~amd64 i had disabled the jpeg USE flag with the same results
Same issue with version 1.14.1, gcc 7.2.0, gentoo profile 17.1.
Created attachment 526224 [details] Fix header checksum mismatch Fix header checksum mismatch, also bumped to 1.14.2. This fix should probably also be backported to 1.12.x. Added use flag to enable/disable libdvbv5 which requires libudev to have the multilib use dependencies, although it should probably just be disabled be a different package.
Created attachment 526234 [details] Missed sysmacro patch
Ok, I met the same problem with 1.16.3, and found a solution looking for the config log. Comparing the summary for 32 and 64 bits I found that, it was respectively: 32 bits: compile time options summary ============================ Host OS : linux-gnu X11 : yes GL : yes glu : no libelf : yes libjpeg : yes libudev : no pthread : yes QT version : none ALSA support : yes SDL support : yes build dynamic libs : yes build static libs : no gconv : no dynamic libv4l : yes v4l_plugins : yes v4l_wrappers : yes libdvbv5 : no dvbv5-daemon : no v4lutils : no qv4l2 : no qvidcap : no v4l2-ctl uses libv4l : yes v4l2-compliance uses libv4l: yes BPF IR Decoders: : yes 64 bits: compile time options summary ============================ Host OS : linux-gnu X11 : yes GL : yes glu : yes libelf : yes libjpeg : yes libudev : yes pthread : yes QT version : v5.4 with QtGL ALSA support : yes SDL support : yes build dynamic libs : yes build static libs : no gconv : no dynamic libv4l : yes v4l_plugins : yes v4l_wrappers : yes libdvbv5 : yes dvbv5-daemon : yes v4lutils : no qv4l2 : no qvidcap : no v4l2-ctl uses libv4l : yes v4l2-compliance uses libv4l: yes BPF IR Decoders: : yes The difference was on lines with glu and libudev. Both were compiled with abi32 but I think it might be related to the change lib32 to lib, both packages were installed before I migrated with the lib. After the reinstalling of glu and eudev the sumamry log for abi 32 looks, beside qt, like for abi64: compile time options summary ============================ Host OS : linux-gnu X11 : yes GL : yes glu : yes libelf : yes libjpeg : yes libudev : yes pthread : yes QT version : none ALSA support : yes SDL support : yes build dynamic libs : yes build static libs : no gconv : no dynamic libv4l : yes v4l_plugins : yes v4l_wrappers : yes libdvbv5 : yes dvbv5-daemon : yes v4lutils : no qv4l2 : no qvidcap : no v4l2-ctl uses libv4l : yes v4l2-compliance uses libv4l: yes BPF IR Decoders: : yes Check your summary, recompile packages which are not found in 32 bit abi and see whether it helps.
It's blocking the last phase of 17.1 migration here, i can't emerge -1v --deep /lib32 /usr/lib32 Because of this. And also because of emerge ignoring --keep-going :-(
(In reply to Thomas Capricelli from comment #15) > It's blocking the last phase of 17.1 migration here, i can't > > emerge -1v --deep /lib32 /usr/lib32 > > Because of this. And also because of emerge ignoring --keep-going :-( I was able to get around this by specifying all of the other packages and doing them first and then doing media-libs/libv4l last and it merged for me finally. Maybe trying doing it the above command you wrote and specifying --exclude=media-libs/libv4l or something?
You can go through it, indeed, by emerging 'by hand' (emerge -1) relevant packages (such as sys-fs/eudev, media-libs/glu or media-libs/libsdl2) Some, like libdvbv5, i cant find what they are, but you dont have to worry about them.
(In reply to Thomas Capricelli from comment #15) > It's blocking the last phase of 17.1 migration here Sorry, I didn't know it is this severe. I still haven't got my hands on this one. I doubt I'll have time to address this sooner than 1 week from now. Meanwhile, patches and pull requests are welcome, and fellow Gentoo developers are welcome to push sensible changes for this package.
Version bump to 1.16.3, which was in February, has added multilib aspect to libudev dependency. --- libv4l-1.14.1.ebuild 2018-07-25 20:09:11.532774864 +0100 +++ libv4l-1.16.3.ebuild 2019-06-17 18:11:28.191110240 +0100 -# The libraries only link to -ljpeg, therefore multilib depend only for virtual/jpeg. RDEPEND="jpeg? ( >=virtual/jpeg-0-r2:0=[${MULTILIB_USEDEP}] ) - virtual/libudev + virtual/libudev[${MULTILIB_USEDEP}] libdvbv5 compilation (and headers installation) is dependent only on libudev presence, according to upstream's configure.ac. I don't understand at the moment how this issue could reproduce exactly because of libdvbv5 headers with version 1.16.3 or higher, without user using some explicit options like --nodeps to make Portage install libv4l package with abi_x86_32 while its dependency, libudev, was not yet installed with abi_x86_32. I see that configure options control is almost non-existent in this ebuild, but rather than pursue perfection, I want to see what is the specific impediment current state of things imposes on users. I would appreciate if people who experience this problem or have retained their failure logs, share them in its entirety. Otherwise I am going to close this ticket soon as resolved.
(In reply to Andrey Utkin from comment #19) > Otherwise I am going to close this ticket soon as resolved. ... opening a different ticket, about the need to track all possible dependencies which are not currently tracked in libv4l ebuild. E.g. X11 and many others. For example, removing X11 from the system will definitely break graphical utilities installed, but there's no dep declared, so Portage would not prevent user from doing that.
Raised follow-up task for myself, https://bugs.gentoo.org/691066 Closing this one - to make any change on this one I'd need active feedback from somebody experiencing this issue now.
I still experience the problem right now, I think. Libv4l complains about missing libudev. virtual/libudev is installed on my system. If I look inside that ebuild it is dependent on either systemd on systemd profiles, or on >=sys-fs/udev-232:0/0 on systems without systemd. But... does that make any sense??? On my system, I can't emerge udev, as eudev blocks it. And I believe I need eudev, NOT udev. Also, why can I emerge virtual/libudev without it installing the underlying deps? neither systemd nor udev are installed on my system. Is this making sense to anybody? Regardless of the possible faulty virtual/libudev I'm now trying if manually reemerging eudev fixes anything for me...
Yes, as it turns out reemerging eudev fixed it for me, so there is a problem with virtual/libudev as it doesn't force eudev to get reinstalled, only udev, which would break things and/or is a blocker for me.
