@pmatilai commented on this pull request.
> @@ -1,6 +1,4 @@
-# Use our top-level targets as an ordering clue to cmake: the project
-# needs to be built before we can populate anything...
-get_property(TOP_TARGETS DIRECTORY .. PROPERTY BUILDSYSTEM_TARGETS)
+set(RPM_TARGETS librpm librpmio
@pmatilai commented on this pull request.
> @@ -1,6 +1,4 @@
-# Use our top-level targets as an ordering clue to cmake: the project
-# needs to be built before we can populate anything...
-get_property(TOP_TARGETS DIRECTORY .. PROPERTY BUILDSYSTEM_TARGETS)
+set(RPM_TARGETS librpm librpmio
Running the test-suite obviously requires on having the project completely
built first. The test-suite was relying on the cli tools in the top level
directory for this, but now that we moved the tools elsewhere there are zero
targets at the top-level. Oops.
Update the property get_property()
Merged #2692 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2692#event-10547324621
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
There's also at least commit a25d881f287e67568c15a87c9fc9a2c4acc0650e embedded
in here. So yep, please rebase before a closer look. Rebasing before submitting
a PR is usually a good idea.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -647,7 +647,7 @@ AT_SETUP([xml format])
AT_KEYWORDS([query])
RPMTEST_CHECK([
RPMDB_INIT
-runroot rpm -qp --xml data/RPMS/hello-2.0-1.x86_64.rpm
+runroot rpm -qp --xml /data/RPMS/hello-2.0-1.x86_64.rpm
These relative -> absolute path changes
LGTM
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2692#issuecomment-1746316556
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
@dmnks commented on this pull request.
> @@ -1,6 +1,4 @@
-# Use our top-level targets as an ordering clue to cmake: the project
-# needs to be built before we can populate anything...
-get_property(TOP_TARGETS DIRECTORY .. PROPERTY BUILDSYSTEM_TARGETS)
+set(RPM_TARGETS librpm librpmio
Oh right, so there was a concrete reason for not allowing binary certificates
in the current API.
Wherever new APIs are needed, just do what makes most sense to you. No reason
to hang with the old ad-hoc API and its naming.
--
Reply to this email directly or view it on GitHub:
@dmnks commented on this pull request.
> @@ -647,7 +647,7 @@ AT_SETUP([xml format])
AT_KEYWORDS([query])
RPMTEST_CHECK([
RPMDB_INIT
-runroot rpm -qp --xml data/RPMS/hello-2.0-1.x86_64.rpm
+runroot rpm -qp --xml /data/RPMS/hello-2.0-1.x86_64.rpm
Indeed, this is another example of something
The dependencies recorded in an src.rpm are only valid for the environment
(including any cli-switches) it was generated in. It's entirely possible to end
up with something quite different on a spec reparse, which is what happens on
any build.
As for pkg-config deps, I see this in the spec,
I'd prefer the "Fix comment style" commit to be merged into the previous commit
that introduces the comment, but other than that looks fine to me. Unless you
have something else you're planning to work on here, just flag ready for review
and I'll merge, we already did the review part here.
--
@pmatilai commented on this pull request.
> @@ -1,6 +1,4 @@
-# Use our top-level targets as an ordering clue to cmake: the project
-# needs to be built before we can populate anything...
-get_property(TOP_TARGETS DIRECTORY .. PROPERTY BUILDSYSTEM_TARGETS)
+set(RPM_TARGETS librpm librpmio
BTW, it's also technically possible to (externally) rewrite the specfile after
launching a build on it, and end up with wildly different in the src.rpm than
what the build was launched with. It would be a nasty thing to do of course,
but technically possible, and could explain oddities like
I suggest you try reproducing it in a different environment. A clean container
image or such.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2690#issuecomment-1746536531
You are receiving this because you are subscribed to this
Yes, this thought has occurred to me, too. I have not addressed this here as it
is mainly an issue of the original dynamic spec change. But it is something we
need to address.
Funny enough we could actually allow %prep to create later build scripts. Ofc
this doesn't work right now. Also there
Interesting... `-rr --nodeps` rewrites .src.rpm in a way that `dnf` INSTALLS
`pkgconfig(systemd)` afterwards.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2690#issuecomment-1746625208
You are receiving this because you are
#781
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2690#issuecomment-1746702064
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
#797
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/781#issuecomment-1746701819
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
As noted in #2646 dynamic spec parts can create/declare tags and sections that
cannot be used that late and we should not allow that and error out. First
rough list:
- all build sections
- including %generatebuildrequires
- BuildRequires
- BuildArch except noarch
--
Reply to this email
Rpm doesn't use the dependencies recorded into an src.rpm in any circumstance,
the spec is always reparsed. I don't know what the difference between rpmbuild
-bs and -br is in your environment, but that's where the issue is.
--
Reply to this email directly or view it on GitHub:
Seems dup of #797
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2690#issuecomment-1746700437
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
FTR, CMake does something similar on `make clean` as I discovered the other
day. As for the test-suite artifacts, we already do exactly
[that](https://github.com/rpm-software-management/rpm/blob/ea19571b86ff1f828efc264744715b69e30d6832/tests/mktree.fedora#L82).
It just seems natural to have
Closed #2690 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2690#event-10548896970
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Oh, I see it now. Try 'rpmspec --parse frr.spec' to see how it looks to rpm,
and it becomes quite clear.
The pkgconf(systemd) dependency comes from the `%{?selinux_requires}` macro.
And if rpmbuild -bs is executed in an environment where that macro is not
defined then it will miss those
@pmatilai I always run everything in a clear environment. i.e. in the
container, yes.
Does `rpmbuild -rr` re-parse .spec-file ? Thought it does not.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2690#issuecomment-1746570147
You are
@pmatilai sorry for not explaining clearly. Seems it is another bug. When `-rr`
says error about missing deps but does not generate `.buildreqs.nosrc.rpm` in
some conditions. In generally – yes, it works as expected. Especially on
pyproject srpms, where 3-5 iterations are possible.
please
Just FTR, this could be related to #1277.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1277#issuecomment-1746473960
You are receiving this because you commented.
Message ID: ___
Rpm-maint
@pmatilai Commented things – are my lines – I did not remove after experiments.
Yes, our scripts build `.src.rpm` from `.spec` file and then (in the same
environment) install build deps. The problem that `rpmbuild -rr` says about
missing deps, but `dnf builddep` does not install them (does not
@pmatilai sorry for bash script, but I want just show what happens in our build
script:
```bash
unpriv rpmbuild "${defines[@]}" -bs "$spec_file" --rmspec
srpm=("$RPMBUILD"/SRPMS/*.src.rpm)
while :; do
unpriv rpmbuild "${defines[@]}" -rr "$srpm" && exit_code=0 ||
exit_code=$?
@pmatilai there are no difference. Really. I have provided part of the shell
script. Tell me how to debug, please. I strongly consider there is a bug in
RPM, but con not knock it down.
--
Reply to this email directly or view it on GitHub:
Seems I figured out. After installing deps from file generated by `-bs` some
macroses appear. that's what is changed in environment.
So the bug is: not generating `.buildreqs.nosrc.rpm`. If it was generated, bug
would not happen.
--
Reply to this email directly or view it on GitHub:
Seeing requiredTagsForBuild inspired some thoughts for the basical reverse
cases of things that cannot be handled from generated content.
What happens if somebody generates a BuildArch line from inside the build?
Other than noarch sub-packages that is.
What happens with stuff like
The one thing -bs and -br *will* disagree with is dynamic buildrequires from
%generate_buildrequires. I don't see that in the src.rpm but I don't know what
macros and stuff you may have locally.
--
Reply to this email directly or view it on GitHub:
Hello,
Software Heritage is the universal archive of source code, and a non profit
organization.
Our mission is to collect, preserve and share source code from every possible
origins,
including forges and package managers.
Software Heritage will soon be ready to support the ingestion of RPM
Instead, just use absolute paths everywhere. This allows us to revert the ugly
workaround for bwraps double-chdir warning from commit
5e9c71296e8cd6c5f2f5a6188b303bbd7a2c74db as well as let make shell
also start in /srv.
No functional change.
You can view, comment on, or merge this pull
@dmnks pushed 2 commits.
e281e9559faafa0f23d666cc59aa4a73080ea95b Keep record of stock RPM in RPMDB in
Dockerfile
1d7f308059202bfd44c0cdbfcfaf7f699949aef7 Add build stages to Dockerfile
--
View it on GitHub:
Closing as I fail to see any bug in here. All our CI builds are done outside
the source tree.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2650#issuecomment-1746943425
You are receiving this because you are subscribed to this
Looking into this again and in more detail, I think it would be enough if there
were some `dummy.attr` file loaded. This would later enable to just define some
`__dummy_requires` macro and this could be enough.
My (probably very silly idea) would be to ship `find.attr` file with RPM, that
Please correct me if I got something wrong. My understanding is the following:
- rpmbuild will generate `Provides: user(foo) = ` and `Provides:
group(foo) = ` (??, see below) for packages which have sysusers.d files
- rpmbuild will generate `Requires: {user,group}(foo)` or `Recommends:
Closed #2650 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2650#event-10551580009
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Included in #2696, closing this one.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2695#issuecomment-1746976877
You are receiving this because you are subscribed to this thread.
Message ID:
These are mostly preparatory work for #2643.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2696
-- Commit Summary --
* Dont assume PWD of / in tests
* Make snapshot() work without CMake configuration
* Move snapshot()
@dmnks commented on this pull request.
> @@ -647,7 +647,7 @@ AT_SETUP([xml format])
AT_KEYWORDS([query])
RPMTEST_CHECK([
RPMDB_INIT
-runroot rpm -qp --xml data/RPMS/hello-2.0-1.x86_64.rpm
+runroot rpm -qp --xml /data/RPMS/hello-2.0-1.x86_64.rpm
Fix for the above:
Closed #2695.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2695#event-10551803373
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
@dmnks pushed 3 commits.
e3d8b2a627ffb79e6a098788f39fd8a2b40288cf Make snapshot() work without CMake
configuration
dd08d096253a1f1137ad4cde32fbbf977a2281f4 Move snapshot() to mktree.common
4871b237fe9b98b001880b7d2dc70a72b6526ff8 Rename make target env to atshell
--
View it on GitHub:
@dmnks pushed 5 commits.
14aa701f38bcd1c32b31d5d9db47e78a68c10535 Make snapshot() work without CMake
configuration
55c24dc6e444ebd3ce54af1d2ecafe6fbc808b4d Move snapshot() to mktree.common
f9113d73e2f9de831874b1299967b9fa563d186d Rename make target env to atshell
OK, I realized this change is actually not needed for #2691 or at all, so
scratch that.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2695#issuecomment-1747774484
You are receiving this because you are subscribed to this thread.
@dmnks pushed 4 commits.
8194e8fdf95dc456397b2ea173bb9b0918246a3c Move snapshot() to mktree.common
9037d8290b254fa6f243dd97f314cafb8cb4b7b2 Rename make target env to atshell
e67e5e7d2f7953183002d64c2812f65d05fdf92b Keep record of stock RPM in RPMDB in
Dockerfile
These are rather different than the general tests otherwise, might
as well have them in their own set.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2698
-- Commit Summary --
* Split development tests into its own file
@pmatilai commented on this pull request.
> @@ -52,6 +52,23 @@ RUN dnf -y install \
&& dnf clean all
RUN echo "%_dbpath $(rpm --eval '%_dbpath')" > /root/.rpmmacros
+# Workaround for pkgconf(1)'s unlisted dependency on rpm.
+# This is needed for cmake to work without an rpm installation.
51 matches
Mail list logo
