(note that reference-file-by-tag, which I did with 2nd iteration, is "perma"
enough in 99.99% cases)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Good point, I think updating this is a prereq:
https://github.com/rpm-software-management/dnf/blob/master/dnf/base.py#L503-L515
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
1. as mentioned at that bug, not sure if it's fortunate to mention something
(`build-id` concept) that cannot be properly referenced, e.g. to
`rpmbuild(8)`
(closest is `tests/rpmbuild.at`: `build-id files should link to the .debug
files`),
perhaps more generic explanation would suffice,
Haven't read this all, but it seems to fit the bill wrt. use case
I tried to tackle at the mock side in the past:
https://github.com/rpm-software-management/mock/issues/11
Nice to see it's becoming a popular request, finally :-)
--
You are receiving this because you are subscribed to this
Like in `-debuginfo`, where it might further help in case of unannounced
ABI breaks?
I see the value of this also for other things, e.g., witnessed daisy
chained breakages because of particular subtle change in linker's
behaviour, thought this is covered with annotations in ELF notes
these days,
> while checking that %_isa suffix is not accidentally specified
> there, which is doable also in the macro but Lua scripting would
> be needed
Or some finalizing pass could have a look and warn if it sees something
like `foo(x86-64)(x86-64)` in whichever dependency establishing tag,
indeed, but
I actually think that `AliasProvides:` directive would be a better
alternative (allowing for original customary syntax while checking that
`%_isa` suffix is not accidentally specified there, which is doable also
in the macro but Lua scripting would be needed), though it looks like
even more loaded
This is spurred with a former naive assumption that arch-qualification
in Provides: will make any dependants (Requires:, Recommends: etc.) free
to choose whether to specify such qualifier or not, as that simply works
with direct package references (because both variants gets provided under
the
I've stumbled upon this code:
```c
if ((op == RPMRICHOP_WITH || op == RPMRICHOP_WITHOUT) && (check &
RICHPARSE_NO_WITH) != 0) {
if (emsg)
rasprintf(emsg, _("Illegal ops in with/without"));
return RPMRC_FAIL;
}
```
in contrast to:
```c
if ((op ==
Looks like a perfect timing regarding discovery and fixing
of silent issues in one of my specfiles:
```
%py_byte_compile '%{__python3} \-I'
'%{buildroot}%{_datarootdir}/%{name}/ext-plugins'
```
Why nobody told me that quotes are taken literally and only spaces/tabs
play the role in
Indeed, better yet:
```
! grep FAILED test.log
exit $? # TODO remove when rpm<4.14 compatibility irrelevant
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
How about `! grep FAILED test.log` to keep it simple?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks, hopefully nobody comes back here and complain later :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain done
--
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/pull/249#issuecomment-318161564___
Rpm-maint mailing list
Only extended the commit message:
```
build system), hence let it just simply handover the last exit status
of the executing environment prior to that point (implicit zero if
-nothing was executed).
+nothing was executed). It will also serve as a reminder to preserve
+exit status propagation in
The least nice option is to put `%define ___build_post exit $?` verbatim
to individual spec file(s). Just noting that's also a tested alternative.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
16 matches
Mail list logo
