Merged #3003 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3003#event-12268442379
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Doxygen is absolutely not required for building rpm, its only required for
building dist tarballs which come with the documentation pre-built.
Fixes: 26a1ccf2819ab148aef3cd354e1cbdb70a9fe5b7
You can view, comment on, or merge this pull request online at:
@mlschroe pushed 1 commit.
c9579db452e4d4c6996d30419889f831c15c68b3 Support clamping the file mtime to
the build time
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944/files/be088c0aa13707a14962d649823b696b3d5a2c7e..c9579db452e4d4c6996d30419889f831c15c68b3
You are
@pmatilai commented on this pull request.
> @@ -240,10 +240,12 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%use_source_date_epoch_as_buildtime 0
-# If true, make sure that timestamps in built rpms
-#
I've updated the pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#issuecomment-2023034485
You are receiving this because you are subscribed to this thread.
Message ID: ___
@mlschroe pushed 1 commit.
be088c0aa13707a14962d649823b696b3d5a2c7e Support clamping the file mtime to
the build time
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944/files/ee365274c42530286a09dad1fc83144ef478b25a..be088c0aa13707a14962d649823b696b3d5a2c7e
You are
The new %(auto)setup -C option complements the declarative buildsystem very
nicely: this is a trivial detail, dont bother the packager. While we
cant default to it everywhere, Buildsystem is a great opportunity to do so.
Suggested-by: Miro Hrončok m...@hroncok.cz
Fixes: #2998
You can view,
Ah, ok, so this works, but not for the `%endif`. I cannot say I grasped it from
the documentation update :/
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#issuecomment-2022749958
You are receiving this because you are subscribed to
@pmatilai commented on this pull request.
> @@ -246,8 +246,8 @@ static int expandMacrosInSpecBuf(rpmSpec spec, int strip)
if ((condition) && (!condition->withArgs)) {
const char *s = lbuf + condition->textLen;
SKIPSPACE(s);
- if (s[0])
-
> > `%dnl` already works for this purpose, doesn't it?
>
> It doesn't, because this check happens before macro expansion.
This fails:
~~~
$ cat license-subpackages.spec
Summary: Demonstration package for mining licenses from subpackages
Name: license-subpackages
Version: 1
Release: 1%{?dist}
Closed #829 as completed via #2996.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/829#event-12265396820
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #2996 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#event-12265396584
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@pmatilai commented on this pull request.
> @@ -246,8 +246,8 @@ static int expandMacrosInSpecBuf(rpmSpec spec, int strip)
if ((condition) && (!condition->withArgs)) {
const char *s = lbuf + condition->textLen;
SKIPSPACE(s);
- if (s[0])
-
**Describe the bug**
A clear and concise description of what the bug is.
Importing a key with User-ID removed (like those of
[keys.openpgp.org](https://keys.openpgp.org/)) causes RPM to segfault
**To Reproduce**
Steps to reproduce the behavior:
1. Start condition e.g. installed packages
2.
Merged #2999 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2999#event-12264507348
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
A bigger problem is that this doesn't actually work. As in, add the users into
the groups on install. The "receiving" code does not know to look for these
new provides so they end up being just decoration.
What you don't test does not work, is a good rule of thumb :smile:
--
Reply to this
Merged #3000 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3000#event-12263647886
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Theres no reason each of these needs to perform their own test setup and
cleanup when theyre not even writing anything. Doesnt change what
gets tested, just less useless chatter in the test output.
You can view, comment on, or merge this pull request online at:
@ffesti commented on this pull request.
> @@ -246,8 +246,8 @@ static int expandMacrosInSpecBuf(rpmSpec spec, int strip)
if ((condition) && (!condition->withArgs)) {
const char *s = lbuf + condition->textLen;
SKIPSPACE(s);
- if (s[0])
- rpmlog(RPMLOG_WARNING,
@pmatilai commented on this pull request.
> @@ -246,8 +246,8 @@ static int expandMacrosInSpecBuf(rpmSpec spec, int strip)
if ((condition) && (!condition->withArgs)) {
const char *s = lbuf + condition->textLen;
SKIPSPACE(s);
- if (s[0])
-
Oh and, a proper commit message for the main change. The how and why are quite
a bit more complicated than "Create Requires/Recommends for both the user and
the group."
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -38,9 +41,10 @@ to weaken these into recommends-dependencies by setting
## Limitations
-At this time, rpm only supports the `u` and `g` directives of sysusers.d
-format and ignores others. If other directives are needed, the package
-will need
@ffesti pushed 1 commit.
fc4c5ef5aaae4a0e360cde24c13647ef4ed8be16 Make junk after conditionals an error
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996/files/6bbb6a39e662d32fa0876c3cafcb091509200c09..fc4c5ef5aaae4a0e360cde24c13647ef4ed8be16
You are receiving this
@pmatilai commented on this pull request.
> if arg[1] == 'g' then
type = 'group'
elseif arg[1] == 'u' then
type = 'user'
-elseif arg[1] == 'r' or arg[1] == 'm' then
+elseif arg[1] == 'm' and #arg >=3 then
+type = 'usergroup'
'groupmember' might be a
@pmatilai commented on this pull request.
> +goto continue
+end
+fields = {}
+for w in line:gmatch("%S+") do
+table.insert(fields, w)
+end
+if #fields >= 3 and fields[1] == 'm' then
+
@pmatilai commented on this pull request.
> @@ -246,8 +246,8 @@ static int expandMacrosInSpecBuf(rpmSpec spec, int strip)
if ((condition) && (!condition->withArgs)) {
const char *s = lbuf + condition->textLen;
SKIPSPACE(s);
- if (s[0])
-
> `%dnl` already works for this purpose, doesn't it?
It doesn't, because this check happens before macro expansion.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#issuecomment-2022362161
You are receiving this because you are
Commit e5d7a823c99b84d65ecbf3810b68aab372ef5d14 broke builds relying on libtool
(and no doubt some others as well) because libtool redirects stdin in some of
its tests and this fails if stdin is closed. Instead of closing, pass the
write-only end of the pipe as the stdin to build scriptlets.
`%dnl` already works for this purpose, doesn't it?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#issuecomment-2022331640
You are receiving this because you are subscribed to this thread.
Message ID:
Done.
@dmnks: This needs to go into the compatibility notes of the 4.20 release.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#issuecomment-2022305618
You are receiving this because you are subscribed to this thread.
Message ID:
Just realized that one problem is that RPM knows nothing about the actual
content of the `License` tag, therefore it would not be easy to "just merge
them" into single field, if needed.
--
Reply to this email directly or view it on GitHub:
Yeah, (looking into) populating SOURCERPM early was what I meant with fixing at
the source. Based on a quick look, you could just move SOURCERPM insertion from
processBinaryFiles() to, say, finalizeSpec() and be done with it with equal
amount of work, without adding duplicate special paths.
--
On that note, don't hesitate to point out shortcomings or other new related
ideas. I'm too close to the source (in both meanings :smile: ) to see clearly,
as the -C example points out.
--
Reply to this email directly or view it on GitHub:
Oh yup, thanks for filing this! The auto directory patch landed just after the
buildsystem work so it kinda went under the radar, but it should complement the
buildsystem work very nicely indeed.
--
Reply to this email directly or view it on GitHub:
Lets worry about the other stuff separately, this is the thing that hurts the
most by far because it used to work, even if for the wrong reasons.
Making non-comments an error now that we do allow comments is indeed the right
thing to do :+1:
--
Reply to this email directly or view it on
35 matches
Mail list logo
