Re: Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On 14.06.20 17:20, Philipp Kern wrote:
> On 11.05.20 11:53, Winfried Münch wrote:
>> 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.
>
> 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.
The good news is that with Debian stable 10.6 that was released today
the installation actually works again and I was able to conduct a
successful one from within z/VM.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On Wed, Jun 17, 2020 at 02:54:37PM -0400, R P Herrold wrote: > On Wed, 17 Jun 2020, Adrian Bunk wrote: >... > > 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. > > '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] >... You skipped the relevant part I wrote before that: > > 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. 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/msg2.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 > -- Russ herrold cu Adrian
Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On Wed, 17 Jun 2020, Adrian Bunk wrote: > On Wed, Jun 17, 2020 at 12:20:46PM +0200, Piotr Kolasi?ski wrote: > > On Tue, Jun 16, 2020 at 11:24:11AM +0300, Adrian Bunk wrote: > >... > > > 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] > > I don't agree. Fact, that s390x doesn't have direct display doesn't mean > > that graphical tools are not used. > >... > > 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. 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 > I do not know whether there is anything special about threading on s390x > compared to other Linux architectures, but porters are expected to know. A reproducer was not included. File a bug and I'll look at it > 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. '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] > > > 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. > > Good point - the question is why there is not so many people with "good > > knowledge of Debian" in Mainframe environment? 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 > 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. 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 -- Russ herrold
Re: Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On Wed, Jun 17, 2020 at 05:11:02PM +0300, Adrian Bunk wrote: > 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. OK - I see that there is no chance to save this arch in Release. It seems that decision has been made. I'm wondering why the architecture had been ported in previous releases and who did it. Why to start porting if it is unnecessery for anyone. > > 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. > Is any porter available for that platform? Based on your previous messages I assume that no - the last release was done by automata (it explain also why installation media lacks of some packages and installation process fails). Sorry to are real porters if they exits for previous sentence. Yes I saw this question - for me personally, the problem is that I don't know all aspects of porting, I cannot even try to answer, because I don't know where and how to check described bug. Yes I know, today creating software like Debian (and other) means to be tribe in the machine. Probably I have to spend long time to understand all dependencies, systems, access right to be a bit like porter. > 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. That is not true - you just don't know such persons :-) > > 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. > Yes definitly - if make businnes you have to pay. No other rules. > >... > > > IMHO it would be best if s390x would become a non-release architecture > > > in ports. > 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. So how to help? > > > (and some people abandon it or switch to Ubuntu > >... > > What people are you talking about? > > Philipp made a good point that the Debian s390x port might already have > no users at all left. > Hmm - so I'm dead, nor exist. And in minimum one other who I know directly. Anyway - once again - thanks for everyone who spend time (and money) for Debian. Piotr
Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On Wed, Jun 17, 2020 at 12:20:46PM +0200, Piotr Kolasiński wrote: > On Tue, Jun 16, 2020 at 11:24:11AM +0300, Adrian Bunk wrote: >... > > 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] > I don't agree. Fact, that s390x doesn't have direct display doesn't mean > that graphical tools are not used. >... 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. >... > 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? >... 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. >... > > 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. > Good point - the question is why there is not so many people with "good > knowledge of Debian" in Mainframe environment? >... 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 of potential > mainframe users know that Debian supports s390x architecture? If not > many - why? >... 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. >... > > IMHO it would be best if s390x would become a non-release architecture > > in ports. > My previous message was sent because I worry, that if this architecture > will become not-release, after short time disappear 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. > (and some people abandon it or switch to Ubuntu >... What people are you talking about? Philipp made a good point that the Debian s390x port might already have no users at all left. > Piotr cu Adrian [1] https://lists.debian.org/debian-s390/2020/06/msg00015.html
Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On Tue, Jun 16, 2020 at 11:24:11AM +0300, Adrian Bunk wrote: > On Mon, Jun 15, 2020 at 12:17:39AM +0200, Vctl Piotr Kolasinski wrote: > >... > > 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. > > 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. 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. > > 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. > Is that not why Linux is so popular - portability? > 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] 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). > > 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. 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? > > IMHO it would be best if s390x would become a non-release architecture > in ports. 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). > > 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. 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
Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On Mon, Jun 15, 2020 at 12:17:39AM +0200, Vctl Piotr Kolasinski wrote: >... > 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. 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. > Kind Regards > Piotr (aka nome) cu Adrian [1] https://lists.debian.org/debian-s390/2018/12/msg00010.html
Re: Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
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 napisał(a):
>
> On 11.05.20 11:53, Winfried Münch wrote:
> > 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.
>
> 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
>
Re: Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On 11.05.20 11:53, Winfried Münch wrote:
> 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.
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
Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On 6/2/20 5:17 AM, Rod Gaiotto wrote: 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 4 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? Yes, see https://lists.debian.org/debian-s390/2020/05/msg7.html Thanks -- Rodrigo Gaiotto Systems & Software Engineer 19-99169-8485 -- Kind Regards, Viktor
Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
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.
