[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: architecture: all but ... (please add armel to architecture list)



Hi Luk,

I wish things were such simple.  Here is the root cause etc.

On Fri, Jan 18, 2008 at 06:58:40PM +0100, Luk Claes wrote:
> Osamu Aoki wrote:
> > Hi, 
> > 
> > Dear porter, please enlighten me.
> > 
> > On Wed, Jan 16, 2008 at 02:26:20PM +0000, Martin Guy wrote:
> >> Package: gsynaptics
> >> Version: 0.9.7-3
> >> Severity: wishlist
> >> User: debian-arm@lists.debian.org
> >> Usertags: eabi
> >>
> >> Please add "armel" to the architecture list in debian/control (or make it "any")
> >>
> >> (A new ARM port should be going into lenny to replace the old one in lenny+1;
> >> see wiki.debian.org/ArmEabiPort)
> > 
> > Since S360 build failure caused me to chose explicit arch list, I
> > think I have to add eabi to fix this bug.  I wish if we can do
> 
> s/s360/s390/

Yes.
 
> What build failure do you mean? 0.9.7-1+b1 as well as 0.9.7-1+b2 built
> fine and 0.9.7-2 didn't have s390 listed anymore as a supported
> architecture...

That is intentional because of Bug #397917.  http://bugs.debian.org/397917

What I meant by "build failure" was that an uninstallable package was
created, I think.

> Why would you remove the support for an architecture when it doesn't
> build anymore, shouldn't you rather fix it to build on that architecture
> again in that case? From looking at the binNMU version numbers, the
> build failure was only temporary anyway...

I hoped if it were so.

> The best thing you can do is mark it Arch: any again and inform the s390
> buildd maintainer (Bastian Blank) about that unless you have a valid
> reason not to build it on s390 anymore?

Well, he is the one who told me as follows in the bug report for Bug #397917:

> Package: gsynaptics
> Version: 0.9.7-1
> Severity: serious
> 
> gsynaptics lists s390 as supported (Architecture: any) but
> xserver-xorg-input-synaptics is not available. This leads to
> uninstallable binary packages.
> 
> Bastian

With serious tag and him being s390 buildd maintainer, I took situation
as that the s390 buildd maintainer (Bastian Blank) will not build
xserver-xorg-input-synaptics with some good reason thus the only way for
me is not to build gsynaptics.  For me, it looked like that gsynaptic
being so much special as an input device aimed for consumer oriented
system hardware, s390 system being data server oriented may have some
hardware issues to support such thing.  (You know that under the normal
situation, people access s390 system running X-client program from
external X-server.  Not the other way.)

The xserver-xorg-input-synaptics comes from source package
xfree86-driver-synaptics which has Architecture: alpha amd64 arm hppa
i386 ia64 m68k mips mipsel powerpc sparc

(See http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=xfree86-driver-synaptics)

So the root cause of trouble is the missing
xserver-xorg-input-synapticis for s390 because the
xfree86-driver-synaptics maintainer chose to use an explicit
architecture list without s390 for some good reason.

I do not see armel here either.  So fixing my package only will cause the same
issue and response from the s390 buildd maintainer.

OK, let me dig more to get wider issue.  I know it is funny but I have
no such issue for tpconfig (3.1.3-9) although I never know if it works
for s390.  As I see qsynaptics and ksynaptics suffer the same problem
due to missing xserver-xorg-input-synaptics.

Another interesting hint was:
  http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xfree86-driver-synaptics
They do not even support powerpc per bug #334733 due to the kernel
issue.  (Strange to see it is build for that atchitecture, though.)

I do not know the issue is s390 kernel code or not, but before asking
gsynaptics, qsynaptics and ksynaptics, you should convince
xfree86-driver-synaptics package maintainer first.  Maybe before that,
you may need to fix kernel issues.

Osamu

PS: CCing people involved.


Reply to: