Package: liburcu1
Version: 0.7.7-1ubuntu1
Severity: normal
File: liburcu
Dear Maintainer,
* What led up to the situation?
I was trying to run a dynamically linked qemu with lttng tracing
support in a chroot where I had bind mounted /lib/x86_64-linux-gnu and
/usr/lib/x86_64-linux-gnu into my
Alex Bennée <alex.ben...@linaro.org> writes:
> Package: debhelper
> Severity: normal
>
> Since bug #571136 was fixed we no longer actually need a devices.tar.gz
> to build our tarball. However we can't just checkout the debootstrap
> script and call directly because it st
afford to
fail gracefully when it doesn't exist. In addition this allows us to
call the script under -e conditions from a straight checkout which is
useful in other cases.
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
---
debootstrap | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Niels Thykier <ni...@thykier.net> writes:
> Alex Bennée:
>> Package: debhelper
>> Severity: normal
>>
>
> Hi Alex,
>
> I am a bit confused by this bug. Did you perhaps intend to submit it
> against debootstrap instead of debhelper?
Apologies, completion
Niels Thykier <ni...@thykier.net> writes:
> Alex Bennée:
>>
>> Niels Thykier <ni...@thykier.net> writes:
>>
>>> Alex Bennée:
>>>> Package: debhelper
>>>> Severity: normal
>>>>
>>>
>>> Hi Alex,
>
ot create devices"
"$DEVICES_TARGZ"
fi
Sorry for the additional bug noise.
--
Alex Bennée
Since bug #571136 was fixed the --second-stage doesn't even use the
devices tarball so we can remove all its related cruft. The README has
been updated to show when real root access is required and give an
example of a foreign debootstrap which works with fakeroot.
Signed-off-by: Alex Bennée
is what I need for running aarch64 guests on my
x86 box. Perhaps the description could be tweaked to make this clearer?
--
Alex Bennée
arch bug
or a user merge bug so I've tagged them as both for now. Certainly
static libraries need to be properly placed in the relevant multi-arch
paths but this seems to work for arm64 and armhf (which I have also set
up QEMU cross build environments for).
---
Alex Bennée
Package: debootstrap
Version: 1.0.95ubuntu0.1
Severity: important
Dear Maintainer,
QEMU's build system has support for debootstrap using binfmt_misc and
QEMU's linux-user emulation. Since commit 9a6ebf628 this is broken as
it checks for the presence of wget which isn't available in the
Source: gcc-defaults
Version: 1.179
Severity: normal
Dear Maintainer,
If you run debian/rules control on an arm64 machine dpkg barfs warning
about duplicate *-x86-64-linux-gnu packages causing the build to fail.
This is probably due to clashing special casing for the amd64
packages.
A simple
Package: libcacard-dev
Version: 1:2.6.1-1
Alex Bennée writes:
> Alex Bennée writes:
>
>> Renzo Davoli writes:
>>
>>> Alex,
>>> we have tried to replicate the problem with no luck.
>
>>
>
> Hmm on my dev machine I still get:
>
&
/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
--
Alex Bennée
System Information:
Ubuntu Release: bionic
Debian Release: buster/sid
Architecture: arm64
I found this on bionic but the bug exists upstream as well:
binfmt-support/bionic,now 2.1.8-2 arm64 [installed,automatic]
qemu-user-static/bionic-updates,now 1:2.11+dfsg-1ubuntu7.10 arm64 [installed]
-- no debconf information
--
Alex Bennée
to get just all the cross binutils cleanly building on arm64
have stalled somewhat so in the meantime is there anything we can do to
keep build-dependencies working on all arches?
See bellow for more context:
Michael Tokarev writes:
> 06.02.2019 13:58, Alex Bennée wrote:
> []
>>&
int flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
--
Alex Bennée
Alex Bennée writes:
Package: qemu
Version: 3.1+dfsg-2
Package: xfsprogs
Version: 4.15.1-1
>
> Which would uninstall the base QEMU binaries. Backtracking I think the
> problem is:
>
> The following packages have unmet dependencies:
>libvdeplug-dev:arm64 : Depends:
Michael Tokarev writes:
> Control: reassign -1 src:qemu
> Control: tag -1 + moreinfo
>
> 05.02.2019 22:12, Alex Bennée wrote:
>> Package: qemu-system-common
>> Version: 1:3.1+dfsg-2+b1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> This
Michael Tokarev writes:
> 06.02.2019 13:58, Alex Bennée wrote:
> []
>>> What should the dependencies look like?
As per:
From: Helmut Grohne
Subject: Re: [PATCH] binutils: enable s390x/ppc64el on arm64 hosts
Message-ID: <20190213051906.ga24...@alf.mars>
The
-common depends on:
ii adduser 3.118
ii libc6 2.28-5
ii libcap-ng00.7.9-2
ii libcap2 1:2.25-1.2
ii libglib2.0-0 2.58.2-3
qemu-system-common recommends no packages.
qemu-system-common suggests no packages.
-- no debconf information
--
Alex Bennée
d in the meantime \o/
For reference these where the steps we were following:
https://github.com/stsquad/dockerfiles/blob/master/multiarch/debian-arm64-cross/Dockerfile
>
> renzo
> (tnx to Diego Zuccato who actually ran the tests)
Is there anyway to list all the package changes that have happened since
the bug was reported?
Anyway I shall close the bug now.
--
Alex Bennée
Alex Bennée writes:
> Renzo Davoli writes:
>
>> Alex,
>> we have tried to replicate the problem with no luck.
>
> Anyway I shall close the bug now.
Hmm on my dev machine I still get:
18:17:40 [root@zen:~] # apt build-dep -a arm64 qemu
Reading package
I can confirm I've seen the same symptoms on my system. I was unable to
get a working X session (although the cursor would appear on one of my
two displays). Manual startx would also fail.
HW:
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller
(rev 06)
ace (#960271)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Alex Bennée
---
debian/changelog | 6 ++
...ux-swab.h-fix-userspace-breakage-use.patch | 71 +++
debian/patches/ser
starts working again.
On Fri, 22 May 2020 at 15:36, Lukas Straub wrote:
>
> Hello Everyone,
> When will this fix be released?
>
> Regards,
> Lukas Straub
--
Alex Bennée
KVM/QEMU Hacker for Linaro
things do mount and I can exit and continue the boot.
I'm not sure the best way to further diagnose this and see if it's really
related.
--
Alex Bennée
KVM/QEMU Hacker for Linaro
Package: multipath-tools
Version: 0.8.5-2
Severity: normal
Dear Maintainer,
While trying to convert QEMU's cross-build images to lci-tool I
discovered installing multipath-tools:arm64 as a foreign architecture
package would fail due to unsatisfied dependencies. Switching the
cross policy to
/systemd/system)
LSM: AppArmor: enabled
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
--
Alex Bennée
Emulation and Virtualisation Tech Lead @ Linaro
Hi,
Just a quick note that the failure mode still exists after upgrading to
bookworm (testing). If anyone has any pointers on how to diagnose mount
failures during initrd I'd happily run some experiments.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
/28985622530/Building+QEMU+with+virtio-gpu+and+rutabaga+gfx
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
On Fri, 26 Apr 2024 at 16:48, Julian Andres Klode <
julian.kl...@canonical.com> wrote:
> On Thu, Apr 25, 2024 at 09:10:08PM +0100, Alex Bennée wrote:
> > Alex Bennée writes:
> >
> > > Julian Andres Klode writes:
> > >
> > >> On Thu,
en using the same grub.cfg and get most of the way through the
Dom0 boot before that failed for unrelated issues. So it seems there is
a bug introduced by the debian customisation of the package or missing a
fix from the current state of upstream.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Julian Andres Klode writes:
> On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote:
>>
>> Continuing to debug on QEMU it seems there is an incompatibility with
>> the images and the peloader (which overrides the normal efi loader):
>>
>&
62a000 in ?? ()
#30 0xafafafaf6c617470 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Is it possible to override the peloader or does the Xen image need to be
prepared a certain way?
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Alex Bennée writes:
> Julian Andres Klode writes:
>
>> On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote:
>>>
>>> Continuing to debug on QEMU it seems there is an incompatibility with
>>> the images and the peloader (which overrides the norm
36 matches
Mail list logo
