The downside is that old releases don't honor RPMSENSE_MISSINGOK in src.rpm
rpmlib() checking, that two-liner patch needs to be backported to relevant
releases. OTOH, rpm2cpio can always be used to extract contents so nobody is
held hostage.
As noted in the commits, this is just the
Merged #901 into master.
--
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/901#event-2739806558___
Rpm-maint mailing list
@pmatilai Ugh... I guess the alternative is figuring out what rpmrc does and
implementing it in debbuild for the debrc file to translate rpm arches to deb
arches. I was hoping I wasn't going to have to go there, since rpmrc is
functionally undocumented and I have no idea what the behavior of
pmatilai approved this pull request.
Okay, we're down to reverting just two things that even I can see being harmful:
1) According to #425, the armv8 architectures were added mostly for symmetry
with armv7 which is an entirely different beast, but turns out this actually
breaks things.
2)
Anyway, there *will* be a bugfix release to 4.15.x soonish, there's a handful
of fairly critical things that needs addressing. I mean, it is a .0 release...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
TBH, the thought of reverting the whole damn threading business has crossed my
mind more than once by now, it is (quite expectedly) proving painful. I've
resisted the temptation so far...
The thing is that this hasn't been an issue on Fedora *at all*, AFAIK. If we
just disable without
Let's work together and sort the problem. If you would like me to run
additional diagnostics, I'd be happy to help.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Replaced by #914.
--
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/878#issuecomment-545846866___
Rpm-maint mailing list
Closed #878.
--
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/878#event-2740154684___
Rpm-maint mailing list
Details in the commit messages, executive summary:
- Packages are not permitted to provide rpmlib() capabilities, so dont
(the use-case is covered by other means)
- src.rpm requires are generally build-time requires, rpmlib() is the odd man
out. Mark build-time rpmlib() dependencies with
@Conan-Kudo , for the reason pointed out above, there can be no "arm64" ->
"aarch64" translation in rpm, contrary to what I said earlier about it seeming
like a reasonable compromise.
What I can accept is an "arm64" macro which includes all the 64bit Arm
architectures similar in spirit to
Olaf, are you going to make this change in SUSE first?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes I've noticed that some dependencies are no longer being generated
correctly, and quite likely we should extend this to `*.cmxs`. However I don't
really have time to test a change right now as I'm preparing for 2 full weeks
of conferences and meetings.
--
You are receiving this because
I don't know how to answer the question of whether they're supposed to be
standalone, but I can tell you what they are.
They are compiled OCaml native code shared libraries (the equivalent of C
`*.so` files). I believe they are in fact simply `*.so` files renamed and
perhaps with some
Right, the checks for magic_open() and magic_load() will just fall through with
errors if openmp is disabled, but at least those are "environmental" issues
rather than something in the package currently being built. The more important
error handling in the loop should still work, only it
Sure. Will replace the greppery with awkery.
--
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/913#issuecomment-545881682___
One the other hand: are these cmxs files are really supposed to be stand-alone?
If they were in the -devel.rpm along with their cm* siblings, the issue would
not exist.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This looks like a good solution - especially if we backport the
RPMSENSE_MISSINGOK change to older version.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@rwmjones , care to comment?
--
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/913#issuecomment-545857738___
Rpm-maint mailing
@mlschroe - given the recent resurgence in ndb activity, just thought to
mention this so we're clear: removing the EXPERIMENTAL tag on ndb is going to
be up to you and I'm going to trust your judgement on that.
--
You are receiving this because you are subscribed to this thread.
Reply to this
@pmatilai If #908 is accepted, can we also pull this PR into rpm 4.15?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo approved this pull request.
It's a decent compromise, code-wise looks sane too.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
22 matches
Mail list logo
