As long as %build was not executed and there is no such things lik
`PrepRequires:` IMO it was not the bug .
`BuildRequires:` literally says that it defines **build** dependencies
Good that `--nodeps` still is working
--
Reply to this email directly or view it on GitHub:
I don;t see anything about that on https://rpm.org/wiki/Releases/4.19.0 so it
must be some side effects recent changes.
console
[tkloczko@pers-jacek SPECS]$ rpmbuild -bp python-fastavro.spec
error: Failed build dependencies:
python3dist(cython) is needed by
Closed #2649 as not planned.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2649#event-10319459976
You are receiving this because you are subscribed to this thread.
Message ID:
___
Closed #2652 as not planned.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2652#event-10319454018
You are receiving this because you are subscribed to this thread.
Message ID:
___
This is intended behavior. The fact that it used to work was *a bug* which was
fixed in RPM 4.18.1 through #2271, also mentioned in
https://rpm.org/wiki/Releases/4.18.1.
--
Reply to this email directly or view it on GitHub:
Closed #2652 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2652#event-10319431444
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
IMO it would be good to add line about that on
https://rpm.org/wiki/Releases/4.19.0
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2652#issuecomment-1711936588
You are receiving this because you are subscribed to this thread.
Message
After build first time rpm 4.18.99 I've tested building it with itself and I
found new rpm no longer accepts shell globs in %files
RPM build errors:
File not found:
/home/tkloczko/rpmbuild/BUILDROOT/rpm-4.18.99-2.fc35.%{_arch}/usr/lib/rpm/*.{req,prov}
File not found:
FTR, if you wish to avoid the check, you can use `--nodeps`. It's also what
e.g. `fedpkg prep` does behind the scenes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2652#issuecomment-1711848199
You are receiving this because you are
I just realised that %_arch macro is not defined as well and I see in %install
```console
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.TkXan3
+ umask 022
+ cd /home/tkloczko/rpmbuild/BUILD
+ '[' '/home/tkloczko/rpmbuild/BUILDROOT/rpm-4.18.99-2.fc35.%{_arch}' '!=' / ']'
+ rm -rf
Files rpmrc, platform and macros are mot in source tree and they are generated
to `${CMAKE_BINARY_DIR}` in cace of off-source tree build.
Here is the patch which fixes this issue
```patch
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -162,7 +162,9 @@
install(CODE "execute_process(COMMAND
Files like rpmrc, platform and macros are not in source tree and they are
generated to ${CMAKE_BINARY_DIR} in cace of off-source tree build.
Close #2650
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2651
-- Commit Summary
This issue may be related to
https://github.com/rpm-software-management/rpm/issues/1749
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2649#issuecomment-1711263408
You are receiving this because you are subscribed to this thread.
Closed #2649 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2649#event-10315224845
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This is apparently because of the `%{_arch}` macro being undefined and thus
unexpanded and used literally when matching files on disk. There's the other
issue #2650 that you've opened which has more information.
--
Reply to this email directly or view it on GitHub:
CMake sets the current working directory to the respective build directory
automatically. I'm not sure how being explicit here would help or fix anything.
We use such relative filenames everywhere in our CMake configuration. Most of
us also use out-of-source builds on a daily basis without any
After install 4.18.99 and rebuild looks globs are working (so indeed globs re
related to %arch).
However looks like python module installation hack still is needed .. so still
something is wrong 樂
```console
RPM build errors:
File not found:
We don't support ctest. The test suite is run with `make check`, see the
[README](https://github.com/rpm-software-management/rpm/blob/master/tests/README.md).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2648#issuecomment-1711189607
Closed #2648 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2648#event-10314626111
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Also, the `ENABLE_TESTSUITE` option no longer has any effect. The test suite is
enabled based on whether the host has the necessary test dependencies
(Bubblewrap or Podman/Docker) or not.
This is, sadly, not yet documented. We're planning to do fix that.
--
Reply to this email directly or
Quite possible that this PR broke shell globs in %files
https://github.com/rpm-software-management/rpm/issues/2649
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1749#issuecomment-1711262879
You are receiving this because you are
Well, if you look at the output above, `%{_arch}` is included verbatim which
means it was not expanded at SPEC parse time. Globs indeed have nothing to do
with this.
--
Reply to this email directly or view it on GitHub:
Let me revert the question: What makes you think we *should* support ctest?
Just because we use cmake?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2648#issuecomment-1711348681
You are receiving this because you are subscribed to
>From https://github.com/rpm-software-management/rpm/issues/2649
I just realised that %_arch macro is not defined as well and I see in %install
```console
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.TkXan3
+ umask 022
+ cd /home/tkloczko/rpmbuild/BUILD
+ '['
I've deleted all %_arch comments and opened separated ticket to keep those two
thing separated.
I don't thing that shell globs are somehow related to %_arch issue when it is
used off-source-tree build.
--
Reply to this email directly or view it on GitHub:
On building 4.18.99 using rpm 4.17.0 I found that it is yet another issue which
is somehow related to %_arch.
On building python module lands in /usr/lib/python* instead in
/usr/lib64/python*
Initially I've added hack in %install
```spec
%__mv %{buildroot}{%{_prefix}/lib/python*,%{_libdir}}
```
OK so it may mean that my patch fixes only install target in case of use
off-source-tree build and because python module was installed in wrong location
(on building rpm 4.17.0) stil something else around.
Other thing is that even with broken %_arch "%{_arch}" string was used in path
name and
> We don't support ctest. The test suite is run with `make check`, see the
> [README](https://github.com/rpm-software-management/rpm/blob/master/tests/README.md).
(just humble question)
OK but why? 樂
--
Reply to this email directly or view it on GitHub:
> > So as you see I'm passing -S and -B paths explicit ..
>
> Yes, that's what fails, see my comment above.
ItWorks™️ in my case. Not only in case of rpm but
```console
[tkloczko@pers-jacek SPECS]$ grep -l %cmake *spec |wc -l
553
```
packages.
May I have look on your command with output? 樂
> ItWorks™️ in my case. Not only in case of rpm but
I'm honestly confused about your comments. Does `cmake --install ` work
for you or not?
Anyway, the output:
```
$ cmake -B build -C rpm
$ cmake --build build/
$ cmake --install build/
[...]
grep: rpmrc: No such file or directory
sed: can't
> > So as you see I'm passing -S and -B paths explicit ..
>
> Yes, that's what fails, see my comment above.
OK, I wasn't specific here, apologies. What I meant was:
Yes, that's *why* the installation fails (i.e. the `cmake --install `
command).
--
Reply to this email directly or view it on
In fact, the use of `-B` and `-S` at configure time doesn't even have anything
in common with this issue. This issue is *just* that `cmake --install` is
invoked (instead of `make install`) from a different directory.
--
Reply to this email directly or view it on GitHub:
In python/CMakeLists.txt is:
```cmake
install(TARGETS _rpm
DESTINATION ${Python3_SITEARCH}/rpm)
install(FILES rpm/transaction.py rpm/__init__.py
DESTINATION ${Python3_SITEARCH}/rpm)
set(egginfo
Still execution of that test suite script IMO should be done over ctest.
This would allow easier migration to execute units over ctest.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2648#issuecomment-1711463478
You are receiving this
Strange. One would expect that specifying a build directory with `-B` would
instruct cmake to change the CWD to that. And indeed, that's what seems to be
happening for me since I'm getting the `rpmrc`, `platform` and `macros` files
in correct (build) directory:
```sh
$ cmake -B build -S rpm
> CMake sets the current working directory to the respective build directory
> automatically
Yes default directory is current directory however I see why it was working in
case fedora build
```spec
%build
%set_build_flags
mkdir _build
cd _build
cmake \
-DCMAKE_INSTALL_PREFIX=%{_usr} \
Looks like python module wrong directory may be related to the fact that I'm
using %cmake macro which in my case looks like below
```spec
%cmake %{set_build_flags} \
%__cmake \\\
-B %{_vpath_builddir} \\\
-D BUILD_SHARED_LIBS=ON \\\
-D CMAKE_AR="$AR" \\\
-D
Because ctest is standard cmake tool and it is supported directly by cmake
files allowing OOTB for example parallelisation of ctest units execution (it
allows as well exclude some exact units paralel execution
https://www.scivision.dev/cmake-resource-lock-ctest/ .. .if it was the cause of
not
> Because ctest is standard cmake tool and it is supported directly by cmake
> files allowing OOTB for example parallelisation of ctest units execution (it
> allows as well exclude some exact units paralel execution
> https://www.scivision.dev/cmake-resource-lock-ctest/ .. .if it was the cause
> Why to maintain own test suite framework? 樂
Oh, and it's not our *own* test framework, I'm not sure where you've that
impression.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2648#issuecomment-1711447179
You are receiving this
Please suggest that in the ticket I linked above, together with the exact
reason why you think it would be better. Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2648#issuecomment-1711476272
You are receiving this because you
Oh, nevermind. It's the `cmake --install` command that fails (used in
`%cmake_install`). I can reproduce this myself now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2651#issuecomment-1711497910
You are receiving this because you are
It's not clear what the current directory is set to by default during
`execute_process()` but in this case, it certainly isn't set to the original
build directory.
Also, if we're going to fix this, setting `WORKING_DIRECTORY` would probably be
better than prefixing each path manually.
I'll
> So as you see I'm passing -S and -B paths explicit ..
Yes, that's what fails, see my comment above.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2651#issuecomment-1711568716
You are receiving this because you are subscribed to this
> ## Problem
>
> It turns out that, while this is quite easy to do on Fedora with DNF and
> `unshare(1)`, it is not as easy on other distros that I've tried, namely
> OpenSUSE where Zypper doesn't seem to like being run through `unshare(1)`,
> and would likely require `sudo` instead
Hmm, not
> This seems more like some kind of misconfiguration related to the `%cmake`
> macro shipped in Fedora
No, no .. this is not the case.
In Fedora rpm.spec %cmake macro is not used so this is why it was not exposed.
https://src.fedoraproject.org/rpms/rpm/blob/rawhide/f/rpm.spec#_360
--
Reply to
> No, no .. this is not the case. In Fedora rpm.spec %cmake macro is not used
> so this is why it was not exposed.
> https://src.fedoraproject.org/rpms/rpm/blob/rawhide/f/rpm.spec#_360
I don't see how that contradicts what I said above.
--
Reply to this email directly or view it on GitHub:
> > No, no .. this is not the case. In Fedora rpm.spec %cmake macro is not used
> > so this is why it was not exposed.
> > https://src.fedoraproject.org/rpms/rpm/blob/rawhide/f/rpm.spec#_360
>
> I don't see how that contradicts what I said above.
You wrote that it must be related to Fedora
> You wrote that it must be related to Fedora %cmake macro definition. In this
> case %cmake macro is not used so it cannot be related to Fedora %cmacro
No. What I meant by *it* was the issue you're seeing.
--
Reply to this email directly or view it on GitHub:
Nevertheless if both params of the install() are specified with
{CMAKE_SOURCE_DIR} and ${CMAKE_BINARY_DIR} like it is in proposed patch it will
be working in both cases
--
Reply to this email directly or view it on GitHub:
Yes, see my previous comment which confirms that `cmake --install` indeed fails
if not run from the build directory.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2651#issuecomment-1711516246
You are receiving this because you are
Reproducer:
```
$ cmake -B /path/to/build/dir -C /path/to/rpm/source/dir
$ cmake --install /path/to/build/dir
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2651#issuecomment-1711521260
You are receiving this because you are
In my case cmake source definition of rpm macros looks like below:
```spec
#
# Macros for cmake
#
%_cmake_skip_rpath -D CMAKE_SKIP_RPATH=ON
%__cmake/usr/bin/cmake
%__ctest/usr/bin/ctest
%_vpath_srcdir .
# - Set default compile flags
# -
Ah, OK, I think this is the error I saw initially (and now too):
```
error: unpacking of archive failed on file /dev: cpio: chown failed - Device or
resource busy
error: filesystem-84.87-12.1.i586: install failed
( 4/27) Installing: filesystem-84.87-12.1.i586
Anyway. Having slept on this a couple of times, it's become clear that we just
don't want to deal with all this bootstrapping business and basically
re-implement `mkosi` (which we can't use for other reasons as outlined above).
So, circling back to where we started, all we really need is to
> $ cmake -B build -C rpm
So in above you are NOT passim -S and -B and looks like you are running cmake
from outside root source tree..
Please try `cmake -B build -S . -C rpm`. (IIRC -C it is only cache dir so it
should not matter)
> $ cmake --build build/
> $ cmake --install build/
Here you
> > $ cmake -B build -C rpm
>
> So in above you are NOT passim -S and -B and looks like you are running cmake
> from outside root source tree.. Please try `cmake -B build -S . -C rpm`.
> (IIRC -C it is only cache dir so it should not matter)
Excuse me... What? I am literally passing -S and -B
Fuck this. There was a typo, it was indeed `-C`, not `-S`. In my testing, I
used `-S`, though. Fixed in the comment above now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2651#issuecomment-1711783432
You are receiving this because
Apologies for the cursing and all, but I'm really tired of this discussion
going nowhere. I think we've agreed on the root cause here, and no further
discussion is required.
As for the patch itself, as I said already, we should rather use
`WORKING_DIRECTORY` and while at it, also look at our
59 matches
Mail list logo
