package: s390-tools

Version: current Installer from 04.05.2020 21:14
http://ftp.halifax.rwth-aachen.de/debian/dists/buster/main/installer-s390x/current/images/generic/

When I install debian I run in this Problem (from console 4):

May 11 09:43:43 debootstrap: Errors were encountered while processing:
May 11 09:43:43 debootstrap:  s390-tools
May 11 09:43:44 debootstrap: dpkg: dependency problems prevent
configuration of s390-tools:
May 11 09:43:44 debootstrap:  s390-tools depends on perl:any.
May 11 09:43:44 debootstrap:
May 11 09:43:44 debootstrap: dpkg: error processing package s390-tools
(--configure):
May 11 09:43:44 debootstrap:  dependency problems - leaving unconfigured

Installation failed in step install base system.

Hello folks,

I'm attempting to install a Debian 10.4.0-s390x in a z/VM system under a
zEC12 CEC - 2827

I've set 1 CPs + 1 GB of memory and a 40000 cyls DASD (30 Gbs ~).

The installation crashes during the OS base installation step. Follow the
logs:

Jun  2 02:55:59 debootstrap: Processing triggers for systemd (241-7~deb10u4) ...
Jun  2 02:55:59 debootstrap: Errors were encountered while processing:
Jun  2 02:55:59 debootstrap:  s390-tools
Jun  2 02:56:00 debootstrap: dpkg: dependency problems prevent
configuration of s390-tools:
Jun  2 02:56:00 debootstrap:  s390-tools depends on perl:any.
Jun  2 02:56:00 debootstrap:
Jun  2 02:56:00 debootstrap: dpkg: error processing package s390-tools
(--configure):
Jun  2 02:56:00 debootstrap:  dependency problems - leaving unconfigured
Jun  2 02:56:00 debootstrap: Errors were encountered while processing:
Jun  2 02:56:00 debootstrap:  s390-tools
Jun  2 02:56:01 debootstrap: dpkg: dependency problems prevent
configuration of s390-tools:
Jun  2 02:56:01 debootstrap:  s390-tools depends on perl:any.
Jun  2 02:56:01 debootstrap:
Jun  2 02:56:01 debootstrap: dpkg: error processing package s390-tools
(--configure):
Jun  2 02:56:01 debootstrap:  dependency problems - leaving unconfigured
Jun  2 02:56:01 debootstrap: Errors were encountered while processing:
Jun  2 02:56:01 debootstrap:  s390-tools
Jun  2 02:56:02 debootstrap: dpkg: dependency problems prevent
configuration of s390-tools:
Jun  2 02:56:02 debootstrap:  s390-tools depends on perl:any.
Jun  2 02:56:02 debootstrap:
Jun  2 02:56:02 debootstrap: dpkg: error processing package s390-tools
(--configure):
Jun  2 02:56:02 debootstrap:  dependency problems - leaving unconfigured
Jun  2 02:56:02 debootstrap: Errors were encountered while processing:
Jun  2 02:56:02 debootstrap:  s390-tools
Jun  2 02:56:03 debootstrap: dpkg: dependency problems prevent
configuration of s390-tools:
Jun  2 02:56:03 debootstrap:  s390-tools depends on perl:any.
Jun  2 02:56:03 debootstrap:
Jun  2 02:56:03 debootstrap: dpkg: error processing package s390-tools
(--configure):
Jun  2 02:56:03 debootstrap:  dependency problems - leaving unconfigured
Jun  2 02:56:03 debootstrap: Errors were encountered while processing:
Jun  2 02:56:03 debootstrap:  s390-tools
Jun  2 02:56:18 base-installer: error: exiting on error
base-installer/debootstrap-failed
Jun  2 02:56:20 main-menu[296]: WARNING **: Configuring
'bootstrap-base' failed with error code 1
Jun  2 02:56:20 main-menu[296]: WARNING **: Menu item 'bootstrap-base' failed.
Jun  2 02:56:25 main-menu[296]: INFO: Modifying debconf priority limit
from 'high' to 'medium'
Jun  2 02:56:25 debconf: Setting debconf/priority to medium
Jun  2 02:56:29 main-menu[296]: INFO: Menu item 'save-logs' selected


Does anybody got the same error?

Thanks

Yes, see https://lists.debian.org/debian-s390/2020/05/msg00007.html

perl:any is not part of the transitive closure that debootstrap
calculates. To me it looks like a bug in debootstrap in that it does not
find a deb to download because it does not drop the :any - either in
pkgdetails or before.

This was presumably broken by 2.3.0-1 which packaged ziomon and included
a ${perl:Depends} on the main package as well - possibly because Lintian
alerted about the missing dependency. That was technically correct, as
it includes binaries that require modules from perl rather than
perl-base. And it would presumably have worked if "perl:any" had instead
been substituted as "perl".

It's pretty telling how late this was discovered, sort of pointing out
that Debian s390x has no users at all if that kind of bug slips into a
stable release. Ubuntu forked the base tooling and thus was not
affected. To be honest, that tells me that the port should be demoted
and not be part of the next release. Especially given the lack of
(motivated) porters.

Furthermore it seems like the current debian-installer daily build does
not boot and ends up in disabled PSW before printing even a single line
of output.

I never managed to get any kind of continuous integration going myself
given how hard it is to integrate with existing Debian infrastructure to
test it properly - unless you are an admin there already. Even a qemu
setup would have spotted this particular bug. But without any users who
care I also don't think it is worth spending much time on this.

Kind regards and sorry
Philipp Kern

Hi
I'm new on that list and and notified (from another -email address -
that will be removed), about my desire to help and contribute that
port. Please don't remove it, Debian is only one of two free (not
charged) distributions.
The mainframe platform is evolving, now exist not only IBM Z servers
but also fully dedicated to Linux the LinuxONE servers. I know from
one case in Poland, taht it was very successful to supersede AIX
installation by LinuxOne installation with Oracle database as main
engine.

I also met the problem witch perl:any dependency  (and a few others
during installation), but I resolved them using another installation
(trial RedHat) and debootstrap (with foreign option). The additional
difficulty was lack of Internet access (it is normal in some
environments), but I was determined.
In my opinion the big problem may be w ith access to the real platform
(currently I have access and possibilities but I don't know how long).
Of course we have emulators like hercules (which I use from very long
time) and know qemu s390 port (only with virtio, not tested by me),
but it is probably not enough in power (as long as yo don't have very
powerful emulation platform or use cross-compile). Anyway if Debian
maintainers have access to valid build environment, I think you should
not remove the architecture.

Kind Regards
Piotr (aka nome)

niedz., 14 cze 2020 o 17:20 Philipp Kern <pkern@debian.org> napisał(a):

Hardware is not the problem.
Forcing 1000 volunteers in Debian to support a port that has no porters
and no users is the problem.

Debian has an s390x porterbox that is available to all Debian developers.
For normal package development this is sufficient.

The s390x port has some unique problems.
And with a390x as release architecture package maintainers in Debian are
supposed to fix these problems in their packages if they want their
packages in the next Debian release.

Forcing volunteers to do unpleasant work like porting to s390x is making
it a more attractive choice to stop contributing to Debian.

s390x is the only big endian release architecture.
Big endian hardware has become exotic, and some of the younger
maintainers in Debian might have never seen big endian hardware.
Endian problems are common problems in packages,
and porting software to support big endian can be a real pain.

s390x is the only headless release architecture.
This was a real pain for the Debian GNOME maintainers already before
the last release, without any support from s390x porters on fixing
this issue.[1]

A port like s390x with unique problems is only sustainable when several
people with good knowledge of Debian, s390x hardware and the Linux
kernel have a long-term commitment of swiftly supporting everyone in
Debian with s390x problems.

IMHO it would be best if s390x would become a non-release architecture
in ports.

Architectures in ports are autobuilt like release architectures,
but there is no pressure on the volunteers maintaining packages
in Debian to spend their time on supporting these architectures.
Other architectures like m68k, big endian powerpc, alpha, hppa
and ia64 that also tend to have one dedicated porter each but
not many users left are also in ports.

cu
Adrian

[1] https://lists.debian.org/debian-s390/2018/12/msg00010.html

I understand your point. I just started to read about Debian
maintainers, developers, porteboxes etc., I will not discuss with you.
My mail was sent because I use Debian in any possible place, advertise it,
treat as stable, good alternative to other distros. From other site I
didn't know about unique problems for that arch.
Is that not why Linux is so popular - portability?
I don't agree. Fact, that s390x doesn't have direct display doesn't mean
that graphical tools are not used. Is really good way to thinking about Linux
as desktop system only? In my daily work we have much more Linux boxes
in VM (as host and target) then desktop system (where Windows is the
king and never will change in next 20 years). I still remember that
X Window architecture assume remote operations and local Xserver is only
one of a few possible configurations.
Of course if we assume, that we produce desktop system, the s390x is not
composing with that. I use Debian in many instances - only two of them I
access directly (using graphics), the rest is some kind of "server" (but
I still can reach then graphically using vnc protocol).
Good point - the question is why there is not so many people with "good
knowledge of Debian" in Mainframe environment? How many of potential
mainframe users know that Debian supports s390x architecture? If not
many - why?
About "s390x hardware and the Linux kernel" - I'm just only advanced user
(I hope), but as I know - the kernel support in this area is mostly done
by IBM. Does someone can tell me how many changes have to be done in Debian
and what kind for the kernel? Does we really need many people in this
area?
My previous message was sent because I worry, that if this architecture
will become not-release, after short time disappear (and some people
abandon it or switch to Ubuntu - as long as it exists).
Here is my lack of knowledge - I just started to dig Debian ecosystem as
supporter, I don't know too much about preparing releases, building
packages etc. Last time when I had problems with installation on
Mainframe, I have learned many things about Debian installer, but ...
I even don't know where to start reading about it  be useful for
others. Anyway I want to be active Debian user (partially on the
Mainframe) and I want to help.

Anyway thank for support till this time.


Piotr

Fact is that the s390x port is different from all other ports in Debian.
And it is causing extra work to support such a port.
Which is an even bigger problem when there are no porters doing this work.

Two porters are the minimum requirement for release architectures.

Just yesterday there was a question from a Debian maintainer sent to the
s390 list about an s390x-only problem in a package[1]:

  Any of you have any idea why the threads on s390x behave differently
  than all the other architectures?

I do not know whether there is anything special about threading on s390x
compared to other Linux architectures, but porters are expected to know.

If there is a problem like for example kernel crashes with the Debian
kernel on a Debian machine like a buildd for a release architecture,
someone has to debug the problem swiftly.

Debian does not have a service agreement with IBM for maintaining the
Debian kernel on s390x, it is the duty of the s390x porters to maintain
the Debian kernel and debug problems in the Debian kernel.

Debian is a volunteer project.
s390x is a business-to-business affair.

Other ports have a community of people who have a Raspberry Pi or
an old hppa workstation at home.

Nonne has an old mainframe at home for keeping Debian running on it
as a hobby.

How many companies are buying a mainframe without any software support
contracts with IBM or other companies?

With that kind of financial investment you usually want a Linux
distribution that is supported by IBM, and buy support for that
distribution from the company behind the distribution.

A Debian port disappears when there are not enough porters with the
necessary skills keeping it working.

For non-release architectures one dedicated person is enough.

What people are you talking about?

Philipp made a good point that the Debian s390x port might already have
no users at all left.

cu
Adrian

[1] https://lists.debian.org/debian-s390/2020/06/msg00015.html

A lack of porters is an issue.  The reason I don't 'lend a
hand' here is the Byzantine and opaque nature of Debian 'hoop
jumping'

I say this having approached Ian Murdock (rip), and his former
employee Jeff Licquia, each through the good offices of weekly
LSB conference calls, trying to get past that

A reproducer was not included.  File a bug and I'll look at it

'duty' as a concept in a social voluntary organization is a
slippery concept.  Many people asserting duties by others are
really seeking free support, and then disappear like magic.
That gets tiring, is not sustainable, and long ago at CentOS,
I set the standard and tone that we don't facilitate such
behaviour [that has changed with the RHT/IBM purchase, but
the history stands]

It is true there are not many known outside of more s390x
focussed mailing lists, as there is no material Debian
'uptake' in an Enterprise production environment.  That space
is small enough that it supports about three non IBM, or SUSE
players with more than 20 employees

umm

Not to put too fine a point on this fine rant, but I've been
building and supporting a community rebuild of RHEL for
several years [called ClefOS] now on s390 and s390x (no longer
s390, as interest died off)

I did so back in the days when I was an active member of the
CentOS project (one of its founders, actually), before RHT /
IBM 'bought it out'

I've pushed in fixes needed for LSB / FHS purposes from time
to time in the past

Build machines are readily available, without charge, through
Marist Univerity, as well as the more recent IBM spoonsored
Linux One

As I recall, Alpine has been building a viable s390x
community distribution for the last couple of years as well

Rick Troth ( a well known s390x'er in the community ) has his
'Nord' standalone distribution

You skipped the relevant part I wrote before that:

The Debian System Administrators maintaining the Debian infrastructure
and the Debian Release that are team requiring these kind of commitments
from porters of release architectures, e.g.
https://lists.debian.org/debian-s390/2016/08/msg00002.html

The next Debian release will be supported until mid-2024 on all
release architectures.

Back in 2013 the 32bit SPARC port had one active porter,
who resigned from that position 3 days after the release
of Debian 7.0

cu
Adrian

clone 960265 -1
reassign -1 debootstrap
retitle -1 debootstrap: should handle multi-arch dependencies properly
severity -1 important
severity 960265 serious
thanks

This is also a bug in debootstrap in that it should strip ":any" from
package dependencies when calculating the set of packages to install. It
tries to fetch "perl:any" instead of "perl". See [1].

At the same time bug #960265 is actually of priority serious (breaks
bootstrapping), rather than normal.

Kind regards
Philipp Kern

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960265#20

Is this fixed? An s390x chroot can be debootstrapped now but is that due
to a workaround or has this bug been fixed?