Re: Conflicting build-ids in chromium and chromium-freeworld
On 2020-09-21 12:08, Mark Wielaard wrote: > Hi, > > On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote: >> On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: >>> Hi. There is an ongoing problem with conflicting build-ids in chromium >>> and chromium-freeworld [1][2]: >>>> Error: Transaction test error: >>>>file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>>>file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from >>>> install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with >>>> file from package chromium-85.0.4183.102-1.fc32.x86_64 >>> >>> There is no clear idea why it happens, but my assumption is that due to >>> the fact of building with the same source code (with similar patches), >>> some generated shared libraries are the same which generates conflict(s). > > The error message could probably be improved. > You might want to look at where the /usr/lib/.build-id/xx/ symlinks > are pointing at to get a better idea which binaries are identical > between the packages. > >>> The quick look at the algorithm for build-id generation [3] doesn't >>> answer my question what exactly is taken into account for their >>> generation and more precisely is there is way to add some "fuzz" (having >>> different buildroots doesn't help) to distinguish those libraries. > > The build-id is calculated over all relevant build environment bits (by > the linker, not rpm). This includes the debuginfo in the original (not > split) ELF file. The debuginfo contains the build paths (which should > be different for different NVRs and include the compiler version and > flags). This really should prevent identical build-ids whenever > something is really build from source. Normally you only get identical > build-ids when building the same source code in the same package with > the same compiler flags. Identical build-ids between packages are > really very rare and are often caused by some binary blob simply being > copied between packages (is there a blob in the upstream tar ball that > isn't build from source?) or if debuginfo (-g) is missing. > >>> To wrap up: >>> 1. Is there a better way to deal with the aforementioned build-id >>> conflicts than disable their generation on one side (with "%global >>> _build_id_links none")? >> >> Instead of disabling entirely, you could tell rpm to put it all into >> -debuginfo packages (ie the original debuginfo layout). Which would >> still conflict, but fewer people are affected: >> >> %global _build_id_links alldebug > > Yes, that is a much better workaround than using none. It sounds very sensible :). Especially, as a workaround, in the situation that solving issues with duplicated shared libraries between packages was problematic. Thanks you guys for suggestions. Marcin > >>> 2. Maybe my assumption about the same generated shared libraries is >>> wrong and there is something else what can be done to fix the root problem? >> >> That's exactly the cause, build-id's are engineered to reproducably >> identify identical built objects, regardless of their location. Which >> causes conflicts when the house rules of not shipping multiple idental >> copies is broken (one might call this a feature). > > Yes, I would call this a feature :) > >> Short of unbundling the shared libraries, I guess a reasonable >> workaround would be patching them to include some identifier string >> based on the containing package name, which would cause them to have >> different build_ids. > > If build from source and building with debuginfo that should already be > the case because the build-id is calculated o
Re: Conflicting build-ids in chromium and chromium-freeworld
Le lun. 21 sept. 2020 à 12:08, Mark Wielaard a écrit : > > Hi, > > On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote: > > On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: > > > Hi. There is an ongoing problem with conflicting build-ids in chromium > > > and chromium-freeworld [1][2]: > > > > Error: Transaction test error: > > > >file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > > > > There is no clear idea why it happens, but my assumption is that due to > > > the fact of building with the same source code (with similar patches), > > > some generated shared libraries are the same which generates conflict(s). > > The error message could probably be improved. > You might want to look at where the /usr/lib/.build-id/xx/ symlinks > are pointing at to get a better idea which binaries are identical > between the packages. > > > > The quick look at the algorithm for build-id generation [3] doesn't > > > answer my question what exactly is taken into account for their > > > generation and more precisely is there is way to add some "fuzz" (having > > > different buildroots doesn't help) to distinguish those libraries. > > The build-id is calculated over all relevant build environment bits (by > the linker, not rpm). This includes the debuginfo in the original (not > split) ELF file. The debuginfo contains the build paths (which should > be different for different NVRs and include the compiler version and > flags). This really should prevent identical build-ids whenever > something is really build from source. Normally you only get identical > build-ids when building the same source code in the same package with > the same compiler flags. Identical build-ids between packages are > really very rare and are often caused by some binary blob simply being > copied between packages (is there a blob in the upstream tar ball that > isn't build from source?) or if debuginfo (-g) is missing. Hello Mark, thanks for confirming that case. (buildID conflict might be caused by binaries not built from sources) The suspected files are the following: (same for the fedora version). lrwxrwxrwx. 1 root root 55 11 sept. 18:54 /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b -> ../../../../usr/lib64/chromium-freeworld/chrome-sandbox lrwxrwxrwx. 1 root root 65 11 sept. 18:54 /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee -> ../../../../usr/lib64/chromium-freeworld/swiftshader/libGLESv2.so lrwxrwxrwx. 1 root root 53 11 sept. 18:54 /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 -> ../../../../usr/lib64/chromium-freeworld/libGLESv2.so lrwxrwxrwx. 1 root root 62 11 sept. 18:54 /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 -> ../../../../usr/lib64/chromium-freeworld/swiftshader/libEGL.so lrwxrwxrwx. 1 root root 50 11 sept. 18:54 /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea -> ../../../../usr/lib64/chromium-freeworld/libEGL.so There is indeed a need to fix this on both sides. Thanks for your input. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Conflicting build-ids in chromium and chromium-freeworld
Hi, On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote: > On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: > > Hi. There is an ongoing problem with conflicting build-ids in chromium > > and chromium-freeworld [1][2]: > > > Error: Transaction test error: > > >file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from > > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with > > > file from package chromium-85.0.4183.102-1.fc32.x86_64 > > >file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from > > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with > > > file from package chromium-85.0.4183.102-1.fc32.x86_64 > > >file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from > > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with > > > file from package chromium-85.0.4183.102-1.fc32.x86_64 > > >file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from > > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with > > > file from package chromium-85.0.4183.102-1.fc32.x86_64 > > >file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from > > > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with > > > file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > > There is no clear idea why it happens, but my assumption is that due to > > the fact of building with the same source code (with similar patches), > > some generated shared libraries are the same which generates conflict(s). The error message could probably be improved. You might want to look at where the /usr/lib/.build-id/xx/ symlinks are pointing at to get a better idea which binaries are identical between the packages. > > The quick look at the algorithm for build-id generation [3] doesn't > > answer my question what exactly is taken into account for their > > generation and more precisely is there is way to add some "fuzz" (having > > different buildroots doesn't help) to distinguish those libraries. The build-id is calculated over all relevant build environment bits (by the linker, not rpm). This includes the debuginfo in the original (not split) ELF file. The debuginfo contains the build paths (which should be different for different NVRs and include the compiler version and flags). This really should prevent identical build-ids whenever something is really build from source. Normally you only get identical build-ids when building the same source code in the same package with the same compiler flags. Identical build-ids between packages are really very rare and are often caused by some binary blob simply being copied between packages (is there a blob in the upstream tar ball that isn't build from source?) or if debuginfo (-g) is missing. > > To wrap up: > > 1. Is there a better way to deal with the aforementioned build-id > > conflicts than disable their generation on one side (with "%global > > _build_id_links none")? > > Instead of disabling entirely, you could tell rpm to put it all into > -debuginfo packages (ie the original debuginfo layout). Which would > still conflict, but fewer people are affected: > > %global _build_id_links alldebug Yes, that is a much better workaround than using none. > > 2. Maybe my assumption about the same generated shared libraries is > > wrong and there is something else what can be done to fix the root problem? > > That's exactly the cause, build-id's are engineered to reproducably > identify identical built objects, regardless of their location. Which > causes conflicts when the house rules of not shipping multiple idental > copies is broken (one might call this a feature). Yes, I would call this a feature :) > Short of unbundling the shared libraries, I guess a reasonable > workaround would be patching them to include some identifier string > based on the containing package name, which would cause them to have > different build_ids. If build from source and building with debuginfo that should already be the case because the build-id is calculated over the original debuginfo which contains the original (pre-debugedit) build paths, which should contain the package nvr in their name. So double check that things are build with -g. Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Conflicting build-ids in chromium and chromium-freeworld
On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: Hi. There is an ongoing problem with conflicting build-ids in chromium and chromium-freeworld [1][2]: Error: Transaction test error: file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 There is no clear idea why it happens, but my assumption is that due to the fact of building with the same source code (with similar patches), some generated shared libraries are the same which generates conflict(s). The quick look at the algorithm for build-id generation [3] doesn't answer my question what exactly is taken into account for their generation and more precisely is there is way to add some "fuzz" (having different buildroots doesn't help) to distinguish those libraries. To wrap up: 1. Is there a better way to deal with the aforementioned build-id conflicts than disable their generation on one side (with "%global _build_id_links none")? Instead of disabling entirely, you could tell rpm to put it all into -debuginfo packages (ie the original debuginfo layout). Which would still conflict, but fewer people are affected: %global _build_id_links alldebug 2. Maybe my assumption about the same generated shared libraries is wrong and there is something else what can be done to fix the root problem? That's exactly the cause, build-id's are engineered to reproducably identify identical built objects, regardless of their location. Which causes conflicts when the house rules of not shipping multiple idental copies is broken (one might call this a feature). Short of unbundling the shared libraries, I guess a reasonable workaround would be patching them to include some identifier string based on the containing package name, which would cause them to have different build_ids. - Panu - [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1869037 [2] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5743 [3] - https://github.com/rpm-software-management/rpm/blob/505fe16f863f83637c9577417a7ae959df674a61/build/files.c#L1803 [4] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5758 Marcin P.S. There are cases where it would be best to have those two packages installed simultaneously [4]. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Conflicting build-ids in chromium and chromium-freeworld
Hi. There is an ongoing problem with conflicting build-ids in chromium and chromium-freeworld [1][2]: > Error: Transaction test error: > file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 There is no clear idea why it happens, but my assumption is that due to the fact of building with the same source code (with similar patches), some generated shared libraries are the same which generates conflict(s). The quick look at the algorithm for build-id generation [3] doesn't answer my question what exactly is taken into account for their generation and more precisely is there is way to add some "fuzz" (having different buildroots doesn't help) to distinguish those libraries. To wrap up: 1. Is there a better way to deal with the aforementioned build-id conflicts than disable their generation on one side (with "%global _build_id_links none")? 2. Maybe my assumption about the same generated shared libraries is wrong and there is something else what can be done to fix the root problem? [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1869037 [2] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5743 [3] - https://github.com/rpm-software-management/rpm/blob/505fe16f863f83637c9577417a7ae959df674a61/build/files.c#L1803 [4] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5758 Marcin P.S. There are cases where it would be best to have those two packages installed simultaneously [4]. -- https://blog.solidsoft.pl/ - Working code is not enough ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
