OK, seems like all the comments are now addressed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-1308622418
You are receiving this because you are subscribed to this thread.
Message ID:
Hmm, this looks like a good candidate for a treatment similar to #2383, i.e.
suppressing these warnings into a single one with a count.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2419#issuecomment-1460429925
You are receiving this
> If you want to trim your budget more:
>
> * the check-buildroot cleanups, that script has been there for > 20 years
> without those changes...
Oh, truly. Let me drop that, too, then. One can never be overly conservative
with updates :smile:
> * split testing population into a
Another update, this time removing the following:
8a74780c0 check-buildroot: harden $tmp creation
fb6ad2c74 check-buildroot script: use if-then-else
f2b4c647c check-buildroot: Redirect xargs stderr to $tmp
11458278a check-buildroot script: Double-Quote the variables
fd3ef9b09 check-buildroot
@dmnks pushed 78 commits.
2c0459a25aa9174373bb514bd8bb4246b03b56c0 Document need to do history research
on behavior changes
49b5fffd958c532497d7e223ff1c9429e9f31a17 Add more on pull requests to
CONTRIBUTING
dae67690507ef192d64b0029105614615418293a Fix potential uninitialized variable
use in
* Plugin fixes (fapolicyd and selinux)
* Various OpenPGP and macro parser fixes
Details and download info at
https://rpm.org/wiki/Releases/4.18.1
--
Michal Domonkos / RPM dev team / Red Hat, Inc.
___
Rpm-maint mailing list
Rpm-maint
Note on the
[`dist-hook`](https://github.com/rpm-software-management/rpm/blob/35c62dce0a327600bc0d947a8c01cc649c6e8646/Makefile.am#L289)
target in `Makefile.am` which generates the `ChangeLog` file (when we migrate
this one to cmake):
When checking whether we're in a git checkout, we should
@dmnks pushed 79 commits.
f4400993780890a37ccad9856340946bb7f9b0c5 Generate Python egg-info from
automake builds
6432673bb96761d41905bd741d7028a2d10cba4d Document need to do history research
on behavior changes
ca4406bd3f6793389de8cb1c9982eefeb4e137c9 Add more on pull requests to
Merged #2406 into rpm-4.18.x.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2406#event-8732507709
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Oh, well... Commit e31fb5b75898bfa09180dba02475c6d01764d94f already was on the
`rpm-4.18.x` branch :facepalm: So we need to make the above change a separate
commit.
--
Reply to this email directly or view it on GitHub:
One last fixup: amend upstream commit e31fb5b75898bfa09180dba02475c6d01764d94f
so that `Home-page` in the newly added `rpm.egg-info.in` is hardcoded (we don't
define `@PACKAGE_URL@` so the field would've been empty).
--
Reply to this email directly or view it on GitHub:
@dmnks commented on this pull request.
> @@ -1174,6 +1177,89 @@ static void doShescape(MacroBuf mb, rpmMacroEntry me,
> ARGV_t argv, size_t *parse
mbAppend(mb, '\'');
}
+static unsigned long getmem_total(void)
+{
+unsigned long mem = 0;
+long int pagesize =
Other than the above, the overall changeset looks sane to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2418#issuecomment-1479932861
You are receiving this because you are subscribed to this thread.
Message ID:
@dmnks commented on this pull request.
> + * Conservative estimates for thread use on 32bit systems where address
+ * space is an issue: 2GB for bare metal, 3GB for a 32bit process
+ * on a 64bit system.
+ */
+if (thread) {
+ unsigned long vmem = mem;
+#if __WORDSIZE
@dmnks commented on this pull request.
> + * Conservative estimates for thread use on 32bit systems where address
+ * space is an issue: 2GB for bare metal, 3GB for a 32bit process
+ * on a 64bit system.
+ */
+if (thread) {
+ unsigned long vmem = mem;
+#if __WORDSIZE
@dmnks commented on this pull request.
> +long int pagesize = sysconf(_SC_PAGESIZE);
+long int pages = sysconf(_SC_PHYS_PAGES);
+
+if (pagesize < 0)
+ pagesize = 4096;
+if (pages > 0)
+ mem = pages * pagesize;
+
+return mem;
+}
+
+static unsigned long
@dmnks commented on this pull request.
> @@ -1174,6 +1177,89 @@ static void doShescape(MacroBuf mb, rpmMacroEntry me,
> ARGV_t argv, size_t *parse
mbAppend(mb, '\'');
}
+static unsigned long getmem_total(void)
+{
+unsigned long mem = 0;
+long int pagesize =
@dmnks commented on this pull request.
> @@ -1174,6 +1177,89 @@ static void doShescape(MacroBuf mb, rpmMacroEntry me,
> ARGV_t argv, size_t *parse
mbAppend(mb, '\'');
}
+static unsigned long getmem_total(void)
+{
+unsigned long mem = 0;
+long int pagesize =
Not too late, really, it's actually just in time! Let's pick these `rpmsign`
fixes too, then, they seem to be important enough for some folks and are
regression fixes so typically a good choice for a maintenance update. Thanks
for the note, @eaon!
--
Reply to this email directly or view it on
Should we also consider #2408?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2406#issuecomment-1461930609
You are receiving this because you are subscribed to this thread.
Message ID: ___
@dmnks pushed 80 commits.
506d4e600de99a010884724b782b1538e51f66bf Permit building rpm from git without
pandoc
d964136eb221306cb3c1c2e0a2ce3bb06c295308 Add a handler for libselinux log
messages (RhBug:2123719, RhBug:2050774)
c5b73532e98cca1a00f0804da94a64c404d0cdb7 Split testing population
I decided to go through the picks once again and *actually* view them from the
"is this an important bugfix" perspective, and removed a couple of less
important commits as a result, namely these:
c4eb357fe Drop a leftover mcheck.h include
4eb26a828 Drop redundant _GNU_SOURCE definitions from
Oh, and I'll also drop b0c9b3d87 since that's not needed to fix the intended
regression, as per #2344.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2406#issuecomment-1462018833
You are receiving this because you are subscribed to this
@dmnks pushed 56 commits.
53733da3609df63557c035717faa18249cc6523e Make %_smp_mflags build rather than
parse time determined
df6359235215095f6a93993393320f59aad2cec8 Fix rpmkeys type confusion test.
8c7029da19ffe724001be361456725374fa5e47e Enable malloc checking with random
perturb in the
OK, changes pushed, dropping the following ones:
b0c9b3d87 Calculate number of threads to use during build, not spec parse
d0867bcea Fix OpenMP enablement in librpmbuild (broken by cmake transition)
37ec18d86 Fix silent wait when missing input RPM package
The second one is a noop without the
I suppose the "iff" was there intentionally, as a (commonly used) shorthand "if
and only if" but correct me if I'm wrong.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2427#issuecomment-1469707490
You are receiving this because you are
@dmnks commented on this pull request.
> @@ -450,6 +448,20 @@ int parsePrep(rpmSpec spec)
}
exit:
+/* Issue a warning for deprecated %patchN usage */
+int num = spec->numConverted;
+if (num) {
+ const char *msg =
+ _("%%patchN is deprecated, use %%patch N (or
OK, time to make the first 4.18 maintenance update, please let me know if the
commit selection works for you. The focus is, as always, on important bugfixes,
regressions and security fixes.
Note that I deliberately stopped the selection process at commit 1f47b1cc0 to
keep the amount of changes
Makes sense, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2406#issuecomment-1453149586
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
How about this one?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2388#issuecomment-1441612623
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
@dmnks pushed 1 commit.
ec34dba06c97d2b17263c91fc7af43f45f050271 Don't repeat %patchN deprecation
warning
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2388/files/37c84fae30c7a5a2985e2a50f090a0e5ab8f68c6..ec34dba06c97d2b17263c91fc7af43f45f050271
You are receiving
When fakechroot is called with FAKECHROOT_BASE and HOME both pointed at the
same directory (as is the case with our test suite, see the file
tests/atlocal.in), the pattern ~ gets expanded by glob() to the
empty string. However, this wasnt the case back when we bundled our own
glob()
Actually, instead of passing the prefix to the test suite, we could just use
`%_rpmmacrodir`, but nah, I've already decided to go with a backport instead
:smile:
--
Reply to this email directly or view it on GitHub:
Ugh, this breaks the actual test, what? :confused: Investigating...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2401#issuecomment-1446550510
You are receiving this because you are subscribed to this thread.
Message ID:
OK, so this is because the non-tilde macro paths depend on the install prefix,
and we don't currently pass it to the test suite. While it would be quite easy
to add, at that point, I'm thinking it would be more appropriate to only
include this patch on the respective stable branches, after all.
@dmnks pushed 1 commit.
07388f7709866a997c12a1d642f9c14e2754d66b Fix a test relying on glibc version
of glob(3)
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2401/files/2c154b31bc5d7582115fe908a527d6f2ff970c97..07388f7709866a997c12a1d642f9c14e2754d66b
You are
Closed #2401.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2401#event-8617644470
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
@dmnks pushed 1 commit.
37c84fae30c7a5a2985e2a50f090a0e5ab8f68c6 Suppress repeated %patchN deprecation
warnings
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2388/files/ab7c577f08f3eece2f9d3c48f5cc4c5d39e14693..37c84fae30c7a5a2985e2a50f090a0e5ab8f68c6
You are
OK, reworked based on:
> A simple alternative would be adding a special purpose counter to the spec
> struct, and log a message based on that towards the end of parsePrep() where
> you can then also log the number of times emitted.
This simple solution will unblock the 4.18.1 release. Later,
Yup, we may suggest that upstream. In the interim, until/if that's implemented
on their side, let's just go with the custom imported target as mentioned
above. I'll update this PR accordingly.
--
Reply to this email directly or view it on GitHub:
@dmnks pushed 2 commits.
e2be683d34c5aab1cf17ae3957a59780446a1130 Use CMake Lua module
ac142060b907ddeccaf844f8fc2e4ce3e9e1c603 Fix leftover "lua.h" import from days
long gone
--
View it on GitHub:
OK, reworked to an imported target.
Note that we can't use `IMPORTED_LOCATION` as with e.g. libmagic since there
can be multiple libraries to link against, all available via `LUA_LIBRARIES`.
Instead, define an "imported interface" which seems like a better fit, anyway.
I'll probably rework
@dmnks commented on this pull request.
> pkg_check_modules(READLINE IMPORTED_TARGET readline)
pkg_check_modules(ZSTD IMPORTED_TARGET libzstd>=1.3.8)
pkg_check_modules(LIBELF IMPORTED_TARGET libelf)
pkg_check_modules(LIBDW IMPORTED_TARGET libdw)
pkg_check_modules(LIBLZMA IMPORTED_TARGET
Just discussed this in a chat - moving the targets to `docs/man/CMakeLists.txt`
would actually mean separating the `man` target from the `apidocs` one (which
doesn't even have such a hardcoded list of `html` files), thus making all this
necessarily more complicated...
--
Reply to this email
@dmnks commented on this pull request.
> pkg_check_modules(READLINE IMPORTED_TARGET readline)
pkg_check_modules(ZSTD IMPORTED_TARGET libzstd>=1.3.8)
pkg_check_modules(LIBELF IMPORTED_TARGET libelf)
pkg_check_modules(LIBDW IMPORTED_TARGET libdw)
pkg_check_modules(LIBLZMA IMPORTED_TARGET
> It seems pretty simple, see (otherwise unrelated) #2472
Oh, thanks! I'll just do the same here, then.
> I'm starting to think we should make this a policy of handling external
> libraries as imported targets everywhere, it's so much nicer...
Yup, seems reasonable and keeps the cmake files
@dmnks commented on this pull request.
> @@ -194,11 +194,14 @@ endif()
if (WITH_IMAEVM)
list(APPEND REQFUNCS lsetxattr)
- find_path(IMA_INCLUDE_DIR NAMES imaevm.h)
- find_library(IMA_LIBRARY NAMES imaevm)
- if (NOT (IMA_INCLUDE_DIR AND IMA_LIBRARY))
-
> OTOH, those targets are already separated, and there is that reason to keep
> them separated (if we drop the rm)...
Oh, truly... :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2467#issuecomment-1498709912
You are receiving
@dmnks commented on this pull request.
> pkg_check_modules(READLINE IMPORTED_TARGET readline)
pkg_check_modules(ZSTD IMPORTED_TARGET libzstd>=1.3.8)
pkg_check_modules(LIBELF IMPORTED_TARGET libelf)
pkg_check_modules(LIBDW IMPORTED_TARGET libdw)
pkg_check_modules(LIBLZMA IMPORTED_TARGET
@dmnks commented on this pull request.
> @@ -194,11 +194,14 @@ endif()
if (WITH_IMAEVM)
list(APPEND REQFUNCS lsetxattr)
- find_path(IMA_INCLUDE_DIR NAMES imaevm.h)
- find_library(IMA_LIBRARY NAMES imaevm)
- if (NOT (IMA_INCLUDE_DIR AND IMA_LIBRARY))
-
@dmnks commented on this pull request.
> @@ -194,11 +194,14 @@ endif()
if (WITH_IMAEVM)
list(APPEND REQFUNCS lsetxattr)
- find_path(IMA_INCLUDE_DIR NAMES imaevm.h)
- find_library(IMA_LIBRARY NAMES imaevm)
- if (NOT (IMA_INCLUDE_DIR AND IMA_LIBRARY))
-
@dmnks commented on this pull request.
> @@ -30,6 +30,7 @@ option(WITH_DBUS "Build with DBUS support" ON)
option(WITH_AUDIT "Build with audit support" ON)
option(WITH_FSVERITY "Build with fsverity support" OFF)
option(WITH_IMAEVM "Build with IMA support" OFF)
+option(WITH_FAPOLICYD "Build
@dmnks commented on this pull request.
> if (EXISTS ${PANDOC})
add_custom_command(OUTPUT ${man} COMMAND ${PANDOC}
${CMAKE_CURRENT_SOURCE_DIR}/${man}.md
-s -t man -o ${man} DEPENDS ${man}.md)
-
It seems like the man pages aren't copied to the build directory when building
from a dist tarball and not having pandoc installed. (The html files are,
though.)
--
Reply to this email directly or view it on GitHub:
Indeed :+1:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2467#issuecomment-1502914674
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing
@dmnks pushed 1 commit.
1fdb30946c4f6c1b6d3ca5b66ab3e72dc88ed587 Handle IMA as an imported target,
take II
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2475/files/7797193e0ab320f70b359a984c3a81f5b5818661..1fdb30946c4f6c1b6d3ca5b66ab3e72dc88ed587
You are receiving
Another attempt at commit 7184fb80137363e39d79e2b5a0eb2c4fb060cc2e.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2475
-- Commit Summary --
* Handle IMA as an imported target, take II
-- File Changes --
M
Thinking about it more, there really is no point in copying the docs to the
builddir in the case of a tarball-based build, so please disregard my above
comments :smile:
--
Reply to this email directly or view it on GitHub:
@dmnks pushed 1 commit.
53bf68a3c6f54164ef330953ab5066e4b97c8f8e Don't rely on pkg-config for libmagic
just yet
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2468/files/ebf33aaee5e02020b6d48485e58653e91ce1a3e3..53bf68a3c6f54164ef330953ab5066e4b97c8f8e
You are
OK, ran this locally myself and seems to be working as expected, well done
:smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2467#issuecomment-1502915732
You are receiving this because you are subscribed to this thread.
Message
@dmnks pushed 1 commit.
ebf33aaee5e02020b6d48485e58653e91ce1a3e3 Don't rely on pkg-config for libmagic
just yet
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2468/files/94e2a6628918fbd5cb30addf1d4b967743810423..ebf33aaee5e02020b6d48485e58653e91ce1a3e3
You are
OK, imported target it is, and using REQUIRED now that we're on 3.18 :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2468#issuecomment-1503040475
You are receiving this because you are subscribed to this thread.
Message ID:
... which may be intentional, though, as they're only meant to be copied to
destdir when installing, I suppose (?) (which they are)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2467#issuecomment-1502857495
You are receiving this
Maybe we could just keep the `4.18.90` version for these pre-releases, or
perhaps something like `4.18.90.1` for alpha1, `4.18.90.2` for alpha2, etc.
then `4.18.91` for beta1, etc.
--
Reply to this email directly or view it on GitHub:
It seems like our original pre-release numbering, e.g. `4.19.0-alpha1`, isn't
compatible with the format of `CMAKE_VERSION`, which only allows integers in
the version components, and optionally takes the `-rc` suffix.
Possibly related: https://gitlab.kitware.com/cmake/cmake/-/issues/16716
We
OK, re-reading the docs, our original format *actually* should be legal, the
`-rc` is there just as an example of how CMake itself does it. Yet, none of
that seems to be working for me... I also tried putting the whole string in
quotes but no dice.
--
Reply to this email directly or view it
Crap... Of course it doesn't work, `CMAKE_VERSION` is for the CMake version,
not the project's version :facepalm:
The correct docs are here:
https://cmake.org/cmake/help/latest/command/project.html#options
--
Reply to this email directly or view it on GitHub:
... or just keep `4.18.90` and increment the fourth component for each
pre-release, regardless of whether it's an alpha, beta or rc.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2477#issuecomment-1503586306
You are receiving this
Lastly, according to the
[docs](https://cmake.org/cmake/help/v3.18/variable/CMAKE_VERSION.html), the
following should also be valid:
`4.18.20231104-alpha1`
However, that doesn't work for me for some reason (CMake 3.26 here).
--
Reply to this email directly or view it on GitHub:
> Let's stick with the number approach for the alpha and sort out the bigger
> versioning question for the beta
Ack :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2477#issuecomment-1504941632
You are receiving this because
Oh, this is indeed nicer :smile: I think we can merge now but I'll leave it
open over the (extended) weekend just in case somebody else wants to chime in.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2467#issuecomment-1499109310
You
While many distros ship a pkg-config file for Lua downstream, the upstream
source tree does not, and so we shouldnt rely on it. Turns out, CMake
provides a native Lua package, so just use that.
Unfortunately, the package doesnt define any IMPORTED target, it only does
the LUA_LIBRARIES and
This fixes a regression from automake where we also didnt use pkg-config
for libmagic.
Fixes: #2246
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2468
-- Commit Summary --
* Dont rely on pkg-config for libmagic just yet
I'm not entirely sure about the `#include ` vs. `#include "lua.h"` thing
here. It does seem more appropriate and consistent to use the bracket style for
external libraries. Let me know your thoughts, I can drop that part from the
commit if needed :smile:
--
Reply to this email directly or
Hmm, so the CI failure doesn't seem to have anything to do with this commit.
The same podman image passes just fine for me locally...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2469#issuecomment-1497696590
You are receiving this
... and the same test passes on the very same VM that the CI job ran on (I've
checked manually using the SSH feature in Semaphore). Seems like we've got a
new random false negative in our test suite... :cry:
--
Reply to this email directly or view it on GitHub:
Also note that any of my above points can be addressed later, they're not
things preventing this PR from merging, in my opinion, as it's good enough just
as is, especially now that we're about to start the releasing.
--
Reply to this email directly or view it on GitHub:
It's this error in test 423 (Dependency generation 3), has anyone seen this
before?
```
error: Illegal char '*' (0x2a) in: *
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2469#issuecomment-1497698026
You are receiving this because
OK, it's not the prettiest piece of code but it does the job, at least for the
foreseeable future, in case somebody finds a more elegant solution :smile:
Just two questions:
* Is there any use of having the man and apidocs archives separate? We remove
both afterwards, anyway, so they won't be
@dmnks commented on this pull request.
> +long int pagesize = sysconf(_SC_PAGESIZE);
+long int pages = sysconf(_SC_PHYS_PAGES);
+
+if (pagesize < 0)
+ pagesize = 4096;
+if (pages > 0)
+ mem = pages * pagesize;
+
+return mem;
+}
+
+static unsigned long
OK, I can confirm the new push fixes the `proc` calculation, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2418#issuecomment-1485189177
You are receiving this because you are subscribed to this thread.
Message ID:
> > Fix #include lines to use "lua.h" instead of as per
> > cmake-modules(7):
>
> The actual issue in the FindLua doc is cautioning against `#include
> ` because of the `lua/` _directory_ is not standardized. The
> guidance to use "lua.h" seems quite odd, as quotes imply per-project files
> Other than that... why oh why doesn't the FindLua module implement an IMPORT
> interface
Yeah, I was quite disappointed to learn that, too. The actual "user interface"
is thus no prettier than a plain `find_library()` approach.
> We could do that by ourselves though, imported interfaces are
> Not really. I developed the man part first and then it seemed natural to do
> the html docs separately and then ended up wondering about the same very
> thing. A potential reason to not combine is the ability to just take the docs
> tarball and unpack into http://ftp.rpm.org/api/ with no
FTR, the `mv(1)` command works around this by simply recursively copying the
directory and removing the old one. Therefore, the workaround is as simple as
doing:
```
# cd /usr/lib/sysimage
# cp -r rpm rpmold.1
# rm -rf rpm
# rpmdb --rebuilddb
```
--
Reply to this email directly or view it on
What better time of year than April to release an Alpha!
This pre-release brings a couple of quality-of-life features and improvements
for packagers, most notably:
* New spec snippet support for dynamic spec file generation [1]
* New sysusers.d(5) integration for automated user and group
What better time of year than April to release an Alpha!
This pre-release brings a couple of quality-of-life features and improvements
for packagers, most notably:
* New spec snippet
[support](https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html)
for dynamic spec file
Just noting that this may need to be revisited after #1580.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2241#issuecomment-1420624196
You are receiving this because you are subscribed to this thread.
Message ID:
Let's not go overboard with these warnings (there's currently one printed per
each `%patchN` line). One should suffice :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2383
You are receiving this because you are subscribed to
Related to #2352.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2383#issuecomment-1420779208
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
> Static variables are best avoided, for one they wont work correctly for the
> case where you query/build multiple specs on a single run.
Argh... The multi-spec case somehow didn't occur to me... yet it's pretty
obvious :sweat_smile:
> A simple alternative would be adding a special purpose
Avoid polluting the build log with this warning repeated as many times as there
are %patchN lines. Once per build should be enough for the packager to notice
(theres also a warning summary now).
Basically, make the warning context-independent, meaning that it doesnt
matter which line caused
This is how the alternative rpmlog-native solution might look like:
https://github.com/dmnks/rpm/commit/37a28123977570f4eb0a2162e2d73bd9529f95dd
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2388#issuecomment-1422668146
You are
This is the final batch before #2559.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2568
-- Commit Summary --
* Add sandbox exec command
* Remove needless HOME override in tests
* Add RPMTREE variable to tests
*
Rebased onto master, now cleaning up and squashing.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2559
-- Commit Summary --
* Add and use RPMTEST_CHECK* and RPMTEST_CLEANUP
* Dont init plugins in Python tests
* Remove
@dmnks commented on this pull request.
> fi
}
function sandbox()
{
-(unset RPM_CONFIGDIR RPM_POPTEXEC_PATH
- cd ${RPMTEST} && \
- FAKECHROOT_BASE="${RPMTEST}" fakechroot "$@"
-)
+local cmd=$1
+shift
+case $cmd in
+exec)
+(unset
@dmnks commented on this pull request.
> @@ -27,7 +29,7 @@ else
exit
fi
-RPMTEST="@CMAKE_CURRENT_BINARY_DIR@/testing"
+RPMTEST=$RPMTREE
Ugh, you're right. Not that I wasn't aware, but I'm kinda sloppy when it comes
to quoting in my own changes. I just consider quotes too noisy to
@dmnks commented on this pull request.
> fi
}
function sandbox()
{
-(unset RPM_CONFIGDIR RPM_POPTEXEC_PATH
- cd ${RPMTEST} && \
- FAKECHROOT_BASE="${RPMTEST}" fakechroot "$@"
-)
+local cmd=$1
+shift
+case $cmd in
+exec)
+(unset
@dmnks commented on this pull request.
> RPM_CONFIGDIR=${RPMTEST}/@RPM_CONFIGDIR@
-export RPMTEST HOME RPM_CONFIGDIR
+export RPMTEST RPM_CONFIGDIR
Oh-oh, again, you're right. On one hand, we do override a bunch of paths like
`_topdir` in `run()` but you can never be
@dmnks pushed 5 commits.
4413f80ea0afe002db3a01e4845d909ba2822c58 Add RPMTREE variable to tests
f31b62e83ac0179d2cf05df369ebf44dbc9b88c5 Rename testing/ to tree/ in tests
b5d2af4d740a35edf9fb09d0aa0f6d9c10cfbc3a Turn populate into mktree
ea3981134bf71b84040c7acc6beb4866a483ffdd Create the
501 - 600 of 1032 matches
Mail list logo
