[Rpm-maint] [rpm-software-management/rpm] dnf install recommends() ? (Discussion #3154)
Would adding this make sense? I'm not sure under which part of rpm this falls but it'd be great if I could do `dnf install recommends()`. Same for all the other dependency types. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3154 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debugsourcefiles.list is empty since rpm 4.19.91 (Issue #3136)
Closed #3136 as not planned. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3136#event-12996020177 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debugsourcefiles.list is empty since rpm 4.19.91 (Issue #3136)
Nvm It seems I had to nuke my build directory which fixed the issue. I think meson is not correctly propagating changed compilation flags from rpm -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3136#issuecomment-2141390960 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] --build-in-place regression in 4.19.91 (Issue #3135)
Worked around the bug by adding `--define "_fixperms true"` to my rpmbuild call. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3135#issuecomment-2141357164 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debugsourcefiles.list is empty since rpm 4.19.91 (Issue #3136)
Only seems to happen when building with `-O0`. If i use `-Og` as the optimization level, the build succeeds. Maybe this is a bug in debugedit? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3136#issuecomment-2141356329 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debugsourcefiles.list is empty since rpm 4.19.91 (Issue #3136)
Logs when adding `set -x` to the find-debuginfo script: https://gist.github.com/DaanDeMeyer/5b675dddba914ac658d78d7ddd398c8e -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3136#issuecomment-2141342834 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] debugsourcefiles.list is empty since rpm 4.19.91 (Issue #3136)
**Describe the bug**
Since rpm 4.19.91 (and with a workaround for #3135), the mkosi rpm build in
systemd is failing because debugsourcefiles.list is empty. I see that
find-debuginfo is being called and passed `-S debugsourcefiles.list` as
expected, yet the file is still empty after find-debuginfo finishes.
**To Reproduce**
Steps to reproduce the behavior:
```
git clone https://github.com/systemd/systemd
cd systemd
mkosi genkey
mkosi -E WITH_DEBUG=1 -f
```
Please link or attach the packages or spec files involved.
https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec
**Expected behavior**
debugsourcefiles.list is populated with files.
**Output**
```
‣ Running build script
/home/daandemeyer/projects/systemd/mkosi.images/system/mkosi.conf.d/10-centos-fedora/mkosi.build.chroot…
+ (( NO_BUILD ))
+ . /usr/lib/os-release
++ NAME='Fedora Linux'
++ VERSION='41 (Rawhide Prerelease)'
++ ID=fedora
++ VERSION_ID=41
++ VERSION_CODENAME=
++ PLATFORM_ID=platform:f41
++ PRETTY_NAME='Fedora Linux 41 (Rawhide Prerelease)'
++ ANSI_COLOR='0;38;2;60;110;180'
++ LOGO=fedora-logo-icon
++ CPE_NAME=cpe:/o:fedoraproject:fedora:41
++ DEFAULT_HOSTNAME=fedora
++ HOME_URL=https://fedoraproject.org/
++
DOCUMENTATION_URL=https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/
++ SUPPORT_URL=https://ask.fedoraproject.org/
++ BUG_REPORT_URL=https://bugzilla.redhat.com/
++ REDHAT_BUGZILLA_PRODUCT=Fedora
++ REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
++ REDHAT_SUPPORT_PRODUCT=Fedora
++ REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
++ SUPPORT_END=2025-05-13
+ '[' '!' -f pkg/fedora/systemd.spec ']'
+ '[' -d .git/ ']'
++ git status --porcelain
+ '[' -z ' M
mkosi.images/system/mkosi.conf.d/10-centos-fedora/mkosi.build.chroot
M mkosi.images/system/mkosi.conf.d/10-opensuse/mkosi.build.chroot
?? pkg/fedora/' ']'
++ date +%s
+ TS=1717099550
++ rpm --version
++ cut -d ' ' -f3
+ systemd-analyze compare-versions 4.19.91 lt 4.19.91
++ cat meson.version
+ VERSION=256~rc3
++ date +%Y%m%d%H%M%S --date @1717099550
+ RELEASE=20240530200550
++ rpm --eval %dist
+ DIST=.fc41
++ rpm --eval %_arch
+ ARCH=x86_64
+ SRCDEST=/usr/src/debug/systemd-256~rc3-20240530200550.fc41.x86_64
++ rpm --define '_fortify_level 0' --undefine _lto_cflags --eval %build_cflags
+ CFLAGS='-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -O0 -Wp,-U_FORTIFY_SOURCE'
+ (( WITH_DEBUG ))
+ CFLAGS='-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -O0 -Wp,-U_FORTIFY_SOURCE
-fdebug-prefix-map=../src=/usr/src/debug/systemd-256~rc3-20240530200550.fc41.x86_64'
+ IFS=
++ (( WITH_TESTS ))
++ echo --nocheck
++ (( WITH_DOCS ))
++ (( WITH_DEBUG ))
++ (( WITH_DEBUG ))
+ ANNOBIN=no-active-checks
+ rpmbuild -bb --build-in-place --with upstream --nocheck --define '_topdir
/var/tmp' --define '_sourcedir pkg/fedora' --define '_rpmdir /work/out'
'--define=_vpath_builddir /work/build' --define '_build_name_fmt
%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm' --define '_binary_payload
w.ufdio' --define 'version_override 256~rc3' --define 'release_override
20240530200550' --define 'build_cflags -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
-march=x86-64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -mtls-dialect=gnu2
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -O0 -Wp,-U_FORTIFY_SOURCE
-fdebug-prefix-map=../src=/usr/src/debug/systemd-256~rc3-20240530200550.fc41.x86_64'
--define 'meson_build %{shrink:%{__meson} compile -C %{_vpath_builddir} -j
%{_smp_build_ncpus} %{nil}}' --define 'meson_install
%{shrink:DESTDIR=%{buildroot} %{__meson} install -C %{_vpath_builddir}
--no-rebuild --quiet %{nil}}' --define 'meson_extra_configure_options -D
mode=developer -D b_sanitize=none' --define '__brp_compress %{nil}' --define
'__brp_mangle_shebangs %{nil}' --define '__brp_strip_comment_note %{nil}'
--define '__brp_strip_static_archive %{nil}' --define '__brp_check_rpaths
%{nil}' --undefine __brp_add_determinism --define '__elf_exclude_path
^/usr/lib/systemd/tests/unit-tests/.*$' --define '__script_requires %{nil}'
--define
[Rpm-maint] [rpm-software-management/rpm] --build-in-place regression in 4.20 (Issue #3135)
**Describe the bug**
Since rpm 4.20, the rpm build in systemd's mkosi image build fails in the %prep
stage when trying to fix the source permissions.
**To Reproduce**
Steps to reproduce the behavior:
```
git clone https://github.com/systemd/systemd
cd systemd
mkosi genkey
mkosi -d fedora -r rawhide -f
```
Please link or attach the packages or spec files involved.
https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec
**Expected behavior**
Build succeeds
**Output**
```
‣ Running build script
/home/daandemeyer/projects/systemd/mkosi.images/system/mkosi.conf.d/10-centos-fedora/mkosi.build.chroot…
+ (( NO_BUILD ))
+ . /usr/lib/os-release
++ NAME='Fedora Linux'
++ VERSION='41 (Rawhide Prerelease)'
++ ID=fedora
++ VERSION_ID=41
++ VERSION_CODENAME=
++ PLATFORM_ID=platform:f41
++ PRETTY_NAME='Fedora Linux 41 (Rawhide Prerelease)'
++ ANSI_COLOR='0;38;2;60;110;180'
++ LOGO=fedora-logo-icon
++ CPE_NAME=cpe:/o:fedoraproject:fedora:41
++ DEFAULT_HOSTNAME=fedora
++ HOME_URL=https://fedoraproject.org/
++
DOCUMENTATION_URL=https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/
++ SUPPORT_URL=https://ask.fedoraproject.org/
++ BUG_REPORT_URL=https://bugzilla.redhat.com/
++ REDHAT_BUGZILLA_PRODUCT=Fedora
++ REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
++ REDHAT_SUPPORT_PRODUCT=Fedora
++ REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
++ SUPPORT_END=2025-05-13
+ '[' '!' -f pkg/fedora/systemd.spec ']'
+ '[' -d .git/ ']'
++ git status --porcelain
+ '[' -z ' M
mkosi.images/system/mkosi.conf.d/10-centos-fedora/mkosi.build.chroot
M mkosi.images/system/mkosi.conf.d/10-opensuse/mkosi.build.chroot
?? pkg/fedora/' ']'
++ date +%s
+ TS=1717098377
++ rpm --version
++ cut -d ' ' -f3
+ systemd-analyze compare-versions 4.19.91 lt 4.20
+ tee --append /usr/lib/rpm/redhat/macros
%install %{?_enable_debug_packages:%{debug_package}}\
%%install\
%{nil}
++ cat meson.version
+ VERSION=256~rc3
++ date +%Y%m%d%H%M%S --date @1717098377
+ RELEASE=20240530194617
++ rpm --eval %dist
+ DIST=.fc41
++ rpm --eval %_arch
+ ARCH=x86_64
+ SRCDEST=/usr/src/debug/systemd-256~rc3-20240530194617.fc41.x86_64
++ rpm --define '_fortify_level 0' --undefine _lto_cflags --eval %build_cflags
+ CFLAGS='-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -O0 -Wp,-U_FORTIFY_SOURCE'
+ (( WITH_DEBUG ))
+ CFLAGS='-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -O0 -Wp,-U_FORTIFY_SOURCE
-fdebug-prefix-map=../src=/usr/src/debug/systemd-256~rc3-20240530194617.fc41.x86_64'
+ IFS=
++ (( WITH_TESTS ))
++ echo --nocheck
++ (( WITH_DOCS ))
++ (( WITH_DEBUG ))
++ (( WITH_DEBUG ))
+ ANNOBIN=no-active-checks
+ rpmbuild -bb --build-in-place --with upstream --nocheck --define '_topdir
/var/tmp' --define '_sourcedir pkg/fedora' --define '_rpmdir /work/out'
'--define=_vpath_builddir /work/build' --define '_build_name_fmt
%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm' --define '_binary_payload
w.ufdio' --define 'version_override 256~rc3' --define 'release_override
20240530194617' --define 'build_cflags -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
-march=x86-64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -mtls-dialect=gnu2
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -O0 -Wp,-U_FORTIFY_SOURCE
-fdebug-prefix-map=../src=/usr/src/debug/systemd-256~rc3-20240530194617.fc41.x86_64'
--define 'meson_build %{shrink:%{__meson} compile -C %{_vpath_builddir} -j
%{_smp_build_ncpus} %{nil}}' --define 'meson_install
%{shrink:DESTDIR=%{buildroot} %{__meson} install -C %{_vpath_builddir}
--no-rebuild --quiet %{nil}}' --define 'meson_extra_configure_options -D
mode=developer -D b_sanitize=none' --define '__brp_compress %{nil}' --define
'__brp_mangle_shebangs %{nil}' --define '__brp_strip_comment_note %{nil}'
--define '__brp_strip_static_archive %{nil}' --define '__brp_check_rpaths
%{nil}' --define '__elf_exclude_path ^/usr/lib/systemd/tests/unit-tests/.*$'
--define '__script_requires %{nil}' --define '_find_debuginfo_dwz_opts %{nil}'
--define '_fortify_level 0' --undefine _lto_cflags --undefine
Re: [Rpm-maint] [rpm-software-management/rpm] --build-in-place multiple flaws (Issue #3131)
> The more I look/think into this, it seems that --build-in-place should > entirely disable %prep and all Source/Patch processing, because .. that's > what's it all about. Or, it should take a copy of the original source > directory to preserve semi-normal functionality of rpm. So I haven't really settled on this myself yet. In the systemd case, we have two types of patches: backports from upstream and downstream patches. The backports from upstream are of course useless in the --build-in-place scenario, but the downstream patches are useful to keep sometimes. As an example, systemd has a downstream patch to match the systemd upstream PAM snippet to match the Fedora guidelines. That's one patch that is not disabled when the %upstream macro is defined. A copy of the original source directory could be rather slow depending on the project unfortunately, and one of the core benefits of --build-in-place is being able to do fast rebuilds. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2136786731 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] --build-in-place multiple flaws (Issue #3131)
Yes we just use the fedora spec as is and include it as a git submodule so we can pin each commit in the systemd repository to a specific commit of the spec sources. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2136754246 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] --build-in-place multiple flaws (Issue #3131)
I have run into a few of these getting --build-in-place to work for systemd, let me post my workarounds here as extra information: > the only way --build-in-place really makes sense is doing vpath builds, but > we don't natively support that in rpm (yet) I implicitly assume that I can set vpath_builddir which is luckily supported everywhere via distribution macros > %patch should be disabled with --build-in-place because it's not a pristine > source we can return to > source/patch meaning is questionable in the first place, because it's not > what we build there I added a `BuildSourcesEphemeral=` option in [mkosi](https://github.com/systemd/mkosi) which mounts a writable overlay on top of the build sources that is thrown away after the build. This way the spec can patch and change all it wants without those changes persisting after the build. > build-in-place always requires spec to be aware of the action, should it > instead be an option to %setup instead of cli? or maybe it should just skip > %prep entirely, that seems more appropriate for the cause For the systemd spec we had to add `%version_override`, `%release_override` and `%upstream` macros. The first two allow us to build rpms that are guaranteed to be newer than previous ones. We set the version override to the upstream version in git and set the release override to the timestamp of the git commit (or current unix timestamp if the tree is dirty). The upstream macro allows us to accomodate build system changes or other customizations that are only desired for --build-in-place upstream builds. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2136723330 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debuginfo generation does not work with --build-in-place (Issue #3042)
@pmatilai Thank you for working on this! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3042#issuecomment-213286 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
There have indeed been quite a few improvements to mkosi lately so I understand that it might not have been suitable when you were working on this. Note that when it comes to building cross building, we have CI in mkosi that verifies that verifies that mkosi can do cross distribution image builds for all supported distributions. The only combos that aren't directly supported are building Arch/Ubuntu/Debian images from OpenSUSE as they don't package apt or pacman. However, mkosi also supports so called tools trees, where it first builds an image with all necessary tools and then uses that image to build the actual image. So on OpenSUSE, you can build a Fedora tools tree and use that to build all other supported distributions. This is what we use in the systemd repository to build images on the Github Actions CI runners. We simply configure `ToolsTree=default` and `ToolsTreeDistribution=fedora` and mkosi will first build a Fedora image with all the latest and greatest tooling and then use that to build the actual image. Of course you still need the package manager on the host system to build the tools tree, but mkosi's CI makes sure that we're notified whenever something breaks in that area. Re-using the local build directory might indeed be somewhat more difficult, since you would need to trick CMake into not wanting to reconfigure and rebuild when installing. But there's also no guarantee that the local build directory would actually work unless the dependencies are roughly the same as on the host. Anyway, feel free to email me if you ever feel the itch to switch to mkosi. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-2132860226 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debuginfo generation does not work with --build-in-place (Issue #3042)
It's not the prettiest thing in the world but if you're interested in how we use --build-in-place, the build script that builds the development rpms in systemd can be found [here](https://github.com/systemd/systemd/blob/main/mkosi.images/system/mkosi.conf.d/10-centos-fedora/mkosi.build.chroot) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3042#issuecomment-2074519704 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debuginfo generation does not work with --build-in-place (Issue #3042)
@pmatilai We're using it as part of systemd's development workflow these days. Being able to incrementally build rpms from a locally checked out tree of the upstream repository allows us to incorporate package building in the development workflow itself. I can build an image with newly packaged systemd rpms from the latest upstream sources and boot it in a virtual machine in about 30s thanks to `--build-in-place`. Without `--build-in-place` we'd have to remove rpm from our development workflow entirely again, which I would hate to do because we get more useful test coverage by using rpm since our test images mimick regular distribution installs more compared to us doing `meson install` and hoping for the best. It also makes debugging production issues a joy because I can make a source code change, get new rpms in 30s, install them, get more feedback, and do the same thing. This would also be a lot harder without `--build-in-place`. (This does not take away that any proper rpm build intended to be distributed widely should always be done from pristine sources) This is just some feedback on how this option makes my life a lot easier, so I'm hoping it won't get removed at some point because it conflicts with rpm's design. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3042#issuecomment-2060484948 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debuginfo generation does not work with --build-in-place (Issue #3042)
@keszybz I filed this here given https://github.com/rpm-software-management/rpm/pull/3040 and https://github.com/rpm-software-management/rpm/pull/3036 are going to move this into rpm itself -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3042#issuecomment-2059493773 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debuginfo generation does not work with --build-in-place (Issue #3042)
@pmatilai Is there by any chance a better way than `--build-in-place` to do builds using a local checkout of the sources? I'd be happy to switch to something else that fits more within rpm's view of the world if that exists. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3042#issuecomment-2058993277 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Upstream debuginfo enablement (PR #3040)
Would be great if https://github.com/rpm-software-management/rpm/issues/3042 could also be fixed at the same time as it touches the same logic. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3040#issuecomment-2058887932 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debuginfo generation does not work with --build-in-place (Issue #3042)
AFAIK for `--build-in-place`, `%buildsubdir` doesn't need to be defined. If I remove the check from the `%install` override, debuginfo packages are generated without problems. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3042#issuecomment-2058875214 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] debuginfo generation does not work with --build-in-place (Issue #3042)
**Describe the bug**
The %install to make debuginfo work is currently defined as follows on Fedora:
```
%install %{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}\
%%install\
%{nil}
```
The `--build-in-place` documentation says:
```
--build-in-place
Build from locally checked out sources. Sets _builddir to
current working directory. Skips handling of -n and untar in the %setup and
the deletion of the buildSubdir.
```
Something in the interaction between these two causes debuginfo to not get
generated when `--build-in-place` is used, presumably because `buildsubdir` is
not defined when `--build-in-place` is used.
**To Reproduce**
Steps to reproduce the behavior:
1. Try to build a package that should produce debuginfo packages by using
`--build-in-place`
Please link or attach the packages or spec files involved.
**Expected behavior**
Debuginfo packages are generated
**Environment**
- OS / Distribution: Fedora 39
- Version: RPM version 4.19.1.1
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3042
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
@dmnks Next time shout at me about what's missing! I Would have been happy to discuss improvements to mkosi to make it work for your use case. (I would have commented but had no clue you were considering it) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-2000416984 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] How to specify a fallback package for unpackaged files? (Discussion #2907)
So what I ended up doing is something like the following:
```sh
build() {
# TODO: Replace meson_build and meson_install overrides with "--undefine
__meson_verbose" once
# https://github.com/mesonbuild/meson/pull/12835 is available.
rpmbuild \
-bb \
--build-in-place \
--define "_topdir /var/tmp" \
--define "_sourcedir rpm" \
--define "_rpmdir $PACKAGEDIR" \
--define "__check_files sh -c '$(rpm --eval %__check_files) | tee
/tmp/unpackaged-files'" \
"$@" \
rpm/systemd.spec
}
if ! build; then
EXIT_STATUS=$?
if [ ! -s /tmp/unpackaged-files ]; then
exit $EXIT_STATUS
fi
# rpm will append to any existing systemd.lang so delete it explicitly so
we don't get duplicate file
# warnings.
rm systemd.lang
cat /tmp/unpackaged-files >>rpm/files.systemd
build --noprep --nocheck
fi
```
Basically we run `rpmbuild` once and if it fails, we check if there are any
unpackaged files. If there are unpackaged files, we append those to the
files.systemd file which lists the files of the systemd package and then run
`rpmbuild` again with `--noprep` and `--nocheck`.
To get the unpackaged files, we override the `__check_files` macro and have it
write its output to `/tmp/unpackaged-files` in addition to writing it to the
standard output.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8503531
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Including a file, expanding the macros in it and writing the result to another file? (Discussion #2912)
I'm trying to include a file with macros in it, expand those macros and write
the result to another file. My last attempt that doesn't work is the following:
```
echo "%{expand:%include %{SOURCE203}}" > expanded
```
If SOURCE203 contains the following:
```
%{_unitdir}/systemd-coredump.socket
%{_unitdir}/systemd-coredump@.service
```
I want "expanded" to contain:
```
/usr/lib/systemd/system/systemd-coredump.socket
/usr/lib/systemd/system/systemd-coredump@.service
```
Anyone able to help me out?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2912
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] How to specify a fallback package for unpackaged files? (Discussion #2907)
@pmatilai I found that flag, but that's not a solution, we want these new files to actually get packaged so we can install the development with those new files so we can run tests with them. Anyway, the Fedora spec already handles this by dynamically generating the files lists so I'll probably try to work the suse spec maintainers to do the same thing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8464140 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] How to specify a fallback package for unpackaged files? (Discussion #2907)
@pmatilai Yes but these packaging specs are downstream. You end up with a chicken and egg problem. If we want to use the downstream packaging specs for building upstream testing packages, the downstream spec needs to be updated before any upstream PR introducing new unpackaged files can be tested and merged. But the downstream spec can only be updated once the upstream PR is merged, because otherwise it would fail to build because the newly added files are not yet installed so you get into a circular dependency. One way out of this circular dependency is to be able to specify that, when building packages from upstream sources, any unpackaged files go into a fallback package (which in systemd's case would be the main systemd package). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8463024 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] How to specify a fallback package for unpackaged files? (Discussion #2907)
@pmatilai That's exactly what I'm doing. I'm trying to reuse the opensuse spec. The same problem still applies. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8462862 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] How to specify a fallback package for unpackaged files? (Discussion #2907)
For hacking on systemd, I'm looking into building rpms from upstream sources. Because we're building from upstream sources, there are naturally unpackaged files depending on how the %files directives are handled. I would like to assign any unpackaged upstream files that haven't been explicitly assigned to a package yet to the systemd package. Is there any way I can specify to rpm that any unpackaged files should be assigned to a specific package? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2907 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpmspec: Add some more popt aliases (PR #2600)
These are all available on the rpm CLI so lets make them available on the rpmspec CLI as well. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2600 -- Commit Summary -- * rpmspec: Add some more popt aliases -- File Changes -- M rpmpopt.in (12) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2600.patch https://github.com/rpm-software-management/rpm/pull/2600.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2600 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmug: Make sure /etc/passwd and /etc/group from chroot are used (PR #2480)
Rewriting the f-variants is a bit more work than I'm willing to spend on this. I realized that I can simply install in two steps, first to install `setup` which provides /etc/passwd and then to install the rest. For the second step, I mount over passwd from the root over passwd from the host and that fixes the issue for me as well, so I won't spend any more time on this. Would still like to see the issue fixed in rpm though! Thanks for taking the time to review the PR. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2480#issuecomment-1508174859 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmug: Make sure /etc/passwd and /etc/group from chroot are used (PR #2480)
Closed #2480. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2480#event-9005424815 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpmug: Make sure /etc/passwd and /etc/group from chroot are used (PR #2480)
If we chroot(), getpwnam() and friends will still return results from the host /etc/passwd and related files because of caching. We cant flush the caches ourselves, so instead, lets open /etc/passwd ourselves in the chroot and use fgetpwent() and friends to read from it. This makes sure we avoid the glibc cache and get up-to-date results after chrooting. We also drop the in function caching because it doesnt take chroot() into account either. The same passwd name could have different uids assigned to it inside and outside of the chroot, so we cant use the current cache as is without having some mechanism to flush the caches every time we chroot() or keeping a cache per chroot. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2480 -- Commit Summary -- * rpmug: Make sure /etc/passwd and /etc/group from chroot are used -- File Changes -- M lib/rpmug.c (132) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2480.patch https://github.com/rpm-software-management/rpm/pull/2480.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2480 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Rpm chroot operations use user/group info from the host (#882)
@pmatilai Is it an option to use `fgetpwent()` and `fgetgrent()` to circumvent glibc's caching? I'm not sure if rpm needs to take into account nsswitch. If it doesn't, using those two functions could be an option. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/882#issuecomment-1458154427 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
