@ffesti Thanks!
--
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/406#issuecomment-370615751___
Rpm-maint mailing list
Apologies for the deleted comment.
Meanwhile twisting in concepts of "compatible arch" strings including aliasing
in all its flaming glories is going to open a world of buggy painfulness even
if narrowly limited to what you are calling "self-updates".
The circumstances where a system-wide
See usage confusion at #363
--
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/409#issuecomment-370544954___
Rpm-maint mailing
The test should be done earlier against the table of builtins as well as the
macro definitions.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Try removing the leading '?', and note that the added documentation explicitly
says "file" not pattern.
You can verify the load (or attempt) by using "strace -e open"
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Of course, that was just test. So I did different one:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index c9ff8dc..ecc5e93 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -102,8 +102,7 @@ Source14: test_systemtap.rb
# The load directive is supported since RPM 4.12, i.e. F21+. The build process
```
+%{?load:%{_rpmmacrodir}/macros.*}
```
This is redundant... RPM already does this...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This passes:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index c9ff8dc..3748781 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -104,6 +104,7 @@ Source14: test_systemtap.rb
# fails on older Fedoras.
%{?load:%{SOURCE4}}
%{?load:%{SOURCE5}}
+%{?load:%{_rpmmacrodir}/macros.*}
# Fix
Just quick test:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index c9ff8dc..fc2e68b 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -104,6 +104,7 @@ Source14: test_systemtap.rb
# fails on older Fedoras.
%{?load:%{SOURCE4}}
%{?load:%{SOURCE5}}
+%{load:%{_rpmmacrodir}/*}
# Fix ruby_version
Ok, so I can imagine I put this into every SCL meta package, but then I have a
few questions.
* Does the load macro support the wild cards?
* What happens if there is no such macro file? Does it fail or just continue?
--
You are receiving this because you are subscribed to this thread.
Reply
@voxik No, no no. You can put the macros wherever, just have a `%{load:..}`
directive that points to it.
If I remember correctly, you can also do something like
`%{load:/opt///rpm/macros.d/macros.*}` to load it.
However, you have to be careful, since if the macros don't exist, the spec will
Okay, changed to the x* versions and now redundant error handling removed.
Hopefully didn't break anything, but it *seems* really straightforward...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #357.
--
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/357#event-1504397124___
Rpm-maint mailing list
I am disappointed. Many people calls SCL being big hack, but you won't make it
any easier :(
So if I read it correctly, the suggestion is that scl-utils should put
something into ```%{_rpmmacrodir}``` (please note that the collection itself
are generally not allowed to put anything outside
No, that's fine. We can also remove the code that is not needed in rpm (i.e.
the non-rpmxdb code in rpmidx).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe ping, mind if we change ndb to use the rpm "native" xmalloc() etc
that never fail?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I guess this was always more a matter of missing documentation than missing
feature.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #363.
--
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/363#event-1504309831___
Rpm-maint mailing list
Ok, I pushed the first and the last patch as a sign of good will.
The problem here is that librpm (which rpmstrPool is part of) but also
librpmbuild are libraries that might be used in applications running other
threading implementations.
Also rpm already uses pthread - although not very
This issue once was https://github.com/rpm-software-management/rpm/pull/253
When you have foo-1-1.i586 installed and you do 'rpm -U foo-1-1.i686', rpm will
not add an erase element for the i586 package.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
OK, this has not made progress for nearly a year. While there may be some use
in further thinking about this the current patch does just not cut it. I am
closing this for now.
Feel free to continue the discussion on the mailing list or in a new, improved
PR.
--
You are receiving this because
Closed #176.
--
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/176#event-1504075897___
Rpm-maint mailing list
Half a year later, there's still no fakechroot upstream release with the
relevant fix in it. Not exactly a huge surprise since the latest release is
from 2016.
We can reconsider when they finally cut that release. In the meanwhile, see my
earlier comment about nftw()...
--
You are receiving
Closed #253.
--
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/253#event-1504048274___
Rpm-maint mailing list
Looks like the patch content and the commit message do not match (or it does
not explain things well enough) and there are also some pieces missing. I am
closing this for now. Feel free to reopen a PR with a complete set of changes
and improved commit messages.
--
You are receiving this
Closed #406 via 6ba887683b4bf9712be00a3d5dcaa890bfce47c1.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks for the patch! Pushed with the surrounding "if defined" guard.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/407#issuecomment-370391017___
Closed #407 via 86ec4c03de2b7cc6af6ba5b10dd686002e0b588c.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/407#event-1503893852___
Rpm-maint mailing
The longer I think about this RFE the more I think it is a bad idea. I am
closing this now. Feel free to reopen if there is a good use case and includes
a spec file of an existing package.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
Closed #376.
--
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/376#event-1503869934___
Rpm-maint mailing list
---
tools/debugedit.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/debugedit.c b/tools/debugedit.c
index e0b1d98d99..57cd83030f 100644
--- a/tools/debugedit.c
+++ b/tools/debugedit.c
@@ -1947,6 +1947,12 @@ edit_dwarf2 (DSO *dso)
if (rtype != R_68K_32)
(Huh, SUSE carries has a patch like that? Weird. We don't use it for sure.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/407
-- Commit Summary --
* debugedit: handle RISC-V relocation
-- File Changes --
M tools/debugedit.c (4)
-- Patch Links --
33 matches
Mail list logo
