Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64
7:11 a.m.
Hey,
apparently some ELF files are identical between Fedora's pypy3.7-libs and
pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error:
file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel list, but I
still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given it's not
"two packages bundle the same thing" but rather "two packages built in a
different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.i...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
What are the side effects for changing the seed like this?:
%global __debug_install_post \
%{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-seed%s+"',
rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a macro I could
redefine in a less cryptic and fragile way?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3:34 a.m.
New subject: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64
and pypy3.8-libs-7.3.7-1.fc34.x86_64
The time had to come, when two packages would generate the same hash.
I was hit by:
---
Error: Transaction test error:
file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64
and skypeforlinux-8.79.0.95-1.x86_64
---
some time ago but since neither is a package maintained by Fedora
Project maintainers, no one gave a damn about the core of the issue.
That time, I got one of the apps as a Flatpak instead, but not all
packages have such workarounds at hand.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
Hey,
apparently some ELF files are identical between Fedora's pypy3.7-libs and
pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error:
file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel list, but I
still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given it's not
"two packages bundle the same thing" but rather "two packages built in a
different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.i...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
What are the side effects for changing the seed like this?:
%global __debug_install_post \
%{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-seed%s+"',
rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a macro I could
redefine in a less cryptic and fragile way?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
5:28 a.m.
On Mon, 2022-02-14 at 10:34 +0100, Michal Schorm wrote:
The time had to come, when two packages would generate the same
hash.
I was hit by:
---
Error: Transaction test error:
file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64
and skypeforlinux-8.79.0.95-1.x86_64
---
some time ago but since neither is a package maintained by Fedora
Project maintainers, no one gave a damn about the core of the issue.
That time, I got one of the apps as a Flatpak instead, but not all
packages have such workarounds at hand.
yeah , thank you for reminder these cases (with electron apps)
we fixed with `%global debug_package %{nil}`
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok <mhroncok(a)redhat.com>
wrote:
>
> Hey,
> apparently some ELF files are identical between Fedora's pypy3.7-
> libs and
> pypy3.8-libs packages.
>
> On Fedora 34, this leads to installation conflict:
>
> Error: Transaction test error:
> file /usr/lib/.build-
> id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
> file /usr/lib/.build-
> id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
> file /usr/lib/.build-
> id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
> file /usr/lib/.build-
> id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
> file /usr/lib/.build-
> id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
> file /usr/lib/.build-
> id/c9/e94d839699198b0e87c334f8e03160fec054de from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
> file /usr/lib/.build-
> id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
> file /usr/lib/.build-
> id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
> file /usr/lib/.build-
> id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
> install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> from package
> pypy3.8-libs-7.3.7-1.fc34.x86_64
>
> As reported in https://bugzilla.redhat.com/2053880
>
> I've read all the previous discussion about this on Fedora devel
> list, but I
> still have no idea what should I do to prevent this conflict.
>
> Moving the files to a common component seems like a bad idea given
> it's not
> "two packages bundle the same thing" but rather "two packages built
> in a
> different way".
>
> I see this:
>
> https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.i...
>
> %{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
>
> I suppose I could pass in %{NAME} as well, right?
>
> What are the side effects for changing the seed like this?:
>
> %global __debug_install_post \
>
> %{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-
> id%-seed%s+"',
> rpm.expand('--build-id-seed "%{NAME}-')))}
>
>
> Actually, should RPM pass %{NAME} by default? Or at least have a
> macro I could
> redefine in a less cryptic and fragile way?
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Sérgio M. B.
9:28 a.m.
On Mon, 2022-02-14 at 11:28 +0000, Sérgio Basto wrote:
On Mon, 2022-02-14 at 10:34 +0100, Michal Schorm wrote:
> The time had to come, when two packages would generate the same
> hash.
>
> I was hit by:
> ---
> Error: Transaction test error:
> file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
> conflicts between attempted installs of discord-0.0.16-
> 1.fc35.x86_64
> and skypeforlinux-8.79.0.95-1.x86_64
> ---
> some time ago but since neither is a package maintained by Fedora
> Project maintainers, no one gave a damn about the core of the
> issue.
> That time, I got one of the apps as a Flatpak instead, but not all
> packages have such workarounds at hand.
yeah , thank you for reminder these cases (with electron apps)
we fixed with `%global debug_package %{nil}`
is fixed with %global _build_id_links none
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
>
> On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok <mhroncok(a)redhat.com>
> wrote:
> >
> > Hey,
> > apparently some ELF files are identical between Fedora's pypy3.7-
> > libs and
> > pypy3.8-libs packages.
> >
> > On Fedora 34, this leads to installation conflict:
> >
> > Error: Transaction test error:
> > file /usr/lib/.build-
> > id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/c9/e94d839699198b0e87c334f8e03160fec054de from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> >
> > As reported in https://bugzilla.redhat.com/2053880
> >
> > I've read all the previous discussion about this on Fedora devel
> > list, but I
> > still have no idea what should I do to prevent this conflict.
> >
> > Moving the files to a common component seems like a bad idea
> > given
> > it's not
> > "two packages bundle the same thing" but rather "two packages
> > built
> > in a
> > different way".
> >
> > I see this:
> >
> >
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.i...
> >
> > %{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
> >
> > I suppose I could pass in %{NAME} as well, right?
> >
> > What are the side effects for changing the seed like this?:
> >
> > %global __debug_install_post \
> >
> > %{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-
> > id%-seed%s+"',
> > rpm.expand('--build-id-seed "%{NAME}-')))}
> >
> >
> > Actually, should RPM pass %{NAME} by default? Or at least have a
> > macro I could
> > redefine in a less cryptic and fragile way?
> >
> > --
> > Miro Hrončok
> > --
> > Phone: +420777974800
> > IRC: mhroncok
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to
> > devel-leave(a)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
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
Sérgio M. B.
10:10 a.m.
New subject: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64
Michal Schorm wrote:
The time had to come, when two packages would generate the same hash.
Well, yes, depending on hash codes being globally unique is broken by
design. Hash collisions exist. They can happen both by accident (because
hash functions cannot possibly be injective because the range is smaller
than the domain) and by design (when really the same binary is compiled
under the same conditions twice, or even a binary from a third party is
bundled by multiple proprietary RPMs, which I suspect is what happened for
discord and skypeforlinux).
The build-id concept needs to be completely redesigned to not rely on hash
codes. We should go by file name or even package EVR + file name (as a
complete string, not hashed) instead. (In fact, that used to be how things
worked before build-ids were introduced, and there were never any issues
with that approach.)
Kevin Kofler
3:33 a.m.
On 14. 02. 22 10:34, Michal Schorm wrote:
The time had to come, when two packages would generate the same
hash.
I was hit by:
---
Error: Transaction test error:
file/usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64
and skypeforlinux-8.79.0.95-1.x86_64
---
some time ago but since neither is a package maintained by Fedora
Project maintainers, no one gave a damn about the core of the issue.
That time, I got one of the apps as a Flatpak instead, but not all
packages have such workarounds at hand.
That's because they both ship the same electron binary.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:31 a.m.
New subject: [Fedora-packaging] Re: Preventing .build-id file conflicts
between pypy3.7-libs-7.3.7-1.fc34.x86_64 and
pypy3.8-libs-7.3.7-1.fc34.x86_64
On Tue, 2022-02-15 at 10:33 +0100, Miro Hrončok wrote:
On 14. 02. 22 10:34, Michal Schorm wrote:
> The time had to come, when two packages would generate the same
> hash.
>
> I was hit by:
> ---
> Error: Transaction test error:
> file/usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
> conflicts between attempted installs of discord-0.0.16-
> 1.fc35.x86_64
> and skypeforlinux-8.79.0.95-1.x86_64
> ---
> some time ago but since neither is a package maintained by Fedora
> Project maintainers, no one gave a damn about the core of the
> issue.
> That time, I got one of the apps as a Flatpak instead, but not all
> packages have such workarounds at hand.
That's because they both ship the same electron binary.
Right , so ? two package can't ship the same binary on Fedora ?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
packaging mailing list -- packaging(a)lists.fedoraproject.org
To unsubscribe send an email to
packaging-leave(a)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/packaging@lists.fedoraproje...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Sérgio M. B.
8:46 a.m.
New subject: [Fedora-packaging] Re: Preventing .build-id file conflicts
between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64
On 15. 02. 22 15:31, Sérgio Basto wrote:
On Tue, 2022-02-15 at 10:33 +0100, Miro Hrončok wrote:
> On 14. 02. 22 10:34, Michal Schorm wrote:
>> The time had to come, when two packages would generate the same
>> hash.
>>
>> I was hit by:
>> ---
>> Error: Transaction test error:
>> file/usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
>> conflicts between attempted installs of discord-0.0.16-
>> 1.fc35.x86_64
>> and skypeforlinux-8.79.0.95-1.x86_64
>> ---
>> some time ago but since neither is a package maintained by Fedora
>> Project maintainers, no one gave a damn about the core of the
>> issue.
>> That time, I got one of the apps as a Flatpak instead, but not all
>> packages have such workarounds at hand.
>
> That's because they both ship the same electron binary.
Right , so ? two package can't ship the same binary on Fedora ?
I never said that. What I meant is that that problem is known and I need to
help with a different problem.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:57 a.m.
New subject: [Fedora-packaging] Re: Preventing .build-id file conflicts
between pypy3.7-libs-7.3.7-1.fc34.x86_64 and
pypy3.8-libs-7.3.7-1.fc34.x86_64
On Tue, 2022-02-15 at 15:46 +0100, Miro Hrončok wrote:
On 15. 02. 22 15:31, Sérgio Basto wrote:
> On Tue, 2022-02-15 at 10:33 +0100, Miro Hrončok wrote:
> > On 14. 02. 22 10:34, Michal Schorm wrote:
> > > The time had to come, when two packages would generate the same
> > > hash.
> > >
> > > I was hit by:
> > > ---
> > > Error: Transaction test error:
> > > file/usr/lib/.build-
> > > id/34/feaa549462e8818baa0629ce11da344465882b
> > > conflicts between attempted installs of discord-0.0.16-
> > > 1.fc35.x86_64
> > > and skypeforlinux-8.79.0.95-1.x86_64
> > > ---
> > > some time ago but since neither is a package maintained by
> > > Fedora
> > > Project maintainers, no one gave a damn about the core of the
> > > issue.
> > > That time, I got one of the apps as a Flatpak instead, but not
> > > all
> > > packages have such workarounds at hand.
> >
> > That's because they both ship the same electron binary.
>
> Right , so ? two package can't ship the same binary on Fedora ?
I never said that. What I meant is that that problem is known and I
need to
help with a different problem.
I was being ironic, I didn't want to say that either, sorry.
But I think the root of the problem is the same, .build-id hash be the
same is not a coincidence .
Also we have old bug reports about .build-id hash conflicts , IIRC .
Best regards,
--
Sérgio M. B.
8:48 a.m.
I've realized I've sent this initially to rpm-list-requests and not rpm-list.
Sorry about that.
On 13. 02. 22 14:11, Miro Hrončok wrote:
Hey,
apparently some ELF files are identical between Fedora's pypy3.7-libs and
pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error:
file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel list, but I
still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given it's not
"two packages bundle the same thing" but rather "two packages built in a
different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.i...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
What are the side effects for changing the seed like this?:
%global __debug_install_post \
%{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-seed%s+"',
rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a macro I could
redefine in a less cryptic and fragile way?
Apparently, changing --build-id-seed breaks debugsourcefiles.list:
+ /usr/bin/find-debuginfo -j6 --strict-build-id -m -i --build-id-seed
3.7-7.3.7-5.fc37 --unique-debug-suffix -7.3.7-5.fc37.x86_64
--unique-debug-src-base pypy3.7-7.3.7-5.fc37.x86_64 --run-dwz
--dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 -S
debugsourcefiles.list /builddir/build/BUILD/
extracting debug info from
/builddir/build/BUILDROOT/pypy3.7-7.3.7-5.fc37.x86_64/usr/lib64/pypy3.7/lib_pypy/_curses_cffi.pypy37-pp73-x86_64-linux-gnu.so
extracting debug info from ...
original debug info size: 2616kB, size after compression: 2468kB
/usr/bin/sepdebugcrcfix: Updated 15 CRC32s, 0 CRC32s did match.
6363 blocks
...
Processing files: pypy3.7-debugsource-7.3.7-5.fc37.x86_64
RPM build errors:
error: Could not open %files file
/builddir/build/BUILD/pypy3.7-v7.3.7-src/debugsourcefiles.list: No such file or
directory
Could not open %files file
/builddir/build/BUILD/pypy3.7-v7.3.7-src/debugsourcefiles.list: No such file or
directory
Is that a bug, or ame I doing something wrong?
That log is from https://src.fedoraproject.org/rpms/pypy3.7/pull-request/16
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:07 a.m.
On Sun, 2022-02-13 at 14:11 +0100, Miro Hrončok wrote:
Hey,
apparently some ELF files are identical between Fedora's pypy3.7-libs
and
pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error:
file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264
from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9
from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c
from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2
from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0
from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de
from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0
from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590
from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6
from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from
package
pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel
list, but I
still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given
it's not
"two packages bundle the same thing" but rather "two packages built
in a
different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.i...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
yes , I like your solution , as talked in previous messages we have a
long historical of .build-id file conflicts , which we should prevent
What are the side effects for changing the seed like this?:
%global __debug_install_post \
%{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-
seed%s+"',
rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a
macro I could
redefine in a less cryptic and fragile way?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Sérgio M. B.
821
days inactive
827
days old
10 comments
4 participants
participants (4)
-
Kevin Kofler -
Michal Schorm -
Miro Hrončok -
Sérgio Basto