similar to: [PATCH] Add hppa, hppa64, ppc64el architectures

This was used only in the RPM package handler. --- src/utils.ml | 27 --------------------------- src/utils.mli | 3 --- 2 files changed, 30 deletions(-) diff --git a/src/utils.ml b/src/utils.ml index f85418f..b25df88 100644 --- a/src/utils.ml +++ b/src/utils.ml @@ -172,33 +172,6 @@ and split_version = function ) in first :: split_version rest -let compare_architecture a1 a2 = -

I hacked out a rough first implementation of parisc64 for klibc last month, and only just got around to testing it now. The good news, it compiled fine on the first shot. The bad news, it failed to link usr/klibc/libc.so, and I'm not clueful enough to know why. hppa64-linux-gnu-ld -Ttext 0x40001000 -o usr/klibc/libc.so --start-group [...] usr/klibc/socketcalls/recvmsg.o

This patch series fixes several problems in the way that supermin handles kernels. The most pressing problem is that supermin doesn't handle bogus vmlinuz files which aren't actual kernels. Along the way there is a lot of clean up. The patches look much better if you view them with ‘-w’. This series will require plenty of time to be tested in Fedora, especially on non-x86 arches.

This patch series fixes the way supermin sorts the list of installed packages when resolving a name, picking the right package for the host architecture. Pino Toscano (5): rpm: do not unpack parameters rpm: fix version comparison rpm: query the RPM architecture rpm: fix package sorting (RHBZ#1696822) utils: remove unused 'compare_architecture' function src/librpm-c.c | 10

--- src/kernel.ml | 43 ++++++++++++++++++++++++++++--------------- 1 file changed, 28 insertions(+), 15 deletions(-) diff --git a/src/kernel.ml b/src/kernel.ml index ed5aea3..436b1b0 100644 --- a/src/kernel.ml +++ b/src/kernel.ml @@ -23,6 +23,19 @@ open Utils open Ext2fs open Fnmatch +let patt_of_cpu host_cpu = + let models = + match host_cpu with + | "mips" |

* Richard W.M. Jones: > On Sat, Apr 26, 2014 at 02:27:07PM +0200, Hilko Bengen wrote: >> --- >> src/kernel.ml | 43 ++++++++++++++++++++++++++++--------------- >> 1 file changed, 28 insertions(+), 15 deletions(-) >> >> diff --git a/src/kernel.ml b/src/kernel.ml >> index ed5aea3..436b1b0 100644 >> --- a/src/kernel.ml >> +++ b/src/kernel.ml

Dear "nouveau" developers, I know that many very competent guys have already spent a lot of time and efforts on this issue without success. I have started to play with "hppa" two weeks ago and, with the support of the linux-parisc mailing list people, now I have a - almost fully - working workstation (hp c8000). Everythings work perfectly BUT the video card. No matter the

Hi Rich Kindly ignore my previos mail. I have downloaded the latest version of supermin supermin-5.1.8 and have compiled it for powerpc.Moreover there was no need to patch the src/ kernel.ml file as the changes were already implemented on the latest version. But still when i run libguestfs-test-tool on powerpc ubuntu,I get the below logs.. libguestfs-test-tool

Hi maks, Adding Anton in CC (who submitted klibc ppc64le support upstream [1]), in case he can help. >> The ppc64el port needs klibc's static binaries, like ppc64. > > This segfaulting is a bug in klibc that needs investigation. > >> This patch enables the ARCH=ppc64 make env var in debian/rules, in order >> for 'debian/patches/ppc64-static.patch' to take

Hi, On Fri, May 23, 2014 at 10:57:31AM -0300, Mauricio Faria de Oliveira wrote: > > The ppc64el port needs klibc's static binaries, like ppc64. This segfaulting is a bug in klibc that needs investigation. > This patch enables the ARCH=ppc64 make env var in debian/rules, in order > for 'debian/patches/ppc64-static.patch' to take effect on ppp64el too. I have no problem

Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is looping. Diddling optimization options can also sometimes provide a clue. -pd > On 29 Apr 2020, at 01:17 , Dirk Eddelbuettel <edd at

On 30 April 2020 at 09:11, luke-tierney at uiowa.edu wrote: | On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote: | Maybe I missed something. How is the 'compiler' package involved? See the other email thread; you replied (~ 26 hours ago) to my message adding that "sysdata.rda in 'tools' hanging was wrong". It gets to the next stage, which is 'compiler'. We know by

Covert common_utils_tests to use oUnit as testing framework, replacing the hand-made assert in favour of structured unit tests and better error reporting. common_utils_tests is now built only when the oUnit module has been found. --- mllib/Makefile.am | 17 ++++- mllib/common_utils_tests.ml | 155 +++++++++++++++++++++++++++----------------- 2 files changed, 108 insertions(+), 64

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Mauricio Faria de Oliveira dixit: >> [...] Effort in making shared binary >> working too is appreciated. It is probably a wrong syscall API. > > Unfortunately I don't find myself in klibc expertise area. I can try, > but maybe it's not the effective way forward (not sure I'd be able to > devote the effort/time

https://bugzilla.mindrot.org/show_bug.cgi?id=3645 Bug ID: 3645 Summary: -fzero-call-used-regs=used detection seems to fail on Linux ppc64el Product: Portable OpenSSH Version: 9.6p1 Hardware: PPC64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: Build

On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: > > > On 29 April 2020 at 11:22, peter dalgaard wrote: > | Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is

On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote: > > On 30 April 2020 at 09:42, I?aki Ucar wrote: > | On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: > | > And to keep the list abreast, this appears to be related to the long double > | > issue on powerpc where needed an extra #define to ensure compilation. That > [...] > | Which reminds me

The R 4.0.0 package migration on Debian is being held back by a failed build on ppc64el [1]. We can see from the history of builds logs [2] that it used to build, briefly failed, worked again and then failed leading to R 4.0.0's release. (And my bad for missing how the alpha1/alpha2/beta/rc builds failed.) I have however neither changed anything, nor did I ever have to accomodate ppc64el (as

On 29 April 2020 at 11:22, peter dalgaard wrote: | Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is looping. Diddling optimization options can also sometimes provide a clue. (Missed this earlier as

Dear Ilia, this page summarize all the possible options of the "nouveau" kernel module: https://nouveau.freedesktop.org/wiki/KernelModuleParameters/ I will test the options that you have suggested as soon as possible. Try a PCI video card is a very good advice because the AGP/FX1(chipset) is on the top of the "usual suspects" list; unfortunately the c8000 has 3.3 PCI slots