similar to: Processed: xen

Processing commands for control@bugs.debian.org: > reassign 366216 xen-utils-3.0.3-1 Bug#366216: vif-bridge: offlining the interface fails because interface already offline Warning: Unknown package 'xen-utils-3.0' Bug reassigned from package `xen-utils-3.0' to `xen-utils-3.0.3-1'. > reassign 369042 xen-utils-3.0.3-1 Bug#369042: xen-utils-3.0: does not work with 32.bit

Processing commands for control at bugs.debian.org: > # reassigning all open bugs reported against versioned xen packages that are no longer in the archive to src:xen > reassign 514918 src:xen 3.3-unstable+hg17961-1 Bug #514918 [xen-utils-unstable] xen-utils-unstable: xend starts with errors Warning: Unknown package 'xen-utils-unstable' Bug reassigned from package

If you have access to an Alpha, please test klibc-1.3.21; in particular, anything which uses pipes... Thanks, -hpa

When I compile klibc on little-endian mips, I get: KLIBCLD klibc/libc.so ld: klibc/arch/mips/crt0.o: compiled for a little endian system and target is big endian ld: klibc/arch/mips/crt0.o: endianness incompatible with that of the selected emulation ld: failed to merge target specific data of file klibc/arch/mips/crt0.o When I change "elf32-tradbigmips" to

This was filed as a bug report on the Debian r-base package. It is more properly a bug report on the ctest package in R. The default method for wilcox.test manipulates x and y without checking the class or data.class of these objects. Possible solutions are - create wilcox.test.factor (if appropriate) - check the class and/or data.class of x and y in wilcox.test.default and produce error

I see the following on a Jetson TK1: [ 9.495425] [TTM] Initializing DMA pool allocator [ 9.495513] nouveau 57000000.gpu: DRM: VRAM: 0 MiB [ 9.495520] nouveau 57000000.gpu: DRM: GART: 1048576 MiB [ 9.508076] nouveau 57000000.gpu: DRM: failed to create ce channel, -22 A Google search suggests that I'm not the only one with this, but I don't see it being discussed anywhere. Is

Hello all, I really want to support vfork() in klibc, mostly because uClinux *has* to use it. Unfortunately vfork() isn't allowed to use the stack *at all* across the system call -- including return address -- which means it needs an assembly wrapper on most architectures. I have tried implementing wrappers for most architectures, but I don't know parisc or s390/s390x well enough,

Package: xen-unstable Version: 3.0-unstable+hg11292-2 Your package fails to build with GCC 4.2. Version 4.2 has not been released yet but I'm building with a snapshot in order to find errors and give people an advance warning. The bug below is in your package though and not because I'm using a snapshot of the compiler so please take a look at it. You can reproduce this with the

From: Sjoerd Simons <sjoerd@spring.luon.net> It seems that klibc uses __sparc64__ to determine if it's compiled in 64 bit mode on sparc, unfortunatly gcc doesn't define __sparc64__ :) It does define __arch64__ though. Signed-off-by: maximilian attems <maks@sternwelten.at> --- klibc-1.2.2.orig/include/sys/vfs.h 2006-02-15 18:32:10.000000000 +0100 +++

I'd like to use linear and quadratic trend analysis in order to find out a change in slope. Basically, I need to solve a similar problem as discussed in http://www.gseis.ucla.edu/courses/ed230bc1/cnotes4/trend1.html My subjects have counted dots: one dot, two dots, etc. up to 9 dots. The reaction time increases with increasing dots. The theory is that 1 up to 3 or 4 points can be counted

I have just pushed out a git tree which actually has the root-mounting code removed from the kernel. Since there are any number of strange boot configurations out there, I would really appreciate any help in testing this stuff out. I have *NOT* implemented support for the following, which I'm hoping has fallen out of use by now: -> Setting boot flags via rdev, as opposed to on the

Stop makeklcc.pl from hardcoding paths of cc, ld and strip in the klcc script it generates. Using hardcoded paths is generally a bad idea. First, the whole idea of $PATH is that you don't need to hardcode paths. Second, klcc is a Perl script but my hardcoding the paths you make it less portable. Signed-off-by: Martin Michlmayr <tbm@cyrius.com> --- klibc-1.1.16/klcc/makeklcc.pl~

Pipe doesn't work in dash on mips/mipsel - everything delivered to a pipe is shown on stdout: mipsel: $ echo foo | cat > ~/d foo <ctrl-c pressed manually> $ cat ~/d $ i386: $ echo foo | cat > ~/d $ cat ~/d foo $ This may be related to the following warnings during compilation but I'm not sure: klibc/arch/mips/syscall.S: Assembler messages: klibc/arch/mips/syscall.S:12:

Processing commands for control@bugs.debian.org: > reassign 368417 xen-hypervisor-3.0.3-1-i386 Bug#368417: xen-hypervisor-3.0-i386: cannot start NetBSD-HEAD Warning: Unknown package 'xen-hypervisor-3.0.2-1-i386' Bug reassigned from package `xen-hypervisor-3.0.2-1-i386' to `xen-hypervisor-3.0.3-1-i386'. > reassign 388152 xen-hypervisor-3.0.3-1-i386 Bug#388152:

Package: blktap Version: 2.0.90-4 Severity: important User: debian-gcc at lists.debian.org Usertags: ftbfs-gcc-6 gcc-6-unused-const-variable This package fails to build with GCC 6. GCC 6 has not been released yet, but it's expected that GCC 6 will become the default compiler for stretch. Note that only the first error is reported; there might be more. You can find a snapshot of GCC 6 in

Processing commands for control at bugs.debian.org: > # Automatically generated email from bts, devscripts version 2.9.26 > reassign 366315 xen-3 Bug#366315: xen-hypervisor-3.0-amd64: package should be build for arch i386 too Bug reassigned from package `xen-hypervisor-3.0.3-1-amd64' to `xen-3'. > tags 366315 wontfix Bug#366315: xen-hypervisor-3.0-amd64: package should be build

Processing commands for control at bugs.debian.org: > reassign 808624 src:xen 4.4.1-9+deb8u3 Bug #808624 [xen-hypervisor-4.4-amd64] Invalid argument while starting daemon Bug reassigned from package 'xen-hypervisor-4.4-amd64' to 'src:xen'. Ignoring request to alter found versions of bug #808624 to the same values previously set Ignoring request to alter fixed versions of bug

I'm supporting a number of consumer devices (e.g. small NAS devices) in Debian. They typically don't export the serial console and don't have any other output devices. We perform the installation via SSH on such devices and start SSH automatically when the system boots so people can login. This works pretty well but sometimes a device stops to boot for no good reason. This is

I was wondering if it would be possible to add a cpio (extraction) implementation to klibc. Maybe this can be done in a way that the code could bet shared between klibc and init/initramfs.c in the kernel. Background of what I'm trying to do: I want to load an initramfs from flash on a number of different devices. The devices are quite similar but the partition in flash where the initramfs

Processing commands for control@bugs.debian.org: > reassign 366315 xen-hypervisor-3.0.3-1-amd64 Bug#366315: xen-hypervisor-3.0-amd64: package should be build for arch i386 too Warning: Unknown package 'xen-hypervisor-3.0.2-1-amd64' Bug reassigned from package `xen-hypervisor-3.0.2-1-amd64' to `xen-hypervisor-3.0.3-1-amd64'. > -- Stopping processing here. Please contact me