> > When `checkSep(EVR, '-', emsg)` or `checkSep(EVR, ':', emsg)` or
> > `checkEpoch(EVR, emsg)` returns RPMRC_FAIL, and
> > `_wrong_version_format_terminate_build` is defined as 0, the checkDep()
> > will returns RPMRC_OK and emsg is set.
>
> Oh, indeed. We could just remove _wrong_version_for
Yes, I agree with you. When there are too many submissions in a PR, one
problematic submission will block other submissions. Considering that the
repair code is simple and is a leak problem of rpmbuild, I put them in a PR to
prevent too many PRs.
--
Reply to this email directly or view it on G
IST) {
+ rpmlog(RPMLOG_WARNING, "xujing: %8s (%s [%d]) %s\n", __func__,
+ dest, fd, (rc < 0 ? strerror(errno) : ""));
+ fd = openat(dirfd, dest, O_WRONLY|O_CREAT, 0200);
+}
+
if (fd < 0)
rc = RPMERR_OPEN_FAILED;
```
--
Reply to this email di
I tried to modify the %install and the installation still failed, but it was
due to symlink failure.
```
%install
mkdir %{buildroot}/sbin/
touch %{buildroot}/sbin/aaa
%if %{with sbinsymlinks}
mkdir -p %{buildroot}/usr/sbin/
cd %{buildroot}/usr/sbin/
ln -sv ../../sbin/aaa .
%endif
```
```
[root@lo
I reconfirmed the rpmrebuild code. The spec file automatically generated by
rpmrebuild does not configure defattr. It seems that this scenario does not
exist unless manually configured.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1
I ran test cases using rpm-4.18.0 and found one test case failed:
```
...
357: rpm -e and shared files removed 1.1 ok
358: rpm -e and shared files removed 1.2 ok
359: rpm -e and verify colored files removed 1.1 ok
360: rpm -e and verify colored files removed 1.2 ok
3
I tried to manually execute the test case and found that verifying conflicta
and conflictb alone was as expected.
```
[root@localhost testing]#
FAKECHROOT_BASE=/root/rpmbuild/BUILD/rpm-4.18.0/tests/rpmtests.dir/363/testing
fakechroot rpm --define "_buildhost testhost" --define "_topdir /build"
I get the same results as you, without -- force.
```
[root@localhost ~]# rpm -ivh /tmp/test-1.0-1.noarch.rpm
Verifying... # [100%]
Preparing... # [100%]
file /usr/sbin/aaa conflicts between attempted installs of test-1.0-1.noarch
and
When Non-privileged user was used to build the "rpm" package, the file deletion
failed during the final rmbuild cleanup phase. The problem is caused by the
lack of write permission on the testing directory.
```
...
[ 209s] Checking for unpackaged file(s): /usr/lib/rpm/check-files
/home/abuild/rp
It is confirmed that this problem is caused by
b34333fa021c0ee7215714eeef96d1a2843ea08e.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2380#issuecomment-1418443920
You are receiving this because you are subscribed to this thread.
Mes
When I try to add a plugin that uses strcmp, a core occurs. The stack is as
follows:
```
#0 ...
#1 rpmpluginsCallFsmFilePost()
#2 fsmDoMkdir()
#3 ensureDir()
#4 rpmPackageFilesInstall()
#5 rpmpsmUnpack()
...
#13 rpmInstall()
#14 main()
```
I tried to analyze it and found that the second parameter
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2612
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://li
After the c5f82d3f6223ebd0c5cc0a07ea60393ae7284929 is integrated, the SIGTERM
signal is blocked. When the installation or uninstallation script is executed,
the script is suspended if an infinite loop occurs. For example, if the script
is `"timeout 20 tail --pid=1 -f /dev/null"`. Theoretically,
I found that cb6aa82dbc10d554f8d234e934ae7c77e39a3ce2 fixed the problem.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2738#issuecomment-1785249430
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2738 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2738#event-10808097119
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
Fedora：
Fedora release 39 (Thirty Nine)
Version：
rpm-4.19.0-1.fc39.aarch64
Reproduction Procedure：
1. mkdir /root/repo && cd repo
2. creating a list of RPM packages to be downloaded:
```
[root@localhost repo]# cat list
abseil-cpp
c-ares
cyrus-sasl-lib
gflags
glibc-common
gnutls
grpc
http-parser
l
According to the preliminary analysis, this problem may be caused by the
patches for fixing CVE-2021-35939,CVE-2021-35938,CVE-2021-35937. After I roll
back to the version before fixing CVE-2021-35939,CVE-2021-35938,CVE-2021-35937,
the problem cannot be reproduced.
--
Reply to this email direct
According to the current code running effect, when one RPM process uses
`--dbpath` but the other does not, the transaction lock does not seem to work,
resulting in real concurrent execution.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/iss
If RPM does not allow this scenario, can we consider returning an error in
advance or optimize the transaction lock? For example, make the transaction
lock global and not affected by `--dbpath`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm
@JetXujing pushed 1 commit.
1f071c8f73006ce12d021f2e7062e4a1e504b2ad Check the validity of hash algo
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3416/files/75e64330aa964d145470e6e3b39d62ca6822..1f071c8f73006ce12d021f2e7062e4a1e504b2ad
You are receiving this bec
If an RPM package has been signed and the hash algorithm is not supported by
the current version, no error is reported during the verification of the RPM
package, and "$?" return 0. Fix this problem.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-softwar
> What verification are you talking about, specifically? The term is overloaded
> in multiple places around rpm...
>
> If an unknown algorithm causes us to give an OK to an unverifiable signature
> then we obviously do have a rather bug someplace.
If xxx.rpm has been signed (Assume that the has
@JetXujing pushed 1 commit.
8a22a51af8e9f7de274f49c3a392ba0af66f4ff2 Check the validity of hash algo
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3416/files/1f071c8f73006ce12d021f2e7062e4a1e504b2ad..8a22a51af8e9f7de274f49c3a392ba0af66f4ff2
You are receiving this bec
Closed #3295 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3295#event-14303602606
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
Oh, I see, I didn't think about it: AT_XFAIL_IF will be removed if
https://github.com/rpm-software-management/rpm/issues/1800 is fixed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3295#issuecomment-2357841440
You are receiving this
@JetXujing pushed 1 commit.
9d9f9a56dba6e5a161643cf99ecb2bfda58eccd8 Fix memleak when process policies
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3301/files/7a178ead29a3b548fe0a45e9fcdba25551f3f729..9d9f9a56dba6e5a161643cf99ecb2bfda58eccd8
You are receiving this b
This is what I found by static analysis of the code.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3301#issuecomment-2360363424
You are receiving this because you are subscribed to this thread.
Message ID: __
@JetXujing pushed 1 commit.
d4fc6aa1633cf60ee6cd287296b106b1f212d7a7 Fix memleak when process policies
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3301/files/9d9f9a56dba6e5a161643cf99ecb2bfda58eccd8..d4fc6aa1633cf60ee6cd287296b106b1f212d7a7
You are receiving this b
@JetXujing pushed 1 commit.
fbd3079a023e7e8d99375d79bb31d536bdfdfd2b Fix memleak when process policies
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3301/files/d4fc6aa1633cf60ee6cd287296b106b1f212d7a7..fbd3079a023e7e8d99375d79bb31d536bdfdfd2b
You are receiving this b
@JetXujing pushed 1 commit.
44fe8cbb65ecefdd866c4e8717228ec82b4c92cd Fix memleak when process policies
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3301/files/fbd3079a023e7e8d99375d79bb31d536bdfdfd2b..44fe8cbb65ecefdd866c4e8717228ec82b4c92cd
You are receiving this b
> What version of popt is that? Oh, at least the man page is wrong on that, it
> claims void but the actual header (on popt 1.19) is:
>
> ```
> /**
> * Destroy context.
> * @param con context
> * @return NULL always
> */
> poptContext poptFreeContext( poptContext con);
> This will fix a leak on early exit or case of single policy, but it should
> additionally be freed in the for-loop.
Yes, it should be freed in the for-loop
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3301#issuecomment-2360369409
Y
> You don't need to test against NULL, and you can just assign like this, it
> always returns NULL for this very purpose: `optCon = poptFreeContext(optCon)`
Thank you for your review comments. The poptFreeContext function has no return
value, is the usage of `optCon = poptFreeContext(optCon)` re
@JetXujing commented on this pull request.
> @@ -298,6 +299,9 @@ static rpmRC processPolicies(rpmSpec spec, Package pkg,
> int test)
free(name);
free(types);
+if (optCon)
done
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm
101 - 134 of 134 matches
Mail list logo
