I don't like that it doesn't output anything if neither `--biarch-deps` not
`--multiarch-deps` is provided. I think it would be better to either change the
option to `--no-biarch-deps` or at least default to biarch if neither option is
given.
--
You are receiving this because you are
Merged #1037 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/1037#event-3001783129___
Rpm-maint mailing list
The second patch does not really belong here but it's more convenient here to
avoid merge conflicts.
It is a preparation for #1028 which will need to modify when Requires will be
ignored within already installed packages.
--
You are receiving this because you are subscribed to this thread.
Erm. So we have this nice sane architecture family known as x86_64, so lets go
call it znver to make it ... more exciting? Sorry but I just don't think so.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yeah, this *functionality* really should be in rpm, should've been ages ago.
The thing is, I was about to basically add the patch originating from Suse
(later adopted by Fedora etc) multiple times but there was ... something.
Something with the details that I don't really remember, but then
Looks sane to me, but then I know absolutely nothing about this arch.
@rwmjones , any thoughts/comments?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
pmatilai commented on this pull request.
> @@ -82,12 +82,16 @@ typedef rpmFlags rpmsenseFlags;
_notpre(RPMSENSE_SCRIPT_PREUN|RPMSENSE_SCRIPT_POSTUN)
#define _UNORDERED_ONLY_MASK \
_notpre(RPMSENSE_RPMLIB|RPMSENSE_CONFIG|RPMSENSE_PRETRANS|RPMSENSE_POSTTRANS|RPMSENSE_SCRIPT_VERIFY)
pmatilai commented on this pull request.
> @@ -82,12 +82,16 @@ typedef rpmFlags rpmsenseFlags;
_notpre(RPMSENSE_SCRIPT_PREUN|RPMSENSE_SCRIPT_POSTUN)
#define _UNORDERED_ONLY_MASK \
_notpre(RPMSENSE_RPMLIB|RPMSENSE_CONFIG|RPMSENSE_PRETRANS|RPMSENSE_POSTTRANS|RPMSENSE_SCRIPT_VERIFY)
Adding @davidlt
--
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/1036#issuecomment-581346762___
Rpm-maint mailing list
@ffesti Mainly because nothing else seemed to follow that convention? They all
seemed to use the GCC machine architecture name, and so we went with that.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Ignoring the actual micro architecture, as a general principle we do not add
new assembler foo into rpm.
That there is pre-existing asm code doesn't mean it's a good idea, on the
contrary the existing stuff needs to go too but that's obviously not in the
scope here.
--
You are receiving this
@pmatilai I can fuse all three back into a single commit if you'd prefer
(that's how it was done in OMV). I broke them apart in case there was something
you'd want me to drop.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Merged #1040 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/1040#event-3001704324___
Rpm-maint mailing list
pmatilai approved this pull request.
Sure. Thanks for the patch.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Like said, the 32bit changes *must* be in a single commit. Whether the 64bit
addition is in a separate commit or not I don't really care, but it's not
necessary by any means.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@rwmjones In OpenMandriva, there was some interest in building the different
variants (including 32-bit stuff), so for a bit of future-proofing, we've gone
ahead and made the same architecture macro structure as ARM, MIPS, and POWER
have to simplify future work.
--
You are receiving this
It's not the fault of this PR but manually maintaining these arch lists in
separate macros is just so braindamaged. ARM being ARM just highlights the bad
craziness.
That aside, the new macros seem fine. However you can't rename and then add
back compatibility in two separate commits as it
I'm confused why we need the `%{riscv32}`/64/128 macros at all. They don't
seem to be necessary for this change unless there's something about how RPM
macros work which I don't understand.
The `%{riscv}` macro seems as if it would be useful to mean "all RISC-V
architectures". Although I will
@pmatilai The addition of this new architecture name is because we need a way
to declare incompatibility at the RPM level for CPUs that don't support it.
This is pretty much the only way we can do it. When this was first being worked
on, nobody seemed to think there was any better way to do
@ffesti pushed 1 commit.
5e4bdb7ede59198a9fa921dbbab0219f7a6800b2 Add reqIgnoreIfInstalled macro
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Fixed typo in second patch.
--
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/1031#issuecomment-581376633___
Rpm-maint mailing
... which is not to say that I'm opposing this change, just pointing out some
stuff.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I've melded the 32-bit ARM macro updates into one commit, as requested.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think one of the questions is: Why doesn't the name start with x86_64 or at
least something closer to that?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Retrieval from memory reels being even more sluggish than usual today, but one
of my concerns might've been related to using a script template in the first
place: this can be overridden by distros and individual packages, so putting it
into rpm doesn't actually *ensure* anything at all. Every
For the latter commit, you'll want to do s/Ingore/Ignore/ for both the
description and the patch itself.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
See also commit a429c99e13fbe9926243f29b78df8d64222c4469 for db3.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1040
-- Commit Summary --
* Permit ndb database queries on read-only media
-- File Changes --
M
pmatilai commented on this pull request.
> @@ -82,12 +82,16 @@ typedef rpmFlags rpmsenseFlags;
_notpre(RPMSENSE_SCRIPT_PREUN|RPMSENSE_SCRIPT_POSTUN)
#define _UNORDERED_ONLY_MASK \
_notpre(RPMSENSE_RPMLIB|RPMSENSE_CONFIG|RPMSENSE_PRETRANS|RPMSENSE_POSTTRANS|RPMSENSE_SCRIPT_VERIFY)
Forgot to mention. OpenEmbedded already supports riscv32 IIRC and it also
supports RPM packaging.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe This should be good to look at again. :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@Conan-Kudo Fair enough. Could you please open an issue for that? And perhaps
include additional details, preferably a use case that you encountered in the
past that would be easier with this feature?
--
You are receiving this because you are subscribed to this thread.
Reply to this email
32b is a thing even if some distributions don't have current plans to support
it. It might be especially popular in buildroot and OpenEmbedded for embedded
Linux based RV32 systems, but that markets could be more complicated. I mean
most of such available soft cores probably don't support
@Conan-Kudo pushed 1 commit.
f7ce837d5b6ed7663ce5774c6507fde6731436fe elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@mlschroe I've added a default to enable biarch when neither option is set.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+
The %patch -P leak was fixed differently in commit
29d70efb1d9b2161f3fcdbdf71945d6c7308432d already, for the rest I submitted PR
#1041 to deal with them all in one go.
Sorry for the slow process and thanks for the patch!
--
You are receiving this because you are subscribed to this thread.
@Conan-Kudo pushed 1 commit.
7532c16153a793d516989f7b0cec622e85c10b33 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Conan-Kudo commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+
@pmatilai @ffesti This doesn't seem to be working as intended. :(
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> since rpm >= 4.6, %{buildroot} is guaranteed to be defined to non-empty,
> non-"/" value so the tests are fairly redundant
The fact that SUSE continues to introduce those checks in _new_ stuff in
current versions of RPM makes me nervous about this property, so I kept the
safeguard in anyway.
mlschroe commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+ if
Conan-Kudo commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+
> The fact that SUSE continues to introduce those checks in _new_ stuff in
> current versions of RPM makes me nervous about this property, so I kept the
> safeguard in anyway.
Bad habits die hard :wink:
--
You are receiving this because you are subscribed to this thread.
Reply to this email
This can be used to recover as much data as possibly from a terminally broken
database. It is currently only supported for the ndb database.
This method is currently hidden from the API by using a macro to select salvage
mode. If it should be more exposed, we can add a rpmtsSalvageDB() method.
This is based on #874 but uses readManifest() instead of separate code for
reading the files.
The first patch adds support for STRIP_TRAILINGSPACE for readManifest() which
was missing previously (although widely used).
You can view, comment on, or merge this pull request online at:
Merged #1041 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/1041#event-3002820650___
Rpm-maint mailing list
popt always returned malloced memory for POPT_ARG_STRING items, but
for whatever historical reason rpm systematically passed const char *
pointers as targets, making them look non-freeable. Besides changing
just the types and adding free()s, const-correctness requires extra
tweaks as theres mixed
@Conan-Kudo pushed 1 commit.
b79056006456be9a923b2dc17c789f35fce2b3a8 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@pmatilai pushed 1 commit.
b334b1d8812fd9002de7bad448a25d7416cdc8cc Fix POPT_ARG_STRING memleaks in
librpmbuild
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@ffesti pointed that processPolicies() popts in a loop, so it was still leaky.
Should be fixed now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@spotrh : If you are not comfortable posting the mail from Mr Estes here you
can also forward it to pmatilai or myself.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1036 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/1036#event-3005044854___
Rpm-maint mailing list
${RPM_BUILD_ROOT} is an environment variable in the shell to be run,
%{dirname:...} is a macro which gets expanded before the shell runs.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
53 matches
Mail list logo
