Hi, Jochen Sprickerhof <[email protected]> (2026-07-15): > # xorg stuff > %xf86-input-multitouch: !s390x > %xf86-input-wacom: !s390x > %xserver-xorg-input-aiptek: !s390x > %xserver-xorg-input-elographics: !s390x > %xserver-xorg-input-joystick: !s390x > %xserver-xorg-input-mouse: !s390x > %xserver-xorg-input-mutouch: !s390x > %xserver-xorg-input-synaptics: !s390x > %xserver-xorg-video-ati: !s390x > %xserver-xorg-video-cirrus: !s390x > %xserver-xorg-video-fbdev: !s390x > %xserver-xorg-video-mach64: !s390x > %xserver-xorg-video-mga: !s390x > %xserver-xorg-video-neomagic: !s390x > %xserver-xorg-video-nouveau: !s390x > %xserver-xorg-video-r128: !s390x > %xserver-xorg-video-savage: !s390x > %xserver-xorg-video-siliconmotion: !s390x > %xserver-xorg-video-sisusb: !s390x > # graphical > %rootskel-gtk: !s390x > > https://salsa.debian.org/wb-team/packages-arch-specific/-/blob/sid/Packages-arch-specific > > I am mailing you as you are listed as the maintainer of some of these > packages. We would like to drop the complete Packages-arch-specific file. > > To keep a package from being built on s390x, one option would be adding > something like this to d/control: > > Build-Depends: do-not-build-on-s390x [s390x] > > Another option would be to just build the packages on s390x too.
As far as rootskel-gtk is concerned, letting it build on s390x shouldn't change much. Ditto for the few xserver-xorg-* that produce udebs (which should be input-libinput and video-fbdev). If those end up being problematic on the debian-cd side, we have an exclude mechanism that can be used to drop any extraneous udebs. I don't remember the exact details, but s390x is special-cased already, with fewer images being built anyway. TL;DR: Dropping P-a-s without adjusting those packages shouldn't be an issue from a d-i point of view. Cheers, -- Cyril Brulebois ([email protected]) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
