On Mon, 2017-03-27 at 17:32 +0100, Peter Maydell wrote:
> On 26 March 2017 at 10:16, Knut Omang wrote:
> > On Sat, 2017-03-25 at 21:15 +, Peter Maydell wrote:
> >> On 25 March 2017 at 20:49, Knut Omang wrote:
> >> >
> >> > Can we please keep the Sparc support in for a while still?
> >>
> >> Y
On 26 March 2017 at 10:16, Knut Omang wrote:
> On Sat, 2017-03-25 at 21:15 +, Peter Maydell wrote:
>> On 25 March 2017 at 20:49, Knut Omang wrote:
>> >
>> > Can we please keep the Sparc support in for a while still?
>>
>> Yes, John Paul Adrian Glaubitz and the Debian Project have
>> kindly pr
On Sat, 2017-03-25 at 21:15 +, Peter Maydell wrote:
> On 25 March 2017 at 20:49, Knut Omang wrote:
> >
> > Can we please keep the Sparc support in for a while still?
>
> Yes, John Paul Adrian Glaubitz and the Debian Project have
> kindly provided me with access to a Sparc box. I'm planning
>
On 25 March 2017 at 20:49, Knut Omang wrote:
> Can we please keep the Sparc support in for a while still?
Yes, John Paul Adrian Glaubitz and the Debian Project have
kindly provided me with access to a Sparc box. I'm planning
to send a patch that puts sparc into the 'supported'
category before 2.9
On Thu, 2017-03-16 at 15:23 +, Peter Maydell wrote:
> OK, here's a concrete proposal for deprecating/dropping out of
> date host OS and architecture support.
>
> We'll put this in the ChangeLog 'Future incompatible changes'
> section:
> -
> * Removal of support for untested host OS and arc
On 24 March 2017 at 01:28, Richard Henderson wrote:
> I also have access to a sparc box.
>
> (At the moment I'm trying to update it from 2013 era system libraries, and
> to enable the 64-bit userland, before I do any testing of current mainline.)
So far I have found that we seem to be mishandling
On 03/23/2017 09:02 PM, Peter Maydell wrote:
On 23 March 2017 at 10:33, Paolo Bonzini wrote:
I own a MIPS Creator ci20 board (donated by Imagination Technologies).
I cannot give it a public IP address, but I can try and use it to do
builds every now and then.
I think our best bet is probably
On 23 March 2017 at 10:33, Paolo Bonzini wrote:
> I own a MIPS Creator ci20 board (donated by Imagination Technologies).
> I cannot give it a public IP address, but I can try and use it to do
> builds every now and then.
I think our best bet is probably to fix our test suite's
overreliance on /tm
On 22/03/2017 14:09, Peter Maydell wrote:
> On 22 March 2017 at 12:51, Alex Bennée wrote:
>> Peter Maydell writes:
>>> ...unfortunately the gcc compile farm mips board (1) is very slow
>>> and (2) has very little disk space free in /tmp, which means that
>>> it can't pass "make check" because f
On 22.03.2017 14:09, Peter Maydell wrote:
> On 22 March 2017 at 12:51, Alex Bennée wrote:
>> Peter Maydell writes:
>>> ...unfortunately the gcc compile farm mips board (1) is very slow
>>> and (2) has very little disk space free in /tmp, which means that
>>> it can't pass "make check" because for
On 22 March 2017 at 12:51, Alex Bennée wrote:
> Peter Maydell writes:
>> ...unfortunately the gcc compile farm mips board (1) is very slow
>> and (2) has very little disk space free in /tmp, which means that
>> it can't pass "make check" because for instance tests/test-replication
>> assumes it c
Peter Maydell writes:
> On 16 March 2017 at 15:23, Peter Maydell wrote:
>> (Technically right this instant 'mips' and 's390' would be in the
>> 'dump' list, since I don't personally have access yet. But we have
>> a plan for s390, and it turns out there is a mips machine in the
>> gcc compile f
On 03/16/2017 10:46 AM, Daniel P. Berrange wrote:
>
>> Should "native CYGWIN" be in the drop list? I only test
>> mingw cross compile, but configure has a separate section for
>> CYGWIN in its $targetos case statement.
>
> Cygwin is different enough from mingw that I'd basically call
> it a comp
On 17 March 2017 at 10:30, Thomas Huth wrote:
> On 17.03.2017 11:15, Peter Maydell wrote:
>> On 17 March 2017 at 10:12, Daniel P. Berrange wrote:
>>> In the mail thread two months back Sean Bruno did suggest he might like
>>> to just start over with bsd-user:
>>>
>>> https://lists.gnu.org/archi
On 17.03.2017 11:15, Peter Maydell wrote:
> On 17 March 2017 at 10:12, Daniel P. Berrange wrote:
>> In the mail thread two months back Sean Bruno did suggest he might like
>> to just start over with bsd-user:
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00171.html
>>
>> So perh
On 17 March 2017 at 10:12, Daniel P. Berrange wrote:
> In the mail thread two months back Sean Bruno did suggest he might like
> to just start over with bsd-user:
>
> https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00171.html
>
> So perhaps someone should just ping him to see if he obje
On Fri, Mar 17, 2017 at 10:09:51AM +0100, Thomas Huth wrote:
> On 16.03.2017 17:52, Paolo Bonzini wrote:
> >
> >
> > On 16/03/2017 16:55, Peter Maydell wrote:
> >>> IOW, I think there is a reasonable 3 tier set here
> >>>
> >>> 1. Stuff we actively test builds & thus guarantee will work for
> >>
On 16 March 2017 at 18:59, Dr. David Alan Gilbert wrote:
> I build-test the FreeBSD when I do migration pulls; given it's
> just a VM it's not too hard; my main reason is that I use it as
> a proxy that gives it a good chance to get past your MacOS build.
Yeah, I have no in principle objection to
On 16.03.2017 17:52, Paolo Bonzini wrote:
>
>
> On 16/03/2017 16:55, Peter Maydell wrote:
>>> IOW, I think there is a reasonable 3 tier set here
>>>
>>> 1. Stuff we actively test builds & thus guarantee will work for
>>> any QEMU release going forward.
>>>
>>> 2. Stuff we don't actively tes
"Daniel P. Berrange" writes:
> On Thu, Mar 16, 2017 at 03:55:13PM +, Peter Maydell wrote:
>> On 16 March 2017 at 15:46, Daniel P. Berrange wrote:
>> > On Thu, Mar 16, 2017 at 03:23:45PM +, Peter Maydell wrote:
>> >> OK, here's a concrete proposal for deprecating/dropping out of
>> >> dat
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 16 March 2017 at 15:46, Daniel P. Berrange wrote:
> > On Thu, Mar 16, 2017 at 03:23:45PM +, Peter Maydell wrote:
> >> OK, here's a concrete proposal for deprecating/dropping out of
> >> date host OS and architecture support.
> >>
> >> We'l
On Thu, Mar 16, 2017 at 06:01:35PM +, Peter Maydell wrote:
> On 16 March 2017 at 15:23, Peter Maydell wrote:
> > (Technically right this instant 'mips' and 's390' would be in the
> > 'dump' list, since I don't personally have access yet. But we have
> > a plan for s390, and it turns out there
On 16 March 2017 at 15:23, Peter Maydell wrote:
> (Technically right this instant 'mips' and 's390' would be in the
> 'dump' list, since I don't personally have access yet. But we have
> a plan for s390, and it turns out there is a mips machine in the
> gcc compile farm which I'm just checking out
On 16/03/2017 16:55, Peter Maydell wrote:
>> IOW, I think there is a reasonable 3 tier set here
>>
>> 1. Stuff we actively test builds & thus guarantee will work for
>> any QEMU release going forward.
>>
>> 2. Stuff we don't actively test, but generally assume is mostly
>> working, and
On 16 March 2017 at 16:16, Daniel P. Berrange wrote:
> BTW, by "build & test system available", presumably you mean a system
> that someone has committed to actively maintaining, not merely donation
> of (or access to) hardware on which to install & run VMs ?
My personal minimum is "something I c
On Thu, Mar 16, 2017 at 03:23:45PM +, Peter Maydell wrote:
> OK, here's a concrete proposal for deprecating/dropping out of
> date host OS and architecture support.
>
> We'll put this in the ChangeLog 'Future incompatible changes'
> section:
> -
> * Removal of support for untested host OS
On Thu, Mar 16, 2017 at 04:06:35PM +, Peter Maydell wrote:
> On 16 March 2017 at 16:00, Daniel P. Berrange wrote:
> > I'm just pretty wary of gratuitously deleting stuff that still
> > has a reasonable chance of being functional, simply because
> > we lack CI testing.
>
> Well, me too, but I
On 16 March 2017 at 16:00, Daniel P. Berrange wrote:
> I'm just pretty wary of gratuitously deleting stuff that still
> has a reasonable chance of being functional, simply because
> we lack CI testing.
Well, me too, but I think that if nobody turns up to help us
or donate a test machine despite c
On Thu, Mar 16, 2017 at 03:55:13PM +, Peter Maydell wrote:
> On 16 March 2017 at 15:46, Daniel P. Berrange wrote:
> > On Thu, Mar 16, 2017 at 03:23:45PM +, Peter Maydell wrote:
> >> OK, here's a concrete proposal for deprecating/dropping out of
> >> date host OS and architecture support.
>
Hi,
> I'm not sure here if we want to just have this as a bald list,
> or to have some kind of two tier setup with OSes we expect to
> dump in one tier and OSes where we're really trolling for a build
> machine in the other tier (the "unlikely to dump" category would
> get most of the BSD varian
On 16 March 2017 at 15:46, Daniel P. Berrange wrote:
> On Thu, Mar 16, 2017 at 03:23:45PM +, Peter Maydell wrote:
>> OK, here's a concrete proposal for deprecating/dropping out of
>> date host OS and architecture support.
>>
>> We'll put this in the ChangeLog 'Future incompatible changes'
>> s
On Thu, Mar 16, 2017 at 03:23:45PM +, Peter Maydell wrote:
> OK, here's a concrete proposal for deprecating/dropping out of
> date host OS and architecture support.
>
> We'll put this in the ChangeLog 'Future incompatible changes'
> section:
> -
> * Removal of support for untested host OS
OK, here's a concrete proposal for deprecating/dropping out of
date host OS and architecture support.
We'll put this in the ChangeLog 'Future incompatible changes'
section:
-
* Removal of support for untested host OS and architectures:
The QEMU Project intends to drop support in a future rele
33 matches
Mail list logo
