similar to: Bug#586772: any progress?

Hello, this two patches add blktap2 functionality to xen-utils. I backported http://xenbits.xen.org/xen-unstable.hg?rev/ca2738f258f8 to remove license issues. First patch(xen-common.patch) is for xen-utils-common, second patch(xen-utils.patch) is for xen-utils. To apply it just enter to 'debian' dir and run `patch -p2 <patch_name` Regards, -- ?ukasz Ole? -------------- next part

We have a great many VMs that are stuck on Lenny because of this. Probably can build it ourselves, but would prefer to avoid the maintenance nightmare. Please make this happen, as we really like Debian. Thanks, -- Jayson Vantuyl jayson at gogrid.com<mailto:jayson at gogrid.com> 417-207-6962<tel:+14172076962> (mobile) ________________________________ The information contained in

Package: xen-utils-4.0 Version: 4.0.1-1 Severity: normal Due to license issues this version of Xen does not include the blktap2 backend (tapdisk2) and associated utilities (vhd-util, etc.). The decision was made to disable the blktap v1 kernel module (the default is now blktap2). As a result we can't use any tap devices which means worse performance than previousl. Since blktap1 was available

Hi all, Thanks for sending this update Hans. I too am interested in helping out with xen packaging. I am trying to dig into the dpkg-shlibdeps issues - I built it successfully on one box but haven?t been able to reproduce. Either way, I will plan to hang around in IRC to help where I can. Stephen > On Jan 9, 2018, at 4:05 PM, Hans van Kranenburg <hans at knorrie.org> wrote: >

Processing commands for control at bugs.debian.org: > close 586772 4.4.0-1 Bug #586772 [xen-utils-4.0] blktap2 does not work There is no source info for the package 'xen-utils-4.0' at version '4.4.0-1' with architecture '' Unable to make a source version for version '4.4.0-1' Marked as fixed in versions 4.4.0-1. Bug #586772 [xen-utils-4.0] blktap2 does not work

Package: xen-utils-4.0 Version: 4.0.0-2 Severity: normal This is the config: #HVM #still no qemu-dm #kernel = "/usr/lib/xen-4.0/boot/hvmloader" #builder = 'hvm' #memory = 2048 #name = "webserver" #vif = ['bridge=eth0'] #disk = ['tap:tapdisk:aio:/srv/xen/webserver.img,xvda,w','phy:/dev/cdrom,xvdb:cdrom,r'] #device-model =

> this two patches add blktap2 functionality to xen-utils. I backported > http://xenbits.xen.org/xen-unstable.hg?rev/ca2738f258f8 to remove > license issues. Has this patch been applied? Darkbasic

This is a serious regression from Lenny which will prevent any of my production systems from being able to upgrade. On my test system it seems that blktap is broken, blktap2 is missing, only file works, which, as noted here, is not recommended. This is perhaps more of a kernel bug than a xen bug so I'm not sure if this bug should be linked to the kernel package.

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-8 Severity: normal Tags: patch The Xen hypervisor in Debian Jessie does not boot on recent HP server hardware (e.g. the current dl360 gen9 series) when using normal "legacy" boot. During boot, it panics with the message "System without CMOS RTC must be booted from EFI". This message was introduced in upstream commit

Just trying to understand: Are you suggesting a way to have a “-O0” build without all the debug information? -Min > On Nov 17, 2020, at 10:25 AM, Luke Drummond via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all > > I wanted to do a quick build of a clean branch yesterday and noticed > something surprising in the configure log: > >> -- No build type

I noticed while running xfstests 83 that if we didn''t have enough space to delete our inode the orphan cleanup would just loop. This is because it keeps finding the same orphan item and keeps trying to kill it but can''t because we don''t get an error back from iput for deleting the inode. So keep track of the last guy we tried to kill, if it''s the same as the

I'm curious how much of this is due to not using LLD? Last I checked, using ld.bfd instead of LLD (or gold) was one of my major build time issues, and somehow our default configuration would use ld.bfd. -- Sean Silva On Tue, Nov 17, 2020 at 10:25 AM Luke Drummond via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all > > I wanted to do a quick build of a clean branch

On Tue, Nov 17, 2020 at 10:25 AM Luke Drummond via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all > > I wanted to do a quick build of a clean branch yesterday and noticed > something surprising in the configure log: > > > -- No build type selected, default to Debug > > It appears that llvm's configuration forces Debug builds if the user > does

Yeah, that's one I'd be in favor of fixing, if it's still the case. On Tue, Nov 17, 2020 at 5:38 PM Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm curious how much of this is due to not using LLD? Last I checked, using ld.bfd instead of LLD (or gold) was one of my major build time issues, and somehow our default configuration would use ld.bfd. >

Hello, I'd like to know if this is an hypervisor related problem or a libvirt one. I did this experiment: on VM I started watching a video on youtube. While video was in progress I started migration. Migration did not complete until video was not finished. I did another experiment: I installed a web server on VM. I then started an httperf stress test. As before migration did not complete

http://bugzilla.mindrot.org/show_bug.cgi?id=901 Summary: visual gauge in progress meter Product: Portable OpenSSH Version: 3.8.1p1 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: scp AssignedTo: openssh-bugs at mindrot.org ReportedBy: peak at

I have no strong opinion on this topic personally (I always set the build type to something if I’m not generating a Visual Studio project), but this “non-optimized, non-asserting, non-debug-info-containing” build that you get when not specifying the build type to CMake is a quirk that I feel most CMake users expect at this point. I don’t think there’s any real value in providing a useful default

On 07/19/2010 05:14, Olivier Meurant wrote: > Together with Jan Sjodin (in copy of this email), we begin an > implementation of the JIT with MC. The idea, suggested by Jan, is to > develop a MCJIT in parallel of the current JIT and to keep the two > implementations until (at least) the new MC one is mature enough. > Currently code is kept on gitorious >

On Jun 24, 2011, at 12:44 PM, Yuri wrote: > On 07/19/2010 05:14, Olivier Meurant wrote: >> Together with Jan Sjodin (in copy of this email), we begin an >> implementation of the JIT with MC. The idea, suggested by Jan, is to >> develop a MCJIT in parallel of the current JIT and to keep the two >> implementations until (at least) the new MC one is mature enough. >>

Hi there, I've done an apt-get source linux-image-2.6.18-4-xen-686 and would very much like to build a package with NFS root enabled. From what I've read, I need to run split-config, which I got from SVN (it doesn't seem to exist anywhere else) I've fooled around with split-config to produce a config to my spec but this doesn't seem to actually work. Usage: