Bug#685134: Bug#684909: Bug#685134: [s390-tools] please add patch from qemu

[Christian Ehrhardt]

On Thu, Oct 19, 2017 at 2:01 PM, Philipp Kern  wrote:

> On 02/03/2016 09:27 AM, Viktor Mihajlovski wrote:
> > On 02.02.2016 01:01, Dimitri John Ledkov wrote:
> >> On Fri, 17 Aug 2012 11:21:04 +0200 bastien ROUCARIES
> >>  wrote:
> >>> Please add http://repo.or.cz/w/s390-tools.git for booting s390 from
> qemu. it port virtio.
> >>> I have ported the pach queue to recent s390-tools. Not tested only
> merge without conflict.
> >> Is this still required? I see that qemu-2.5 has support for booting El
> >> Torito .iso images, and it boots Debian off virtio block drives just
> >> fine.
> >>
> >> Granted, it looks like debian packaging strips the s390 firmware file,
> >> and doesn't rebuild it. Maybe that should simply be fixed and that's
> >> it?
> > Right, including the firmware file would be the proper way to enable
> > QEMU for booting on s390.
>
> If I understand it correctly, this is now obsoleted by the fact that
> qemu dropped s390-virtio and runs with their own s390-ccw rom now that's
> built from the qemu source. Is that correct? Can we close the s390-tools
> bug at least? And I suppose arrange for s390-ccw.rom to be shipped from
> the qemu package?
>
>
On Ubuntu there already is: /usr/share/qemu/s390-ccw.img
which works for me as part package qemu-system-s390x.

That is part of the suggested contribution in bug 874347 already.
See #2 in that bug and the suggestion to accept it without an ubuntu: label
in d/control-in.


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#685134: [s390-tools] please add patch from qemu

[Philipp Kern]

On 02/03/2016 09:27 AM, Viktor Mihajlovski wrote:
> On 02.02.2016 01:01, Dimitri John Ledkov wrote:
>> On Fri, 17 Aug 2012 11:21:04 +0200 bastien ROUCARIES
>>  wrote:
>>> Please add http://repo.or.cz/w/s390-tools.git for booting s390 from qemu. 
>>> it port virtio.
>>> I have ported the pach queue to recent s390-tools. Not tested only merge 
>>> without conflict.
>> Is this still required? I see that qemu-2.5 has support for booting El
>> Torito .iso images, and it boots Debian off virtio block drives just
>> fine.
>>
>> Granted, it looks like debian packaging strips the s390 firmware file,
>> and doesn't rebuild it. Maybe that should simply be fixed and that's
>> it?
> Right, including the firmware file would be the proper way to enable
> QEMU for booting on s390.

If I understand it correctly, this is now obsoleted by the fact that
qemu dropped s390-virtio and runs with their own s390-ccw rom now that's
built from the qemu source. Is that correct? Can we close the s390-tools
bug at least? And I suppose arrange for s390-ccw.rom to be shipped from
the qemu package?

Kind regards and thanks
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Processed: Merge two equivalent bugs

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forcemerge 685134 685988
Bug #685134 [s390-tools] [s390-tools] please add patch from qemu
Bug #685134 [s390-tools] [s390-tools] please add patch from qemu
Marked as found in versions s390-tools/1.16.0-1.
Bug #685988 [s390-tools] please provide arch-all package with zipl firmware
Severity set to 'important' from 'normal'
684909 was blocked by: 685988
684909 was not blocking any bugs.
Removed blocking bug(s) of 684909: 685988
Added tag(s) patch.
Merged 685134 685988
> severity 685134 normal
Bug #685134 [s390-tools] [s390-tools] please add patch from qemu
Bug #685988 [s390-tools] please provide arch-all package with zipl firmware
Severity set to 'normal' from 'important'
Severity set to 'normal' from 'important'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
684909: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684909
685134: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685134
685988: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685988
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Unmark patch

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # patch contains many new code paths to be maintained
> # not applicable as-is
> tag 685134 - patch
Bug #685134 [s390-tools] [s390-tools] please add patch from qemu
Bug #685988 [s390-tools] please provide arch-all package with zipl firmware
Removed tag(s) patch.
Removed tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
685134: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685134
685988: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685988
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#685134: Bug#684909: Bug#685134: [s390-tools] please add patch from qemu

[Aurelien Jarno]

On 2017-10-19 16:31, Philipp Kern wrote:
> On 10/19/2017 03:06 PM, Michael Tokarev wrote:
> > Debian has much stricter policy wrt blobs (DFSG),
> > and debian builds for more architectures (the firmware,
> > if it is part of qemu-system-s390 package, needs to be
> > built on all architectures where this binary package
> > builts, or it needs to be a separate arch-all package).
> 
> Note that the arch:all autobuilders are amd64. gcc-*-s390x-linux-gnu
> exists in Debian, although only on i386 and amd64. I don't think there's
> a policy today that precludes you from forcing users to build arch:all
> on amd64 for technical reasons.

Indeed that's one option to build it, that's for example the solution
chosen to build slof using gcc-powerpc64-linux-gnu. So far nobody
complained it's buildable only on amd64, i386, ppc64el and x32.

The other alternative is to build a cross-compiler using binutils-source
and gcc-source (that requires that the none or elf os is supported for
this architecture). This has the advantage of ignoring all the flags
that debhelper tries to push that make a firmware to not build or break.
That's the solution chosen for example for openbios.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#685134: Bug#684909: Bug#685134: [s390-tools] please add patch from qemu

[Aurelien Jarno]

On 2017-10-19 18:15, Dimitri John Ledkov wrote:
> On 19 October 2017 at 15:31, Philipp Kern  wrote:
> > On 10/19/2017 03:06 PM, Michael Tokarev wrote:
> >> Debian has much stricter policy wrt blobs (DFSG),
> >> and debian builds for more architectures (the firmware,
> >> if it is part of qemu-system-s390 package, needs to be
> >> built on all architectures where this binary package
> >> builts, or it needs to be a separate arch-all package).
> >
> > Note that the arch:all autobuilders are amd64. gcc-*-s390x-linux-gnu
> > exists in Debian, although only on i386 and amd64. I don't think there's
> > a policy today that precludes you from forcing users to build arch:all
> > on amd64 for technical reasons.
> >
> > Kind regards
> > Philipp Kern
> >
> 
> The s390x firmware in question, is built from source, on Ubuntu, on
> every src:qemu upload on the s390x architecture and shipped in an
> arch:s390x package.
> 
> qemu-system-s390x requires to run on the s390x hardware, as it is
> effectively passthrough kvm only, and is not userspace emulated.
> (Does not work on non-s390x machines).

Maybe because Ubuntu decided to build it only on s390x. Debian ships it
built for other architectures and it works perfectly. You can emulate an
s390x with qemu-system-s390x on amd64, arm or mips. This firmware works
too.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#685134: Bug#684909: Bug#685134: [s390-tools] please add patch from qemu

[Michael Tokarev]

19.10.2017 15:36, Christian Ehrhardt wrote:
> On Thu, Oct 19, 2017 at 2:01 PM, Philipp Kern  > wrote:
> On 02/03/2016 09:27 AM, Viktor Mihajlovski wrote:
> > On 02.02.2016 01:01, Dimitri John Ledkov wrote:
> >> On Fri, 17 Aug 2012 11:21:04 +0200 bastien ROUCARIES
> >> > 
> wrote:
> >>> Please add http://repo.or.cz/w/s390-tools.git 
>  for booting s390 from qemu. it port 
> virtio.
> >>> I have ported the pach queue to recent s390-tools. Not tested only 
> merge without conflict.
> >> Is this still required? I see that qemu-2.5 has support for booting El
> >> Torito .iso images, and it boots Debian off virtio block drives just
> >> fine.
> >>
> >> Granted, it looks like debian packaging strips the s390 firmware file,
> >> and doesn't rebuild it. Maybe that should simply be fixed and that's
> >> it?
> > Right, including the firmware file would be the proper way to enable
> > QEMU for booting on s390.

There's no way to include firmware on debian without actually building it,
and building it, as far as I can see, only works on s390 architecture.
That's why we don't build other firmware stuff - either lack of cross-
compiler on all necessary architectures, or the requiriment to have
actual system of the necessary architecture (virtual or real). It'd be
nice to have it all in one place.

> If I understand it correctly, this is now obsoleted by the fact that
> qemu dropped s390-virtio and runs with their own s390-ccw rom now that's
> built from the qemu source. Is that correct? Can we close the s390-tools
> bug at least? And I suppose arrange for s390-ccw.rom to be shipped from
> the qemu package?
> 
>  
> On Ubuntu there already is: /usr/share/qemu/s390-ccw.img
> which works for me as part package qemu-system-s390x.
> 
> That is part of the suggested contribution in bug 874347 already.
> See #2 in that bug and the suggestion to accept it without an ubuntu: label 
> in d/control-in.

Debian has much stricter policy wrt blobs (DFSG),
and debian builds for more architectures (the firmware,
if it is part of qemu-system-s390 package, needs to be
built on all architectures where this binary package
builts, or it needs to be a separate arch-all package).

I'll take look at all this once again.

It looks like the s390-tools bug can be closed indeed.

Thanks,

/mjt

Bug#685134: Bug#684909: Bug#685134: [s390-tools] please add patch from qemu

[Philipp Kern]

On 10/19/2017 03:06 PM, Michael Tokarev wrote:
> Debian has much stricter policy wrt blobs (DFSG),
> and debian builds for more architectures (the firmware,
> if it is part of qemu-system-s390 package, needs to be
> built on all architectures where this binary package
> builts, or it needs to be a separate arch-all package).

Note that the arch:all autobuilders are amd64. gcc-*-s390x-linux-gnu
exists in Debian, although only on i386 and amd64. I don't think there's
a policy today that precludes you from forcing users to build arch:all
on amd64 for technical reasons.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#685134: Bug#684909: Bug#685134: [s390-tools] please add patch from qemu

[Dimitri John Ledkov]

On 19 October 2017 at 15:31, Philipp Kern  wrote:
> On 10/19/2017 03:06 PM, Michael Tokarev wrote:
>> Debian has much stricter policy wrt blobs (DFSG),
>> and debian builds for more architectures (the firmware,
>> if it is part of qemu-system-s390 package, needs to be
>> built on all architectures where this binary package
>> builts, or it needs to be a separate arch-all package).
>
> Note that the arch:all autobuilders are amd64. gcc-*-s390x-linux-gnu
> exists in Debian, although only on i386 and amd64. I don't think there's
> a policy today that precludes you from forcing users to build arch:all
> on amd64 for technical reasons.
>
> Kind regards
> Philipp Kern
>

The s390x firmware in question, is built from source, on Ubuntu, on
every src:qemu upload on the s390x architecture and shipped in an
arch:s390x package.

qemu-system-s390x requires to run on the s390x hardware, as it is
effectively passthrough kvm only, and is not userspace emulated.
(Does not work on non-s390x machines).

Therefore src:qemu should build s390x specific firmware and ship in
arch:s390x package as if it is an s390x-specific binary.

Stuff about arch:all autobilders etc do not in practice cause any
constraints here since this particular firmware is useless in a non
_s390x.deb.

There are no plans to make qemu-system-s390x able to perform userspace
emulation on non-s390x architectures.

-- 
Regards,

Dimitri.