On Wed, Aug 02, 2017 at 01:09:15PM +0200, Mark Wielaard wrote:
> Do we want to be nicer to packages that don't include sources like this?
> Or should we just declare that this is probably a packaging issue (badly
> produced debuginfo) and improve the error message?
I just wanted to say that in the
Based on Mark Salter's aarch64 support patch (commit 8e1ca16c58).
Signed-off-by: Richard W.M. Jones
---
installplatform | 6 ++
rpmrc.in| 16
2 files changed, 22 insertions(+)
diff --git a/installplatform b/installplatform
index ebade42..12339fc 100755
v2 -> v3:
- The RISC-V Linux kernel can now be built to return `uname -m'
as either "riscv" or "riscv64". This fixes RPM so it can cope
with either form.
- Retested.
Rich.
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.or
rch_canon cannot take into account the bit
size of the architecture, but the C code here can.
Signed-off-by: Richard W.M. Jones
---
lib/rpmrc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/rpmrc.c b/lib/rpmrc.c
index f2e0f48..eb136d8 100644
--- a/lib/rpmrc.c
++
On Wed, Aug 10, 2016 at 09:54:28PM +0100, Richard W.M. Jones wrote:
> On Wed, Aug 10, 2016 at 04:45:16PM -0400, Neal Gompa wrote:
> > On Wed, Aug 10, 2016 at 10:09 AM, Richard W.M. Jones
> > wrote:
> > > Returning the value into a char is a mistake on all platforms, but i
The first patch is pretty much the same as the one posted before.
The second patch solves the missing %{_arch} problem. The problem
turned out to be in the order that RPM does the arch_canon mapping,
which happens before we add the arch_canon entries to the internal
table. The problem is describ
Based on Mark Salter's aarch64 support patch (commit 8e1ca16c58).
Signed-off-by: Richard W.M. Jones
---
installplatform | 6 ++
rpmrc.in| 15 +++
2 files changed, 21 insertions(+)
diff --git a/installplatform b/installplatform
index ebade42..12339fc 100755
On RISC-V, the kernel returns uname.machine == "riscv" (for all bit
sizes). GNU is using "riscv64". Convert the kernel uname machine
type to a more suitable value.
This conversion is supposed to be done by the arch_canon table.
However the arch_canon table is not populated until after the
defaul
On Wed, Aug 10, 2016 at 04:50:27PM -0400, Neal Gompa wrote:
> On Wed, Aug 10, 2016 at 1:52 PM, Richard W.M. Jones wrote:
> > On Wed, Aug 10, 2016 at 06:51:43PM +0100, Richard W.M. Jones wrote:
> >> So this sort of works.
> >>
> >> However %{_arch} is not def
On Wed, Aug 10, 2016 at 04:45:16PM -0400, Neal Gompa wrote:
> On Wed, Aug 10, 2016 at 10:09 AM, Richard W.M. Jones
> wrote:
> > Returning the value into a char is a mistake on all platforms, but is
> > particularly bad on RISC-V. On that platform (like ARM) char is
> >
On Wed, Aug 10, 2016 at 06:51:43PM +0100, Richard W.M. Jones wrote:
> So this sort of works.
>
> However %{_arch} is not defined, for reasons I don't understand.
>
> # uname -a
> Linux stage3 4.1.26-01508-g592a151 #1 Sat Aug 6 08:53:06 BST 2016 riscv
> GNU/L
So this sort of works.
However %{_arch} is not defined, for reasons I don't understand.
# uname -a
Linux stage3 4.1.26-01508-g592a151 #1 Sat Aug 6 08:53:06 BST 2016 riscv
GNU/Linux
and according to
http://www.rpm.org/max-rpm-snapshot/s1-rpm-multi-build-install-detection.html
what I've
Based on Mark Salter's aarch64 support patch (commit 8e1ca16c58).
Signed-off-by: Richard W.M. Jones
---
installplatform | 6 ++
rpmrc.in| 16
2 files changed, 22 insertions(+)
diff --git a/installplatform b/installplatform
index ebade42..12339fc 100755
Returning the value into a char is a mistake on all platforms, but is
particularly bad on RISC-V. On that platform (like ARM) char is
unsigned. Therefore EOF (-1) is returned as 255, and the subsequent
test 'c == EOF' ('255 == -1') fails causing an infinite loop.
Signed
s.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
>From 316422050b8d129b109ee0a43fa9aae443c51023 Mon Sep 17 00:00:00 2001
From: "Richard W.M. Jones"
Date: Tue
I'm trying to get RPM going on a new architecture, RISC-V
(https://fedoraproject.org/wiki/Architectures/RISC-V)
I have cross-compiled rpm, rpmbuild etc fine. As I'm having a bit of
a problem building a native GCC for this new architecture (unrelated
to rpm) at the moment I can only try to build
On Mon, Sep 15, 2014 at 03:42:37PM +0300, Panu Matilainen wrote:
> On 09/13/2014 04:13 PM, Richard W.M. Jones wrote:
> >
> >We have a program[1] that needs to take a list of installed RPM
> >package names, and quickly generate all of the installed dependencies
> >(recur
We have a program[1] that needs to take a list of installed RPM
package names, and quickly generate all of the installed dependencies
(recursively).
*Note* this is NOT a question about yum/dnf/zypper/etc depsolving.
It's about doing 'rpm -qR' quickly on installed packages only.
At the moment we
I don't know if this is the new version of RPM in Fedora Rawhide, or
just coincidence, but recently I've noticed that RPM has become even
more aggressive about stripping binaries.
However, stripping binaries sometimes breaks them, so this is not
welcome (or at least there should be a simple way t
On Mon, Aug 04, 2008 at 07:56:31AM -0500, Mark Hatle wrote:
> You will want to probably define _strip as true or provide a custom
> __os_install_post. This is a necessity if you are creating a cross
> compiler with binaries for another architecture.
I maybe should have said that I'm aware of
Hi, I hope this is the right place to raise these issues.
We've recently been trying to build MinGW (a Windows cross-compiler)
plus MinGW packages for Fedora. This "kinda" works, but there are
some problems because RPM itself doesn't understand cross-compilation,
or maybe we're just not using RPM
21 matches
Mail list logo
