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 m
* 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
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.
> + * 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.
> @@ -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 = sysconf(_SC_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 = sysconf(_SC_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 = sysconf(_SC_PAGESIZE)
@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 getmem_proc(
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.
> +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 getmem_proc(
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: __
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 G
This fixes a regression from automake where we also didn't 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 --
* Don't rely on pkg-config for libmagic just ye
While many distros ship a pkg-config file for Lua downstream, the upstream
source tree does not, and so we shouldn't rely on it. Turns out, CMake
provides a native Lua package, so just use that.
Unfortunately, the package doesn't define any IMPORTED target, it only does
the LUA_LIBRARIES and L
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 vie
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 beca
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
... 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:
https://github.com/rpm-software-
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 r
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:
https://github.com/rpm-s
> > 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 s
> 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 furth
> 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 eas
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 di
@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 libl
@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 libl
@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))
- m
@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))
- m
@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 libl
@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))
- m
> 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 th
@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 wit
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 ar
@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)
- ins
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:
https://github.com/rpm-software-management/rpm/pull/2467#issuecomment-150285339
... 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 becaus
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:
https://github.com/rpm-software-management/rpm/pull/2467#issuecomment-1
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 list
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 ID
@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 receiv
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: _
@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 receiv
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 CMakeLists.
@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 t
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 ne
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:
https://github.com/rpm-software-management/rpm/issues/2477#i
... 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 bec
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:
https://github.c
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 on
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:
https://github.com/rpm-software-ma
> 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
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 genera
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:
https://github.com/rpm-software-management/rpm/p
@dmnks pushed 2 commits.
e2be683d34c5aab1cf17ae3957a59780446a1130 Use CMake Lua module
ac142060b907ddeccaf844f8fc2e4ce3e9e1c603 Fix leftover "lua.h" import from days
long gone
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2469/files/c75f26eb0729ee6cf35ad5db1480ff4e
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 lib
Replace 32-bit sizes in types like off_t with 64-bits when building on 32-bit
architectures, to enable large file support there.
This fixes a nasty regression introduced in the cmake transition. As autotools
would set this flag to 64 automatically for us, applications linking against
librpm (s
Merged #2510 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2510#event-9271108448
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint maili
There's currently no guarantee that "RPM build warnings:" and the actual
warnings are printed in the right order, an example here:
https://kojipkgs.fedoraproject.org//work/tasks/2924/101252924/build.log
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-managem
> If you want to use alpha/beta/rc convention IMO you should consider use Gnome
> convention like `rpm-4.19.0.alpha` [...]
Already tracked here: https://github.com/rpm-software-management/rpm/issues/2477
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manag
I just checked the official alpha tarball and there were no grep matches for
`pgpPrtPkts` in it. Please double-check your local copy, there must be some
leftovers as mentioned previously.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues
Yup, we should probably add the flag parameter here from the start, rather than
later having to add a `glob_path()` for the flags variant :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2526#issuecomment-1566984522
You are receiv
Otherwise (whether or not you manage to come up with a way to idiomatically
pass the flags), the patch looks alright!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2526#issuecomment-1566986452
You are receiving this because you are subs
Yeah, it seems like the proposed `%rpmversion` macro would indeed be a good fit
for SPEC syntax changes in general. Having a separate version for the SPEC
format might perhaps come in handy in the future, too, but not sure.
--
Reply to this email directly or view it on GitHub:
https://github.co
How about a bitwise parameter? Like here:
https://luaposix.github.io/luaposix/modules/posix.glob.html
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2526#issuecomment-1567145896
You are receiving this because you are subscribed to this th
> Bitwise flags would be rpm-native of course, but it doesn't seem very Lua.
> Bitwise operators were only added to the language in Lua 5.3, so we'd even
> have to bump our version requirement for that.
Oh, right, I didn't think that far :smile:
> The closest thing to a "flags" argument in the
@dmnks commented on this pull request.
> @@ -883,6 +883,30 @@ static int rpm_unsplitargs(lua_State *L)
return 1;
}
+static int rpm_glob(lua_State *L)
+{
+const char *pat = luaL_checkstring(L, 1);
+rpmglobFlags flags = RPMGLOB_NONE;
+int argc = 0;
+ARGV_t argv = NULL;
+
+
@dmnks commented on this pull request.
> @@ -883,6 +883,30 @@ static int rpm_unsplitargs(lua_State *L)
return 1;
}
+static int rpm_glob(lua_State *L)
+{
+const char *pat = luaL_checkstring(L, 1);
+rpmglobFlags flags = RPMGLOB_NONE;
+int argc = 0;
+ARGV_t argv = NULL;
+
+
@dmnks commented on this pull request.
> @@ -883,6 +883,30 @@ static int rpm_unsplitargs(lua_State *L)
return 1;
}
+static int rpm_glob(lua_State *L)
+{
+const char *pat = luaL_checkstring(L, 1);
+rpmglobFlags flags = RPMGLOB_NONE;
+int argc = 0;
+ARGV_t argv = NULL;
+
+
I wonder if we could make it the default value for now (i.e. in the spirit of
#2533 basically)?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2532#issuecomment-1580266258
You are receiving this because you are subscribed to this threa
* Fix undefined symbols from plugins in some circumstances
* Revert %_smp_build_ncpus change to a parametric macro (RhBug:2210347)
* Move dbus announce plugin config to DATADIR
Details and download info at
https://rpm.org/wiki/Releases/4.19.0
--
Michal Domonkos / RPM dev team / Red Hat
This is a bug fix update to address a couple of issues found by the early
adopters of ALPHA1, mostly related to some bits and pieces missed during the
CMake transition.
Commits applied since ALPHA1:
* Have dist (and snapshot) targets automatically pull in the po submodule
* Add pgpVerif
Yup, this will find its way into 4.19 in Beta (planned for ~ end of month).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2523#issuecomment-1587284491
You are receiving this because you are subscribed to this thread.
Message ID: _
> What if we instead had a FA_REFLINK file action (supported in rpm core), and
> the plugin would 1) set this for applicable files 2) supply the necessary
> details such as what to actually reflink to?
I like this idea. In the context of `rpmFileAction`, reflinking indeed can be
seen as a file
@dmnks commented on this pull request.
> +return rc;
+}
+
+static int lookup_num(const char *path, const char *val, int vcol, int rcol,
+ long *ret)
+{
+char *buf = NULL;
+int rc = lookup_field(path, val, vcol, rcol, &buf);
+if (rc == 0) {
+ rc = stol(
@dmnks commented on this pull request.
> @@ -132,6 +132,10 @@
%_keyringpath %{_dbpath}/pubkeys/
+# Location of passwd(d) and group(5)
Typo here! Should be `passwd(5)` :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pu
@dmnks commented on this pull request.
> @@ -1454,9 +1454,9 @@ RPMDB_INIT
runroot rpmbuild -bb --quiet --define "pkg user" --define "provs %{add_sysuser
u myuser 876 - /home/myuser /bin/sh}"\
/data/SPECS/deptest.spec
-runroot rpm -U /build/RPMS/noarch/deptest-user-1.0-1.noarch.rpm 2> /dev
@dmnks commented on this pull request.
> @@ -1454,9 +1454,9 @@ RPMDB_INIT
runroot rpmbuild -bb --quiet --define "pkg user" --define "provs %{add_sysuser
u myuser 876 - /home/myuser /bin/sh}"\
/data/SPECS/deptest.spec
-runroot rpm -U /build/RPMS/noarch/deptest-user-1.0-1.noarch.rpm 2> /dev
@dmnks commented on this pull request.
> @@ -1454,9 +1454,9 @@ RPMDB_INIT
runroot rpmbuild -bb --quiet --define "pkg user" --define "provs %{add_sysuser
u myuser 876 - /home/myuser /bin/sh}"\
/data/SPECS/deptest.spec
-runroot rpm -U /build/RPMS/noarch/deptest-user-1.0-1.noarch.rpm 2> /dev
@dmnks commented on this pull request.
> @@ -1454,9 +1454,9 @@ RPMDB_INIT
runroot rpmbuild -bb --quiet --define "pkg user" --define "provs %{add_sysuser
u myuser 876 - /home/myuser /bin/sh}"\
/data/SPECS/deptest.spec
-runroot rpm -U /build/RPMS/noarch/deptest-user-1.0-1.noarch.rpm 2> /dev
Apart from the inline comments I made, the change itself looks good!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2503#issuecomment-1604564230
You are receiving this because you are subscribed to this thread.
Message ID: __
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
* Don't init plugins in Python tests
* Remove
@dmnks pushed 1 commit.
e20039effd1a16e7c47f119db1604c60e1f0949b Fixup mktree.native building
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2559/files/f6922b3ecc5d552dc727ddb4574b20ca82248912..e20039effd1a16e7c47f119db1604c60e1f0949b
You are receiving this because yo
Oops, forgot to uncomment the OS setup script in `mktree.native`. Fixed now.
And yup, I'm going to update README as well, it's one of the items on my little
TODO list before claiming this PR ready :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-man
No manual setup will be needed, though. If a native script isn't available for
your platform (currently anything else than Fedora), the usual podman fallback
will kick in (i.e. former `make ci`).
I'm also going to add back `make ci` even if you're running natively so that
one can just see how C
@pmatilai BTW, before you try 'make check` again, please run `make tree-clean`
first (or just `rm -rf tests/mktree.output`), there's currently a bug in how
this is handled :smile: To be fixed today.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management
Could you please paste the log output of those? (`rpmtests.dir/N/rpmtests.log`)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-1621188314
You are receiving this because you are subscribed to this thread.
Message ID: ___
Ugh, yup, I did test for different prefixes at the beginning but then just
settled on the default and never got to trying out a different out :smile: So
yup, we either fix the tests or add some kind of check / disclaimer to
tests/README.md.
I bet the remaining test that fails is 437. I'm seeing
Hmm that's strange, indeed. `ccache` isn't even installed in the OS tree so
it's strange that it's being poked in that test...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-1621220046
You are receiving this because you
Both :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-1621238021
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing lis
`make env` can also be useful as it gives you a shell on your host, with the
same container mounted at `$RPMTEST` so you can inspect or modify stuff in it
with your host tooling. Including DNF of course.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manag
Ohh, nice find, thanks :smile: Adding this to the TODO list above.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-1621250797
You are receiving this because you are subscribed to this thread.
Message ID:
Oh yup, thanks, that's one of those little "bugs" still to be fixed :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-1621267348
You are receiving this because you are subscribed to this thread.
Message ID: __
> It's worth noting that rpm-ostree has been isolating individual scripts (e.g.
> `%post`) with bwrap for a long time now. That's distinct from the test suite
> only usage here, but just FYI.
Interesting, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-soft
Thanks for investigating. The leakage is strange, though, as `rpmbuild` is run
in the container.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-1621311535
You are receiving this because you are subscribed to this thread
Ohh right :smile: Indeed. Let me think about it then.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-1621313814
You are receiving this because you are subscribed to this thread.
Message ID: _
Also, are we OK with the replacement of `AT_CHECK` and `AT_CLEANUP` with the
new `RPMTEST_CHECK` and `RPMTEST_CLEANUP` across the test suite?
Currently, that's what I opted for, but it's also possible to just redefine
those original macros. The caveat with the latter is that there *could*
possi
Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2561#issuecomment-1621427024
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-
701 - 800 of 1218 matches
Mail list logo
