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
> 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
> 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
> --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
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
> 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
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'
> @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
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-
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
> 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
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
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
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
**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
> ```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
#
> 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
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: ___
> 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
> (..) 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
> 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
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
> 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
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-
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
On requests is reported NET::ERR_CERT_COMMON_NAME_INVALID
```console
NET::ERR_CERT_COMMON_NAME_INVALID
Subject: *.osuosl.org
Issuer: InCommon RSA Server CA
Expires on: 14 Aug 2024
Current date: 28 Nov 2023
PEM encoded chain:
-BEGIN CERTIFICATE-
MIIGqDCCBZCgAwIBAgIRALyLan5HduQddO9zEyf77a
License details are in Licence: field.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2778#issuecomment-1822460400
You are receiving this because you are subscribed to this thread.
Message ID: __
Do you have any suggestion why in my case cmake is not installing pytom module
in `%{python3_sitearch}`? 🤔
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2650#issuecomment-1713690481
You are receiving this because you are subscribed t
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
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:
https://github.com/rp
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 python-fastavro-1.8.3-2.fc35
> $ 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 n
> > 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? 🤔
-
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
# - CMAKE_*_FLAGS_R
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
> > 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
> 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
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
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
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}.
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
> 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} \
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
> 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
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
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}}
```
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
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
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
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 -
>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 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
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/
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
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
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
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
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
> 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
> 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
.
.
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-
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
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
> @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
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
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: _
> 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?
`
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
> 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
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
> 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
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:
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
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
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.
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: __
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
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
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___
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
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
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
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
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
.. 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_
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_
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_
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
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
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
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,
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
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
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
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:
`
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
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
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
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://
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
1 - 100 of 133 matches
Mail list logo
