Hi Christian,
Thank you for accepting MR.
>>> I'll try to get some tests done over the weekend. Ryutaroh, given your
>>> experience, if you get a chance to look at ARM side of this, too, I'd be
>>> immensely grateful :-)
>> I will see its behavior on building an arm image by the start of the next
Hi Ryutaroh,
On 07.01.21 02:02, Ryutaroh Matsumoto wrote:
> I have sent an MR regarding
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975024
Good catch, thanks!
I slightly modified debian/changelog to follow convention. (In
particular, I think the Closes: #xx syntax requires the : to
Hi Christian,
Thank you very much for your work!.
> The updated packaging is in my fork on Salsa:
> https://salsa.debian.org/ckk/vmdb2
I have sent an MR regarding
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975024
I have looked at
Hi Ryutaroh, Gunnar,
On 01.01.21 05:27, Ryutaroh Matsumoto wrote:
> I wonder if you have available time to package vmdb 0.21 for Debian Bullsyeye
> before its deadline.
I went ahead and took a stab at updating the package. There were some
minor tweaks to the build process, but the first result
On 01.01.21 05:27, Ryutaroh Matsumoto wrote:
> vmdb 0.21 appeared in the upstream:
> http://git.liw.fi/vmdb2/log/?showmsg=1
>
> I wonder if you have available time to package vmdb 0.21 for Debian Bullsyeye
> before its deadline.
Gunnar, I'm happy to do this if your schedule doesn't permit it.
> As I said in debian-private (which, of course, is not read by
> everybody), I am in a [VAC] period. I am having quite limited
> available time, and this will continue at least until the beginning of
> 2021. So, please, if you have an upload to make - NMU the package at
> will!
Hi Gunnar,
CC:
On 12/11/20 12:33 AM, Ryutaroh Matsumoto wrote:
>> The conclusion being that the proposed changes should be first included
>> into upstream directly.
>
> According to
> http://git.liw.fi/vmdb2/log/?showmsg=1
> arm64 support is being developed at the upstream.
> armhf, armel, or ppc64el doesn't
> The conclusion being that the proposed changes should be first included
> into upstream directly.
According to
http://git.liw.fi/vmdb2/log/?showmsg=1
arm64 support is being developed at the upstream.
armhf, armel, or ppc64el doesn't seem so.
I am willing to submit a merge request like
I forgot to say:
On 12/10/20 10:45 AM, Christian Kastner wrote:
> In any case, I guess the most reasonable course of action would be only
> do "new upstream versions", that is, only changes coming from upstream.
The conclusion being that the proposed changes should be first included
into
Hi all,
On 12/10/20 2:12 AM, Ryutaroh Matsumoto wrote:
> In short, I am not qualified to do NMU, a detailed excuse follows.
>
> I have no right or expertise to NMU...
> As your email is publicly appearing to BTS,
> I CC'ed my reply to Christian.
>
> I know he is also very busy now, but he has
Hi everyone interested in vmdb2!
Short comments: David's approach for vmdb2 multi-arch supports
re-uses the architecture specified for qemu-debootstrap for that of "grub:
uefi".
My approach requires a user to specify the architecture twice for
qemu-debootstrap and "grub: uefi".
So, David's
Hi Gunnar,
CC: Christian,
Thank you for your message.
Since I am in To: field of your email,
I assume your last email is somewhat directed to me.
In short, I am not qualified to do NMU, a detailed excuse follows.
I have no right or expertise to NMU...
As your email is publicly appearing to BTS,
Hello world,
As you have guessed by now, I have been unable to follow on this bug
report. As the Debian vmdb2 maintainer, I am ashamed of not even
answering... :-( Anyway, I'm happy to see that Lars, upstream author,
is part of the discussion, and there are other DDs involved.
As I said in
Hi Lars, David,
On 12/9/20 8:39 AM, Lars Wirzenius wrote:
> On Tue, Dec 08, 2020 at 05:12:57PM +, David Edmondson wrote:
>> I figured that out today (need to specify a 64 bit CPU) and provided an
>> updated set of patches.
>
> I'll just note that David updated his patches and that I've
On Tue, Dec 08, 2020 at 05:12:57PM +, David Edmondson wrote:
> I figured that out today (need to specify a 64 bit CPU) and provided an
> updated set of patches.
I'll just note that David updated his patches and that I've merged
them now.
--
I want to build worthwhile things that might last.
On Friday, 2020-12-04 at 08:39:55 +02, Lars Wirzenius wrote:
> As it happens, David Edmonson (dme), added to cc, has been working on
> adding arm64 support for the grub plugin. Part of his changes is that the
> grub plugin will know the target archietecure, and choose the right grub
> .deb
As it happens, David Edmonson (dme), added to cc, has been working on
adding arm64 support for the grub plugin. Part of his changes is that the
grub plugin will know the target archietecure, and choose the right grub
.deb package to install based on that.
Unfortunatly, the tests for his changes
Hi Christian, thanks again for your attention.
> * You could enhance the new "arch" field of the grub plugin by not
> defaulting to amd64, but to the native host architecture. You can
> get this using
> subprocess.check_call(['dpkg', '--print-architecture'])
Thank you. I
Hi Ryutaroh,
On 11/18/20 5:45 AM, Ryutaroh Matsumoto wrote:
> I made the attached patch against the latest upstream git source
> as attached. I also add "patch" tag to this bts.
> As far as I tested, the patch seems working well.
> I also added bind-mount of /proc and /dev/pts as recent version
Control: tags -1 + patch
Hi Gunnar, in response to your message,
From: Gunnar Wolf
Subject: Re: Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on
arm64 and does not work on arm64
Date: Sat, 7 Nov 2020 23:33:01 -0600
> As you said here, the workaround is not a fix, as it would
I've sent some patches to liw for vmdb2 to improve building a UEFI based
arm64 image which can be seen here:
https://git.sledj.net/dme/vmdb2/src/branch/devel/arm64
These should address the general problem of vmdb2 being able to build an
arm64 image when grub is used, as long as UEFI is
Hello Lars,
I am writing to you regarding the bug report I am Cc:ing here. Please
help me correctly answer to this! The submitter says, in the initial
mail:
> I am trying to let autopkgtest-build-qemu work on arm64.
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038
> for relevant
tags 973467 - patch
tags 973467 + confirmed upstream
severity 973467 important
thanks
Hello Ryutaroh,
As you said here, the workaround is not a fix, as it would make vmdb2
produce images unable to boot on amd64 - So I'm removing the "patch"
tag. I am also adding the tags "confirmed" and
Control: tags -1 + patch
The following workaround (NOT A FIX AT ALL) let vmdb2 work for my arm64...
--- usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py-orig
2020-10-31 12:47:04.796899268 +0900
+++ usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py 2020-10-31
Package: vmdb2
Version: 0.19-1
Severity: grave
Justification: renders package unusable
Control: block 973038 by -1
Dear Maintainer,
I am trying to let autopkgtest-build-qemu work on arm64.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038
for relevant report.
The original
25 matches
Mail list logo
