Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3348#discussioncomment-10819368
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailin
We're looking to move systemd unit operations in rpm scriptlets to `%posttrans`
instead of `%postun`. While looking into this, I discovered that currently
`systemctl daemon-reload` is run via `We'd like to run `systemctl
daemon-reload` before any `%posttrans` scriptlets. Currently `systemctl
da
> the only way --build-in-place really makes sense is doing vpath builds, but
> we don't natively support that in rpm (yet)
I actually figured out that you can mount a build directory onto a source
directory with overlayfs to do vpath builds for autotools and makefile based
stuff as well. A gro
@pmatilai Can I get a new release in rawhide with the --build-in-place changes?
I'm trying to switch to absolute `_sourcedir` with `--build-in-place` in
https://github.com/systemd/systemd/pull/34142 and hoping it'll be fixed with
the recent changes.
--
Reply to this email directly or view it o
> Yup, that selinux.spec snippet was what pretty much inspired that %prep -a
> idea.
>
> One open question there is: where does %{SOURCEn} come from with
> --build-in-place? (this goes beyond just %prep of course). Using the normal
> %_sourcedir seems very wrong for that, and of course you ment
> It just occurred to me that another possibility could be defining
> build-in-place as to override the main %prep section, but allow appended
> sections to be executed as normal for other actions. This would probably help
> share a spec between a "normal" and in-place build. For example:
>
> `
@DaanDeMeyer commented on this pull request.
LGTM
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3255#pullrequestreview-2251025306
You are receiving this because you are subscribed to this thread.
Message ID: _
> So this issue is really at the heart of the problem with --build-in-place.
>
> Working on #3216 (see PR #3252) kinda convinced me that --build-in-place
> should probably _imply_ skipping %prep, because that actually offers a way to
> make sense out of this all. For an in-place build, it's not
> Relative _foodir for the build stuff was never supported by rpm, it just
> happened to work in various cases in the past (see
> https://github.com/rpm-software-management/rpm/issues/3128, we're considering
> on making it explicit). The new intermediate build directory in >= 4.20 just
> means
@pastalian This seems like a duplicate of
https://github.com/rpm-software-management/rpm/issues/3208?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3216#issuecomment-2255150622
You are receiving this because you are subscribed to this
Somewhat related, specifying `_sourcedir` as a relative directory is also
broken with rpm 4.20:
```
Building target platforms: noarch
Building for target noarch
setting SOURCE_DATE_EPOCH=1721952000
Executing(%mkbuilddir): /bin/sh -e /var/tmp/rpm-tmp.FddfFZ
+ umask 022
+ cd /var/tmp/BUILD/selinux-
**Describe the bug**
Something is still different between rpm from Fedora 40 and rpm from Fedora
Rawhide when it comes to `--build-in-place`:
Fedora 40:
```
➜ mkosi git:(cache) ✗ mkosi -r 40 --debug-shell -f
Create subvolume '/home/daandemeyer/.cache/mkosi/mkosi-workspace-4b0haoi_/root'
‣ Buil
@pmatilai Something is still different between rpm from Fedora 40 and rpm from
Fedora Rawhide when it comes to `--build-in-place`:
Fedora 40:
```
➜ mkosi git:(cache) ✗ mkosi -r 40 --debug-shell -f
Create subvolume '/home/daandemeyer/.cache/mkosi/mkosi-workspace-4b0haoi_/root'
‣ Building default
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/315
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
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 rece
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:
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 receivin
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
**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-debugin
**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 ra
> 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 rea
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-213
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
@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:
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 build
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)
@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
@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/iss
@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.c
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
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#issuec
**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 loc
@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-m
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 \
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
%{
@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
@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 teste
@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 s
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 a
These are all available on the rpm CLI so let's 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 Change
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
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-
If we chroot(), getpwnam() and friends will still return results from the host
/etc/passwd and related files because of caching. We can't flush the caches
ourselves, so instead, let's open /etc/passwd ourselves in the chroot and
use fgetpwent() and friends to read from it. This makes sure we avo
@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-soft
45 matches
Mail list logo
