> > FWICT, the auxiliary vector for HWCAPS is no longer really used and
> > applications (including glibc, gcc runtime code) have to resort to methods
> > like this instead.
>
> It's one thing for gcc and glibc getting their hands dirty with details and
> maybe to always get the latest info you
> FWICT, the auxiliary vector for HWCAPS is no longer really used and
> applications (including glibc, gcc runtime code) have to resort to methods
> like this instead.
It's one thing for gcc and glibc getting their hands dirty with details and
maybe to always get the latest info you need to d
@pmatilai commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64 pro
Merged #2316 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2316#event-7996115863
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint maili
Yes, I'm aware of this inconsistency, there are many more places in header.c
that still mix int vs uint besides just regionSwab(). It's basically waiting
for the one last effort to go through the remaining cases, on the previous
round I ran out of steam after unifying the various header entry pa
Err, no. The fread() is what initializes the buffer up to count bytes.
Accessing the array beyond count would be buggy of course.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2317#issuecomment-1343943704
You are receiving this because
Closed #2317.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2317#event-7996060486
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm-
static int isSpecFile(const char * specfile)
{
char buf[256];
-
count = fread(buf, sizeof(buf[0]), sizeof(buf), f);
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2317
-- Commit Summary --
* char ar
@dirkmueller commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64
@Conan-Kudo commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64 p
@Vogtinator commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64 p
@dirkmueller commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64
@Conan-Kudo commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64 p
@dirkmueller commented on this pull request.
> @@ -1063,6 +1063,10 @@ package or when debugging this package.\
#
%ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode
+#--
+# arch macro for all supported x86_64
@dralley commented on this pull request.
> @@ -568,15 +568,15 @@ static int regionSwab(indexEntry entry, int il, int dl,
}
} break;
case RPM_INT32_TYPE:
- { int32_t * it = ie.data;
+ { uint32_t * it = ie.data;
See the INT64 type handling above. Add
Not a functional change, it just makes the code more clear and self-consistent.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2316
-- Commit Summary --
* Use unsigned integers more consistently in the handling of tag data
> I know @dmach was working on [libarch](https://github.com/dmach/libarch) to
> deal with this problem (of centralizing and simplifying arch detection code).
> Maybe he's interested in reviving this so we can deal with this and #1035.
> Because I still want to get this problem sorted out. weary
> FWIW, I've repeatedly said "no" to attempts to add more assembly into rpm,
> the only direction for assembly code is _out_. Use the auxiliary vector for
> determining features, and for things that are not there, I don't think rpm
> needs to care.
FWICT, the auxiliary vector for HWCAPS is no l
I know @dmach was working on [libarch](https://github.com/dmach/libarch) to
deal with this problem (of centralizing and simplifying arch detection code).
Maybe he's interested in reviving this so we can deal with this and #1035.
Because I still want to get this problem sorted out. 😩
--
Reply
FWIW, I've repeatedly said "no" to attempts to add more assembly into rpm, the
only direction for assembly code is *out*. Use the auxiliary vector for this
kind of stuff, and for things that are not there, I don't think rpm needs to
care.
--
Reply to this email directly or view it on GitHub:
h
> can you please include in `macros.in` also a %x86_64 macro that covers this
> new family of architectures?
Done, also fixed missing platform macros.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1342668471
You are r
can you include in `macros.in` also a %x86_64 macro that covers this new family
of architectures?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-134264
You are receiving this because you are subscribed to this threa
The x86_64 SysV psABI defines four levels of x86_64 with certain CPU features
required for each level. Those definitions are meant to be generically useful
and recognized as such by glibc and gcc as well.
For backward-compatibility and to avoid surprises, default to building x86_64
even on v2+
Yes, I agree with you. When there are too many submissions in a PR, one
problematic submission will block other submissions. Considering that the
repair code is simple and is a leak problem of rpmbuild, I put them in a PR to
prevent too many PRs.
--
Reply to this email directly or view it on G
> > When `checkSep(EVR, '-', emsg)` or `checkSep(EVR, ':', emsg)` or
> > `checkEpoch(EVR, emsg)` returns RPMRC_FAIL, and
> > `_wrong_version_format_terminate_build` is defined as 0, the checkDep()
> > will returns RPMRC_OK and emsg is set.
>
> Oh, indeed. We could just remove _wrong_version_for
@JetXujing commented on this pull request.
> @@ -276,7 +279,11 @@ static int doBuildRequires(rpmSpec spec, int test)
exit:
freeStringBuf(sb_stdout);
-free(output);
+if (output) {
Thank you for the tip, I've made the relevant changes.
--
Reply to this email directly or view it
@JetXujing pushed 5 commits.
ae4e1fad3c30beae27b53721e048c8ca9d7fcf52 Fix BANames leak in handlePreambleTag
b1c328fae840ee5553df9d85d59dc4f8426abda5 Fix prog leak in parseScript
ac5b93c101ffeb83f72357b59d86810b5197de8c Fix elf leak in getElfColor
e9bf10bda8fd211bdce46a96fbb9d4f41717a608 Fix *s
@JetXujing pushed 1 commit.
76fa5ee9a4b55bcb9498b084471b2bf86d28a0c0 Fix memleak when running
%generate_buildrequires
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2293/files/63d6d70d869296fd8fe95bd73466bed6ae72a133..76fa5ee9a4b55bcb9498b084471b2bf86d28a0c0
You are
Build root policy scripts (that brp-* stuff) can and do modify build root
contents, sometimes inadvertely.
Impossible to say with this level of detail but I'd hazard a guess this is
brp-strip-static-archive in action.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-
That message is just a warning if the file in question is not executable, so
that has changed for whatever reason.
The mode in the message comes from the package, which may inherit it from the
disk or be spec defined. This sounds like the spec is accidentally overriding
the file mode for these
> The leaked scenarios are different and independent. Is it clearer to use
> every commit to fix every scenario separately?
The commits are fine as they are here. But as noted in
https://github.com/rpm-software-management/rpm/blob/master/CONTRIBUTING.md,
pull-requests should ideally be "atomic"
Closed #2304.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2304#event-7987121031
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm-
Merged manually as commit cf27c6f4963dcf27302d0f4fa39d7787dd03f942, tweaked a
bit just to deal with the redundant whitespace in the existing code, the patch
was adding more. Usually changing unrelated whitespace is not a good idea but
adding a separate commit just to remove the empty line betwee
> When `checkSep(EVR, '-', emsg)` or `checkSep(EVR, ':', emsg)` or
> `checkEpoch(EVR, emsg)` returns RPMRC_FAIL, and
> `_wrong_version_format_terminate_build` is defined as 0, the checkDep() will
> returns RPMRC_OK and emsg is set.
Oh, indeed. We could just remove _wrong_version_format_terminat
> Are there any other problems? Please review them. Thanks.
Everything gets review in time, it's just not always in the same day, week or
even month sometimes. Separately asking for review is not particularly helpful,
please be patient.
--
Reply to this email directly or view it on GitHub:
ht
@pmatilai commented on this pull request.
> @@ -276,7 +279,11 @@ static int doBuildRequires(rpmSpec spec, int test)
exit:
freeStringBuf(sb_stdout);
-free(output);
+if (output) {
Good catch, but this should simply be `argvFree(output)` instead.
--
Reply to this email directly
36 matches
Mail list logo
