This is similar to #, but I read the conclusion there as "the RPM team
won't bend over backwards to support an OS that isn't POSIX complaint," which
makes perfect sense to me. Now, macOS has added the missing POSIX function
described in that issue, but 4.20 won't build for different reasons:
Merged #2806 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2806#event-11211977757
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
For normal debug output the basename of the files are sufficient as when
debugging is enabled the directories are also printed. But here the warning is
given without a debug flag so we need the full context right there.
You can view, comment on, or merge this pull request online at:
https://gi
I also updated the README to make it a bit more clear.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#issuecomment-1850090417
You are receiving this because you are subscribed to this thread.
Message ID:
OK, in the end I went with simply `pinned`. When I was updating the commit, it
became apparent "mutable" just didn't fit well in the context, and also clashed
with the other meaning I'd mentioned...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management
@dmnks pushed 1 commit.
42b6792c91dd951e21ab37485955fa68195009cd Add support for "pinned" tests
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803/files/2973e1957638cae6807783ee6f50e13b248164f9..42b6792c91dd951e21ab37485955fa68195009cd
You are receiving this because
Yup, annoyingly as well as amusingly long :smile: But as a rule of thumb,
naming make targets after the "artifacts" they produce rather than the "action"
they do is always better, at least IMO (of course we don't follow that
precisely but that's fine).
--
Reply to this email directly or view i
Yeah, mutable and immutable are generic concepts and used in multiple places
already. So if you really want to pinpoint it, "update-mutable-tests" :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#issuecomment-1849773127
You a
Oh! That's a pretty good idea! :smile:
... except that "mutable" is already used in the test context. But - that
doesn't matter much, I suppose. It's a lower-level detail that's relevant when
*writing* a test. Otherwise, "mutable" is indeed the best fit.
So, let's just go with that.
--
Reply
Leafing through the mental dictionary of handy words...
Mutable! It fits the bill pretty perfectly as these results are *expected to
change* at certain times, whereas all the other tests do not. So perhaps
"update-mutable"?
--
Reply to this email directly or view it on GitHub:
https://github.
And perhaps, if we were to put all the test-related targets behind the "check-"
prefix, then "check-update"...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#issuecomment-1849711377
You are receiving this because you are subscribed
... which makes me think about another target name: update-tests :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#issuecomment-1849710161
You are receiving this because you are subscribed to this thread.
Message ID: _
The idea behind this kind of tests is basically this: We need to *track* the
expected output in the repository so that we ensure it's always the same when
running the given test, which is why don't just dynamically determine the
expected output at test-runtime. At the same time, we need this out
"version-diff" indeed is perhaps closer to what it does, however it just
happens that these tests depend on the version. There might as well be other
tests (in the future) that depend on some other baked-in value.
"release-prep" is similarly too generic because this really is just about the
tes
Added docs for the global defaults + some other tweaks in that department, and
added a cmake buildsystem example.
I think this is ready to go now. As with any new feature there's likely to be
some rough edges, but those are best found in hands of the users rather than
sitting in a draft somewh
@pmatilai commented on this pull request.
> @@ -1352,5 +1352,16 @@ end
end
}
+# buildsystem defaults
+%buildsystem_default_prep() %autosetup -p1
Documented in the last push.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#
@pmatilai commented on this pull request.
> +%buildsystem_python_build
+```
+
+## Supporting new build systems
+
+Supporting new build system types is just a matter of declaring a few
+macros for the build scriptlet sections relevant to the build system.
+
+Scriptlet | Mandatory
@pmatilai pushed 4 commits.
03dfaa56dd67073cbbe27fd125167bc79acda55c Extract static tests for easier
release bumps
a939bee8957e01ba8ece72c16727909f94d138fb Use rpmSpecGetSection() internally
where appropriate
159a96eff15edd4defb52399b22f7edaffbfb354 Store spec section string buffers as
an ar
18 matches
Mail list logo
