_The --set-utc (-Z) option causes patch to set a patched file’s modification
and access times to the timestamps given in context diff headers._
=>
behavior of diff file without date header
_patch normally refrains from setting a file’s timestamps if the file’s
original last-modified timestamp
I don't believe it's that easy if you don't already have a `.attr` file. It
doesn't look to me as if RPM will look at `%__foo_magic` or `%_foo_provides`
unless it sees `%_fileattrsdir/foo.attr` first. Of course, you could override
`%_fileattrsdir` instead, but then you would have to copy the
I do think this could be useful if it would serve to reduce packager workload,
though the trend seems to be moving away from scriptlets in general.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks, all. In the meantime the bizarre extra Provides: bit doesn't really
hurt anything.
One interesting side effect is that I'm not sure anything in Fedora would
actually ever validate any of the installed pkgconf files. I wonder if this is
a reasonable candidate for a brp script. (It
I tested `patch -Z` on my local using this repository's README file.
I created below 2 files based on a result of `diff -u`.
I expected the patched file is updated as fixed value.
But actually on below cases, it is updated as system date even when using
`patch -Z`.
Just implementing `patch -Z`
Commit d53499d1565dd7ba6d93939e552cc604b26dccd7 makes rpmbuild use %_build_cpu
instead of %_target_cpu for valid architecture testing if the target_cpu is
noarch.
On most architecture this works well, but there are cases with unexpected
results. Our ppc64le rpm has _host_cpu and thus
pkgconf 1.6.3 will warn when malformed versions are provided:
```
kaniini@nanabozho:~/pkgconf$ ./pkgconf --validate
tests/lib1/malformed-version.pc
tests/lib1/malformed-version.pc:2: warning: malformed version field with
whitespace, trimming to [3.922]
```
since this is a problem with
That sounds good to me.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/789#issuecomment-510851979___
Rpm-maint mailing list
> The other question is whether this should be added to _default_patch_flags in
> the long run.
This is the best solution for me if we can add it to the _default_patch_flags.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/790
-- Commit Summary --
* Add support for 'patch -Z'
-- File Changes --
M build/parsePrep.c (15)
-- Patch Links --
I think it may make sense to change pkgconf to explicitly strip anything after
a whitespace character in the version. that would solve this issue and also
make sure other automatic generators don't do something bad when they encounter
something ridiculous like this. I'll release 1.6.3 today
spaces are not valid in the version string. this will parse as 3.922 in
comparisons.
in a dependency list,
```
Depends: verilator = 3.922 2018-03-17
```
will parse as:
```
[
["verilator", "=", "3.922"],
["2018-03-17"]
]
```
hope that helps.
--
You are receiving this because you are
The other question is whether this should be added to _default_patch_flags in
the long run. So instead of packager adding it all over the place it can be
enabled globally. Probably in some distribution first before changing the
upstream default.
--
You are receiving this because you are
This is awful... And yes, I don't see any place which would say that spaces are
forbidden. However, I don't know how pkgconf or such would compare such
versions... @kaniini?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
14 matches
Mail list logo
