packaging February 2022

packaging@lists.fedoraproject.org

16 participants
16 discussions

Automatic virtual provides for RPM macros?
by Miro Hrončok 10 Mar '23

10 Mar '23

Hello, today at Nest, somebody said "unfortunately, there is no way to tell what package to install to get a particular RPM macro". I think that having an RPM provides generator for "rpm-macro(__python3)" or similar should be a fairly simple exercise. Would you folks consider that useful? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 4

RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
by Ben Cotton 13 Aug '22

13 Aug '22

https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog… == Summary == redhat-rpm-config will be updated so users of the auto framework get automated release and changelog bumping. == Owner == * Name: [[User:nim| Nicolas Mailhot]] * Email: <nicolas.mailhot at laposte.net> == Detailed Description == This is a system-wide change because all packages build with redhat-rpm-config, but it only concerns packages that opted to use this part of redhat-rpm-config (auto framework). The change will make those packages auto-bump and auto-changelog at the rpm level, in an infrastructure-independent way. == Benefit to Fedora == Autobumping removes a huge packager shore and makes timestamping in changelogs more reliable. == Scope == * Proposal owners: The feature is coded and works at the rpm level. Unfortunately, mock filters away the srpms containing the bump state, so it does not work in upper layers. * Other developers: The feature requires buy-in by mock developers (and probably koji developers) to lift the restrictions that block it above the rpm level. Also, it requires a mechanism to pass the user name and email that will be used in bumped changelogs (defining two variables in ~/.rpmmacros is sufficient at rpm level) * Mock issue: https://github.com/rpm-software-management/mock/issues/599 * Release engineering: https://pagure.io/releng/issue/9567 * Policies and guidelines: maybe eventually if things work out on the technical level * FPC issue: https://pagure.io/packaging-committee/issue/998 * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This is a pure build tooling update, it changes how things are built not what is built. == How To Test == A redhat-rpm-config packages with the changes and some example packages are available in https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-… Since the mock/copr layer is currently blocking the feature, you need to install the redhat-rpm-config and forge macro packages available in this repo locally. Afterwards you can take any of the example packages in the repo and rebuild them with rpmbuild -ba to your heart content, and see the releases bump and the changelogs being updated accordingly. To get beautiful changelogs, you also need to add <pre> %buildsys_name Your name %buildsys_email Your email </pre> in ~/.rpmmacros == User Experience == N/A Packager experience change only == Dependencies == The change is a spin-off of https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macro… Therefore, it depends on the success of that other change and will probably need rebasing if the code in this other change evolves during the redhat-rpm-config merge. It also depends on mock / copr/ koji buy-in and changes, that may add their own requirements. == Contingency Plan == There is no contingency plan because the change will happen or not at all. == Documentation == There is as much documentation as the average redhat-rpm-config change (ie comments in the macro files themselves) == Release Notes == N/A Packager productivity change only -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

12 23

Requesting an epel8 branch
by Brad Bell 11 Mar '22

11 Mar '22

How does one request an epel9 branch for an existing project that has an epel8 branch ?

4 4

Problem Compiling yabridge 3.8.0: error: invalid conversion from 'uint32_t*' {aka 'unsigned int*'} to 'LPDWORD' {aka 'long unsigned int*'
by Martin Gansser 25 Feb '22

25 Feb '22

Hi, I am trying to compile [1] yabridge 3.8.0 on Fedora 35, but I get the following error message: [22/35] wineg++ -Isrc/wine-host/libhost_common_32bit.a.p -Isrc/wine-host -I../src/wine-host -I../src/include -Isrc/common/config -I../src/common/config -I../subprojects/bitsery/include -I../subprojects/function2/include -I../subprojects/tomlplusplus/include -I/usr/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Wpedantic -std=c++2a -O3 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -msse2 -DRELEASE=1 -m32 -malign-double -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_ALL_NO_LIB -isystem../subprojects/vst3 -isystemsubprojects/vst3 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ASIO_DISABLE_CONCEPTS -DBOOST_POSIX_HAS_VFORK=1 -msse2 -DWITH_BITBRIDGE -DWITH_VST3 -DNOMINMAX -D__WINE_WINSOCKAPI_STDLIB_H -D_WINSOCKAPI_ -D__IFileOperation_INTERFACE_DEFINED__ -D__WINE_SAL_H__ -m32 -malign-double -MD -MQ src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -MF src/wine-host/libhost_common_32bit.a.p /meson-generated_host_common_32bit-unity0.cpp.o.d -o src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -c src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp FAILED: src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o wineg++ -Isrc/wine-host/libhost_common_32bit.a.p -Isrc/wine-host -I../src/wine-host -I../src/include -Isrc/common/config -I../src/common/config -I../subprojects/bitsery/include -I../subprojects/function2/include -I../subprojects/tomlplusplus/include -I/usr/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Wpedantic -std=c++2a -O3 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -msse2 -DRELEASE=1 -m32 -malign-double -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_ALL_NO_LIB -isystem../subprojects/vst3 -isystemsubprojects/vst3 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ASIO_DISABLE_CONCEPTS -DBOOST_POSIX_HAS_VFORK=1 -msse2 -DWITH_BITBRIDGE -DWITH_VST3 -DNOMINMAX -D__WINE_WINSOCKAPI_STDLIB_H -D_WINSOCKAPI_ -D__IFileOperation_INTERFACE_DEFINED__ -D__WINE_SAL_H__ -m32 -malign-double -MD -MQ src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -MF src/wine-host/libhost_common_32bit.a.p/meson-g enerated_host_common_32bit-unity0.cpp.o.d -o src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -c src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp In file included from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:13: /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/xdnd-proxy.cpp: In function 'void dnd_winevent_callback(HWINEVENTHOOK, DWORD, HWND, LONG, LONG, DWORD, DWORD)': /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/xdnd-proxy.cpp:756:36: error: invalid conversion from 'uint32_t*' {aka 'unsigned int*'} to 'LPDWORD' {aka 'long unsigned int*'} [-fpermissive] 756 | GetWindowThreadProcessId(hwnd, &process_id); | ^~~~~~~~~~~ | | | uint32_t* {aka unsigned int*} In file included from /usr/include/wine/windows/windows.h:40, from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/../utils.h:26, from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.h:24, from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.cpp:17, from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:9: /usr/include/wine/windows/winuser.h:3953:61: note: initializing argument 2 of 'DWORD GetWindowThreadProcessId(HWND, LPDWORD)' 3953 | WINUSERAPI DWORD WINAPI GetWindowThreadProcessId(HWND,LPDWORD); | ^~~~~~~ In file included from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:13: /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/xdnd-proxy.cpp:793:22: error: invalid conversion from 'unsigned int*' to 'ULONG*' {aka 'long unsigned int*'} [-fpermissive] 793 | &num_formats); | ^~~~~~~~~~~~ | | | unsigned int* In file included from /usr/include/wine/windows/objbase.h:262, from /usr/include/wine/windows/ole2.h:25, from /usr/include/wine/windows/wtypes.h:13, from /usr/include/wine/windows/winscard.h:22, from /usr/include/wine/windows/windows.h:67, from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/../utils.h:26, from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.h:24, from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.cpp:17, from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:9: /usr/include/wine/windows/objidl.h:9511:16: note: initializing argument 3 of 'virtual HRESULT IEnumFORMATETC::Next(ULONG, FORMATETC*, ULONG*)' 9511 | ULONG *pceltFetched) = 0; | ~~~~~~~^~~~~~~~~~~~ winegcc: /usr/bin/g++ failed ninja: build stopped: subcommand failed. [1] https://martinkg.fedorapeople.org/ErrorReports/yabridge/yabridge.spec Is there any solution, how can I solve this ? Regards Martin

2 2

EPEL8 build problem
by Steve Cossette 24 Feb '22

24 Feb '22

Good morning... I was trying to mockbuild a package for epel8 this morning, and got an error message that seems to have to do less with my build and more of (maybe?) a bigger problem: Start: dnf update No matches found for the following disable plugin patterns: local, spacewalk, versionlock CentOS Stream 8 - BaseOS 19 kB/s | 3.9 kB 00:00 CentOS Stream 8 - AppStream 1.9 kB/s | 4.4 kB 00:02 CentOS Stream 8 - AppStream 9.8 MB/s | 20 MB 00:02 CentOS Stream 8 - Extras 13 kB/s | 3.0 kB 00:00 CentOS Stream 8 - PowerTools 9.0 kB/s | 4.4 kB 00:00 Extra Packages for Enterprise Linux 8 - x86_64 20 kB/s | 4.7 kB 00:00 Error: Problem: problem with installed package rpm-build-4.14.3-21.el8.x86_64 - cannot install the best update candidate for package rpm-build-4.14.3-21.el8.x86_64 - nothing provides rpm = 4.14.3-22.el8 needed by rpm-build-4.14.3-22.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) ERROR: Exception(/home/farchord/build/lutris/lutris/lutris-0.5.9.1-4.el8.src.rpm) Config(centos-stream+epel-8-x86_64) 0 minutes 11 seconds INFO: Results and/or logs in: /home/farchord/build/lutris/lutris/results_lutris/0.5.9.1/4.el8 INFO: Cleaning up build root ('cleanup_on_failure=True') Start: clean chroot Finish: clean chroot ERROR: Command failed: # /usr/bin/systemd-nspawn -q -M 5bc8223ee6104692a8cb1c3aa3b2cf25 -D /var/lib/mock/centos-stream+epel-8-x86_64-bootstrap/root -a --capability=cap_ipc_lock --bind=/tmp/mock-resolv.e_p6y9ke:/etc/resolv.conf --console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/var/lib/mock/centos-stream+epel-8-x86_64/root/installation-homedir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$ --setenv=LANG=C.UTF-8 --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf --installroot /var/lib/mock/centos-stream+epel-8-x86_64/root/ -y --releasever 8 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock update --setopt=tsflags=nocontexts Could not execute mockbuild: Failed to execute command. Anyone know about this? Thank you.

1 1

Packaging for EPEL9 question
by Steve Cossette 23 Feb '22

23 Feb '22

Hello, So I am working on building for EPEL9 from fedora 35, but mock was complaining it had no config file for epel9. So I created a symlink: epel-9-x86_64.cfg -> /etc/mock/centos-stream+epel-9-x86_64.cfg I was looking in the doc files and couldn't find any documentation on this, is this correct? Thank you.

2 1

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
by Sérgio Basto 19 Feb '22

19 Feb '22

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.in#… > > > > %{?_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.

1 1

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
by Miro Hrončok 17 Feb '22

17 Feb '22

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.in#… %{?_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

2 2

Schedule for Thursday's FPC Meeting (2022-02-17 17:00 UTC)
by James Antill 16 Feb '22

16 Feb '22

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2022-02-17 17:00 UTC in #fedora-meeting-1 on irc.libera.chat. Local time information (via. uitime): ================= Day: Thursday ================== 2022-02-17 09:00 PST US/Pacific 2022-02-17 12:00 EST --> US/Eastern <-- 2022-02-17 17:00 GMT Europe/London 2022-02-17 17:00 UTC UTC 2022-02-17 18:00 CET Europe/Berlin 2022-02-17 18:00 CET Europe/Paris 2022-02-17 22:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2022-02-18 01:00 HKT Asia/Hong_Kong 2022-02-18 01:00 +08 Asia/Singapore 2022-02-18 02:00 JST Asia/Tokyo 2022-02-18 03:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followup Actions = #topic #pr-814 * mhroncok talk to authors again, having a working example might help a lot = Followup Issues = #topic #886 Enable BRP for detecting RPATH .fpc 886 https://pagure.io/packaging-committee/issue/886 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #1058 How to handle %lang files in package owned directories? .fpc 1058 https://pagure.io/packaging-committee/issue/1058 #topic #1132 Mark comments as scriplets for Sources (automation) .fpc 1132 https://pagure.io/packaging-committee/issue/1132 #topic #1150 request for clarification wrt. base version / compat package naming .fpc 1150 https://pagure.io/packaging-committee/issue/1150 #topic #1159 Ban use of %configure in %prep .fpc 1159 https://pagure.io/packaging-committee/issue/1159 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 #topic #pr-1045 WIP: Add discussion of macro names beginning with underscores. https://pagure.io/packaging-committee/pull-request/1045 #topic #pr-1046 Improve separate test suite sourcing instructions https://pagure.io/packaging-committee/pull-request/1046 #topic #pr-1071 Overhaul the RPATH section of the guidelines. https://pagure.io/packaging-committee/pull-request/1071 #topic #pr-1097 Use caret in Obsoletes to simplify https://pagure.io/packaging-committee/pull-request/1097 #topic #pr-1144 Weak deps. on subpkgs. MUST NOT be fully versioned https://pagure.io/packaging-committee/pull-request/1144 #topic #pr-1157 Drop redundant Source and Patch numbers https://pagure.io/packaging-committee/pull-request/1157 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

1 0

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
by Miro Hrončok 15 Feb '22

15 Feb '22

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

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2022