It would be good to add checking that target to release procedure
```console
+ /usr/bin/cmake --build x86_64-redhat-linux-gnu -j48 --verbose --target
update-pot
Change Dir: '/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1/x86_64-redhat-linux-gnu'
Run Build Command(s): /usr/bin/cmake -E env VERBOSE=1 /us
BTW: is it possible to change dist tar ball compression from .bz2 to .xz 🤔
(xz produces shorter tar balls on archives with text files)
```console
[tkloczko@pers-jacek SOURCES]$ ls -l rpm-4.19.1.tar.xz rpm-4.19.1.tar.bz2
-rw-rw-r-- 1 tkloczko tkloczko 5940447 Dec 14 19:37 rpm-4.19.1.tar.bz2
-rw-rw-
> Why on earth are you specifically running 'update-pot' on a released rpm
> tarball in the first place?
Because .pot file used during build is ALWAYS not-up-to-date. `update-pot`
removes many translated entries which are no longer used (-> installed .mo
files are shorter).
As you see in this c
IMO all those changes should be part of rpm repo.
In this repo should be time to time (at least week before release) updated
po/rpm.pot file and that .pot files should be registered on one of the i18n
translation infras. Than time to time available updates should be pooled.
Really .. please have
> I'm just making the changes where they are now. I can certainly see moving
> the CMake code out and file list out.
It is not possible to tag repo ans subrepo.
At the moment in https://github.com/rpm-software-management/rpm-l10n there is
no any tags.
--
Reply to this email directly or view i
> (..) and for Fedora multiple times by different people and doesn't exhibit
> any such errors.
Because Fedora build procedure has no `update-pot` target execution.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2817#issuecomment-1860
> Well yes, it's not something you're expected to run on a release tarball. So
> this is really going in circles, again.
MANY projects have not updated .po files (look on
https://github.com/mesonbuild/meson/issues/11338)
--
Reply to this email directly or view it on GitHub:
https://github.com
Wate of time.
Deduplication it is something which should be done on fs layer.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2827#issuecomment-1872599981
You are receiving this because you are subscribed to this thread.
Message ID: ___
> we can use : rpmbuild --without check
This can be added very easy by place in global macros single line modification
```spec
# Add handle --{with|without} check
%__spec_check_pre \
%{!?with_check:echo "%%check disabled."; exit 0} \
%{___build_pre}
```
Than you can place in spec f
> ```spec
> # Add handle --{with|without} check
> %__spec_check_pre \
> %{!?with_check:echo "%%check disabled."; exit 0} \
> %{___build_pre}
> ```
Actually this is not all. It needs to be added default value of the
%with_check. So wole solution has two additional lines.
```spec
#
**Describe the bug**
in
https://github.com/rpm-software-management/rpm/issues/316#issuecomment-1900766922
I wrote that I'm using +years solution which allows me to disable %check
execution by use `%bcond_with check`.
What I'm using is not exactly what I've proposed in next comment.
What I'm usin
Sorry Actual behaviour is different.
When I've executed above commands I've already had changed `%__spec_check_pre`
in /usr/lib/rpm/redhat/macros.
Result with defined %bcond_with
```spec
%bcond_with check
Summary:bcond test
Name: test
Version:1
Release:1
L
https://github.com/rpm-software-management/rpm/blob/b2e8a2bed582a9ccc70fbbf3c8586bdd712ea4d1/macros.in#L762-L766
Issue is that `%{?build_ldflags}` it is no value of the macro but it provides
information is macro defined or not.
When I've added in some cyrus-sasl.spec file "%global build_ldflags
This PR is wrong and is not solving th issue.
It is the problem that macros used with `%bcond_with foo`/`%bcond_without foo`
like `%{?with_foo}` and `%{?without_foo}` are using presence or not that macro.
If you will look closer on macros file
```spec
# Internally, the `--with foo` option defines
> Do I understand correctly that the `BUILDROOT` dir was replaced by
> `%{_builddir}/%{_target_cpu}-%{_target_os}-root`? The `%{_builddir}` is the
> right move IMHO, but what is the advantage of
> `%{_target_cpu}-%{_target_os}-root` over `BUILDROOT`, especially when e.g.
> `SPECPARTS` stays the
Just made grep across all Fedora spec files
```console
[tkloczko@pers-jacek SPECS.fedora]$ grep SPECPARTS *
python-bidict.spec:# SPECPARTS dir in %%_builddir/%%buildsubdir is leaking to
setuptools package
python-bidict.spec:rm -rf SPECPARTS
python-cairocffi.spec:- Drop rmdir SPECPARTS
python-chao
Just found in inbox that another maintainer sorted out issue related to create
directory in python module source tree
https://github.com/PyGithub/PyGithub/pull/2894. As you see fixing that it is
not rocket science ..
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-
> @kloczek , this is not about SPECPARTS although if you _look_ at the PR,
> that's one of the issues that gets solved by this. See #2532 for the
> background.
On first look it looks like it is `setuptools` issue. .. like in other python
modules cases (which I've mention here).
--
Reply to th
Looks like po/POTFILES.in is not up-to-date and translators as well are not
aware that some updates needs to be added 😋
```console
[tkloczko@pers-jacek x86_64-redhat-linux-gnu]$ make update-pot -C po
make: Entering directory
'/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu/po'
> Oh, and just to clarify, in the case of 4.19.1.1, we did _not_ intend to
> update the translations in that release at all, which is why this issue
> wasn't caught yet.
Just FTR: updating translations should be be part of the (pre)release process.
Email addresses taken from each .po files shoul
I know that this option is not mentioned anywhere in documentation however IMO
it should be present to be able not only define from command line macro using
`--define foo` but as well undefine it if it is present in global or spec
macros.
So this is I've decided to raise this not as RFE but issu
> --define and --undefine execute long before the spec is parsed, so while they
> can affect the way a spec is parsed, neither can affect a macro defined
> inside a spec.
Please have look one more time on my examples.
`--define` IS working and at the same time `--undefine` IS NOT working so it
> No, read what I wrote more carefully. Neither --define or --undefine can
> affect a macro _defined inside a spec_.
> Both can affect the parse, and cause things to be defined or undefined, but
> only wrt macros that are defined before the macro is parsed.
Please have look ONE MORE time on spec
> No, it doesn't.
Can you show your executios of commands executions which I've provided?
Did you try to reproduce what I've done? 🤔
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2939#discussioncomment-8618693
You are receiving
Yeah .. looks like that remove files listed in NoSource: NoPatch: is not
performed when --rmsource is used.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3037
You are receiving this because you are subscribed to this thread.
Message
Looks like if it is something like:
```
%prep
%autosetup -a1 -a2 -a3
```
only Source0 and Source1 will be unpacked. Probably it will be necessary to
copy some parts from %setup so theoretically it should be easy to fix.
--
You are receiving this because you are subscribed to this thread.
Reply
It happens when binary is linked with static library located in other directory.
Part of the rpm elfutils posintall:
```
/usr/lib/rpm/sepdebugcrcfix: Updated 22 CRC32s, 0 CRC32s did match.
cpio: debuginfod/printversion.c: Cannot stat: No such file or directory
cpio: libasm/eblelfclass.c: Cannot s
No just in other directory than directory in which is linked library or
executable.
For example first missing file from above list is in
`elfutils-0.179/lib/printversion.c` and all binaries which re stripped during
post installation comes from `elfutils-0.179/src'
--
You are receiving this bec
Just repeated elfutils build but with disabled LTO.
Looks like it is issue with finding source files only when LTO is used.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issu
In attachment are all elf binaries of my current elfutils package
[elfutils-0.179-with_LTO.tar.gz](https://github.com/rpm-software-management/rpm/files/4595957/elfutils-0.179-with_LTO.tar.gz)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
htt
I thik that it would be good to add mapping ~ part of the version to
%{PREVERSION} macro if version string contains ~.
It will allow standarise using that mechanisms across all spec files.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view i
I'm not sure exactly name like `%{PREVERSION}`.
Maybe `%{NONREL}`?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1321#issuecomment-663854518_
Just in case: I can try to implemt that but if you will like that idea first it
would be good to agree on some exact name/mechanics.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/
Any update or progress?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1207#issuecomment-663857170___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
Closed #1321.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1321#event-3594576273___
Rpm-maint mailing list
Rpm-maint@lists.r
Closing.
After few experiments I founfd that using `~` in version for non-release builds
makes spec files more complicated so curretly it does not simplifies anything.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://
Building my own gnome-tour I found strange case.
After `%meson_install` binary gnome-tour binary is not stripped but after `post
installation of course it is stripped but there is no debug info file and by
this buid fails.
```
+ /usr/bin/meson install -C x86_64-redhat-linux-gnu --no-rebuild
Inst
If it would true all my meson builds would be reporting the same issue.
```
$ rpm -E %meson
export CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redh
I've spend a bit more time on that case and I think that you may be actually
right
https://gitlab.gnome.org/GNOME/gnome-tour/-/issues/24
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-managem
I've started experimenting with lxc and I'm trying to make some rpm database
queries from outside lxc zone using `-r `.
Looks like it is some issue with that option:
```
[root@barrel ~]# lxc-attach -n fedora -- rpm -qa | wc -l
329
```
So using lxc to execute command inside zone it works however:
`
Look one more time on what I've copied. I've been executing rpm from root user.
Issue is that despite some files have been stat()ed and opened nothing is
displayed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://git
You can try that even without container by for example what I just did:
```
$ mkdir -p var/lib/rpm; cp -r /var/lib/rpm var/lib/rpm; rpm -r
$(pwd)/var/lib/rpm -qavv
ufdio: 1 reads,17654 total bytes in 0.11 secs
ufdio: 1 reads, 5557 total bytes in 0.02 secs
ufdio: 1
Of course it doesn't wortk as well from root.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1372#issuecomment-699851585___
Rp
Of course it doesn't wortk as well from root.
```
[root@barrel ~]# mkdir -p var/lib/rpm; cp -r /var/lib/rpm var/lib/rpm; rpm -r
$(pwd)/var/lib/rpm -qavv
ufdio: 1 reads,17654 total bytes in 0.10 secs
ufdio: 1 reads, 5557 total bytes in 0.03 secs
ufdio: 1 reads,
I don't think that rpm should be doing anything using chroot() for simple query.
To make query all what needs to be done is just add base root path (for
/var/lib/rpm, /etc/rpm and /var/lib/rpm as well).
On install/upgrade/remove the same if will be done from non-root current checks
is uid=0 is IM
Still it does not work ..
```
[root@barrel ~]# rm -rf var; mkdir -p var/lib/rpm; cp -r /var/lib/rpm
var/lib/rpm; rpm -qa -r $(pwd) -vv
ufdio: 1 reads,17654 total bytes in 0.10 secs
ufdio: 1 reads, 5557 total bytes in 0.03 secs
ufdio: 1 reads,17654 total bytes
Looks like something has changed in test suite and after suzessfull build
package standard %clean section cannot remove build tree:
```
Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.4Q0rn7
+ umask 022
+ cd /home/tkloczko/rpmbuild/BUILD
+ rm -rf rpm-4.16.0
rm: cannot remove 'rpm-4.16.0/tests/test
IMO better woud be just do that chmod as last unit of the test suite.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1382#issuecomment-703469613_
As I wrote chmod at the end shout not harm any test units.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1382#issuecomment-703473925_
.. because test suite not always will be executed by rpmbuild.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1382#issuecomment-703470941_
I'm still struglling with access to the database of the LXC zone using --dbpath
or --root.
You wrote that you been able to use rpm on such cases with --dbpath.
Could you please c&p some example how you ar doing that?
--
You are receiving this because you are subscribed to this thread.
Reply to
At the moment fedora `%pytes` ant `%ox` are udsing paths in %{builroot} and in
many cases there is no other way to perform `%check` than using `%{builroot}`
tree
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://githu
It doent matter what is using and how.
Changing order of the `check` and `%insytall` does not fixes or improves
anything and may cause **only** problems.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm
Just please "If it ain't broke, don't fix it".
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1618#issuecomment-814813292___
Rpm
Look slike rpm still is mot fully cleaned for autoconf 2.71
```console
+ autoreconf -fiv
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: running: autopoint --force
Copying file m4/codeset.m4
Copying file m4/fcntl-o.m4
Copying file m4/glibc2.m4
Copying file m4/glibc21.m4
Those warnings can be fixed and using older version of autoconf still will be
fine.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1785#issuecomment-926497383___
According to
https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
it is possible to define in .ttr files dependencies generators.
That works.
As long as .attr files defines macros I've been thinking that this will mean
that such macros meybe is possible to define dire
That is OK (do I was not wrong) .. what do you think about create RFE? 🤔
IMO especially such dependecy generator for `provides` would be usefull. IMO it
would be godd to be able define different dependencies generators per
sunbpackage so this is why I've been thinking about something like `%def
Known issue https://github.com/rpm-software-management/rpm/issues/1204
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2495#issuecomment-1519134758
You are receiving this because you are subscribed to this thread.
Message ID: __
Nevertheless it is possible to hadle such cases by:
```spec
%setup -q -a1 -a2
%autopatch
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2495#issuecomment-1523607579
You are receiving this because you are subscribed to this thread.
Looks like some library (probably `gpgme`) dependency checking is missing when
source tree is configured with `-D WITH_INTERNAL_OPENPGP=ON -D WITH_OPENSSL=ON`.
I see only openssl detection in
https://github.com/rpm-software-management/rpm/blob/93ee7d9c6164467608094a7e0652a0e3d84a6715/rpmio/CMakeLi
Moment so intention is to abandon handle by rpm handle PGP signatures using
openssl routines? 🤔
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2507#issuecomment-1548003186
You are receiving this because you are subscribed to this thre
OK .. so it some unfinished wotk on that transition.
Thanks for clarification 😃
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2507#issuecomment-1548093170
You are receiving this because you are subscribed to this thread.
Message ID:
> The openssl backend builds just fine. Like @ffesti said, you have some cruft
> in your source and/or build tree that's causing the failure.
Moment so what kind of cmake params I need to pass to 4.18.90 to build with
openssl? 🤔
BTW looks like currently is used kind of messy versioning/tagging
God to know that issue of tagging/versioning in in WIP state 😋
Thx 👍
What about how to build 4.18.90 with openssl? 🤔
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2507#issuecomment-1557550368
You are receiving this because you are
> As per INSTALL:
>
> ```
> wget http://ftp.rpm.org/releases/testing/rpm-4.18.90.tar.bz2
> tar xf rpm-4.18.90.tar.bz2
> cd rpm-4.18.90
> mkdir _build
> cd _build/
> cmake -D WITH_INTERNAL_OPENPGP=ON -D WITH_OPENSSL=ON ..
> make
> ```
Please have a look one more time on the ticket description.
Exa
I'm not using ccache.
Build env is performed inside LXC zone which has been created out of only
BuldRequires.
The same effect I have outside LXC zone.
Did you check 'cmake -L" output to check what exactly have been set by cmake? 🤔
--
Reply to this email directly or view it on GitHub:
https://g
> Look, there simply are no references to those symbols in the entire source
> tree. Take a pristine copy of the source and see for yourself. I don't know
> what you're building, but those error messages can not come from building the
> pristine 4.19 alpha tarball or git master.
Are you sure?
`
Hmm .. why this PR is not using paths provides by `dbus-1.pc`? 🤔
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2530#issuecomment-1573756570
You are receiving this because you are subscribed to this thread.
Message ID: _
To be honest I have no idea why rpm source tree still cares about $RPM_*FLAGS
env variables.
%configiure, %cmake and %meson are using %set_build_flags and that macro has
nothing to do with $RPM_*_FLAGS.
If it something still uses $RPM_*FLAGS it is still some rare uncleaned case.
--
Reply to th
> @kloczek if you don't know then perhaps you should find out before making
> such statements.
As I wrote %set_build_flags is using $CFLAGS, $CXXFLAGS, $LDFLAGS, $NM, $CC,
$CXX and so on because those env variables comes with meson, GNU, autotools,
cmake and even plain make.
If some project is
Someone have been trying to construct rpm query format string to produce for
example `rpm -qa` packages names and versions as json? 🤔
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2547
You are receiving this because you are sub
During almost +20 years of using rpm I've never had such needs.
`%exclude` so far was enough.
-1
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2555#issuecomment-1609161572
You are receiving this because you are subscribed to this thre
I would like to see something more like pk11 format
```spec
SourceCSum: sha256://
```
Which would allow use different checksums algorithms.
Or as second argument of the `Source:`
```spec
Source: sha256://
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-
> I think that makes it really tricky with ordering (is it applying to the next
> source or the previous one? and what if there are conditionals around source
> lines?). imho really not very intuitive as it is very context dependent.
Currentpy you can use:
```spec
Source: file1
Source: file2
.
.
> This is an orthogonal discussion. you can have multiple variants in both
> suggestions of mine (also in the fragmet suffix)
Maybe you din't notice but I've proposed not one but two variants.
Main point which I've added is to use pk11 like csum format. From that point of
view everything from my
You can do that by `rpmbuild --define "%_buildhost " `
or you can put permanentny line in ~/.rpmmacros like "%_buildhost ".
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2603#issuecomment-1665426860
You are receiving this because you
I want only point that %optflags could be used in %check.
I don not remember even one case when such change would be necessary.
👎
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2615#issuecomment-1678625213
You are receiving this because
Introduction of `CheckRequires` which will be working as same as
`BuildRequires` but skipped when executed with `--no-check` would be useful.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2631#issuecomment-1694277030
You are receiving
Just started refreshing my rpm package with rpm to latest version and found
that despite run cmake with `ENABLE_TESTSUITE=ON` ctest is not able to run any
test units
```console
+ cd rpm-4.18.99
+ /usr/bin/ctest --test-dir x86_64-redhat-linux-gnu --output-on-failure
--force-new-ctest-process -j48
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:
/home/tkloczko/rpmbu
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 '/home/tkloczko/
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
>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
+ '[' '/home/tkloczko/rpmbuild/BUILDROOT/
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 -
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 subscr
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.
Mess
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:
https://github.com/rpm-software-manage
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:
https://github.com/rpm-software-manage
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:
/home/tkloczko/rpmbuild/BUILDROOT/rpm-4.18.99-2.fc
> 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
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
${PROJECT_NAME}-${PROJECT_VERSION}-py${Python3_VERSION_MAJOR}.${Python3_VERSION_MINOR}.
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 c
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 b
> 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 t
> > 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 %cma
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:
https://github.com/rpm-software-management/rpm/pull/2651#issuecomment
1 - 100 of 133 matches
Mail list logo
