Debian Bug report logs -
#397917
gsynaptics - lists s390 as supported
Reported by: Bastian Blank <waldi@debian.org>
Date: Fri, 10 Nov 2006 13:18:01 UTC
Severity: serious
Found in version gsynaptics/0.9.7-1
Fixed in version gsynaptics/0.9.7-2
Done: Osamu Aoki <osamu@debian.org>
Bug is archived. No further changes may be made.
Toggle useless messages
Report forwarded to debian-bugs-dist@lists.debian.org, Osamu Aoki <osamu@debian.org>:
Bug#397917; Package gsynaptics.
(full text, mbox, link).
Acknowledgement sent to Bastian Blank <waldi@debian.org>:
New Bug report received and forwarded. Copy sent to Osamu Aoki <osamu@debian.org>.
(full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
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
--
Landru! Guide us!
-- A Beta 3-oid, "The Return of the Archons", stardate 3157.4
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#397917; Package gsynaptics.
(full text, mbox, link).
Acknowledgement sent to Osamu Aoki <osamu@debian.org>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #10 received at 397917@bugs.debian.org (full text, mbox, reply):
On Fri, Nov 10, 2006 at 02:00:32PM +0100, Bastian Blank wrote:
> 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.
I see. But xserver-xorg-input-synaptics has
Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc
This looks agry. Because I need to track new architectures.
Can I do
Architecture: !s390
Anyone have suggestion?
Osamu
Information forwarded to debian-bugs-dist@lists.debian.org, Osamu Aoki <osamu@debian.org>:
Bug#397917; Package gsynaptics.
(full text, mbox, link).
Acknowledgement sent to Mattia Dongili <malattia@linux.it>:
Extra info received and forwarded to list. Copy sent to Osamu Aoki <osamu@debian.org>.
(full text, mbox, link).
Message #15 received at 397917@bugs.debian.org (full text, mbox, reply):
On Fri, Nov 10, 2006 at 11:17:57PM +0900, Osamu Aoki wrote:
> On Fri, Nov 10, 2006 at 02:00:32PM +0100, Bastian Blank wrote:
> > 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.
>
> I see. But xserver-xorg-input-synaptics has
>
> Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc
it was "Architecture: any" with a quinn-diff[1] entry in the past, and
s390 was not supported because xserver-xfree86 wasn't available there.
> This looks agry. Because I need to track new architectures.
>
> Can I do
>
> Architecture: !s390
>
> Anyone have suggestion?
This is ok until you have to add one more unsupported arch to the list.
I think the trade-off here is if you want to add new supported
or unsupported architectures, the latter implying you may need to ask
for removal of the binary (as in the current case for s390), the former
implying a new upload.
Here the discussion I had some time ago:
http://www.mail-archive.com/debian-mentors@lists.debian.org/msg12969.html
Currently (AFAICT) xserver-xorg-input-synaptics seems to be installable
on s390 but maybe it doesn't make much sense...
[1]: http://buildd.debian.org/quinn-diff/Packages-arch-specific
--
mattia
:wq!
Information forwarded to debian-bugs-dist@lists.debian.org, Osamu Aoki <osamu@debian.org>:
Bug#397917; Package gsynaptics.
(full text, mbox, link).
Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Osamu Aoki <osamu@debian.org>.
(full text, mbox, link).
Message #20 received at 397917@bugs.debian.org (full text, mbox, reply):
On Fri, Nov 10, 2006 at 11:17:57PM +0900, Osamu Aoki wrote:
> On Fri, Nov 10, 2006 at 02:00:32PM +0100, Bastian Blank wrote:
> > 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.
> I see. But xserver-xorg-input-synaptics has
> Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc
> This looks agry. Because I need to track new architectures.
> Can I do
> Architecture: !s390
No, this syntax is not supported.
> Anyone have suggestion?
One possibility is to list the package as Architecture: any, but construct
your debian/rules file such that the package fails to build if the
architecture is s390.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#397917; Package gsynaptics.
(full text, mbox, link).
Acknowledgement sent to Osamu Aoki <osamu@debian.org>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #25 received at 397917@bugs.debian.org (full text, mbox, reply):
Hi,
On Fri, Nov 10, 2006 at 03:04:54PM -0800, Steve Langasek wrote:
> On Fri, Nov 10, 2006 at 11:17:57PM +0900, Osamu Aoki wrote:
> > On Fri, Nov 10, 2006 at 02:00:32PM +0100, Bastian Blank wrote:
> > > 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.
>
> > I see. But xserver-xorg-input-synaptics has
>
> > Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc
>
> > This looks agry. Because I need to track new architectures.
>
> > Can I do
>
> > Architecture: !s390
>
> No, this syntax is not supported.
OK.
> > Anyone have suggestion?
>
> One possibility is to list the package as Architecture: any, but construct
> your debian/rules file such that the package fails to build if the
> architecture is s390.
That may be a good solution if I did not have package in testing
including s390. But it is there.
It will waste of autobuilder time and current package stays in testing
and unstable for s390.
Since my packages for all arches are already in testing, the newly
build packages will stay in unstable and old packages stay in testing
due to version difference. So no real gain just doing this.
As I see now, I have few options. What is right?
Option 1)
* Change BTS "#397917: gsynaptics - lists s390 as supported" to "normal"
* Reassign #397917 to xserver-xorg-input-synaptics
* Ask xserver-xorg-input-synaptics to be rebuild as Architecture: any .
I know it is unlikely to hook synaptics device to s390 but then who
will ever bother to set up xserver to start with. I understand that it
is likely to have s390 run X client softwares on it and some X server
to be connected to it for display. I see X server on s390 so I see no
reason not to build xserver-xorg-input-synaptics.
There is also "Hercules" emulator. It may support funny hardware
extension in future too.
Option 2)
* Change BTS "#397917: gsynaptics - lists s390 as supported" to "normal"
* Lazily sit tight.
This removes RC bug but really leaves my package uninstallable in s390.
xserver-xorg-input-synaptics can do what ever he wants.
Option 3)
* Set "Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc"
* Ask ftp-master for removal of package for s390
* Make entry in quinn-diff not to build on s390
This is a lot of CPU time and work for no real gain other than closing
bug.
Option 4)
* Set "Architecture: any"
* Have fancy script to fail in s390.
* Ask ftp-master for removal of package for s390
* Make entry in quinn-diff not to build on s390
This is a lot of CPU time and work for no real gain other than closing
bug.
Osamu
PS: Many device support packages are almost useless for
non-PC/workstation like hardware. This goes with arm and mips too.
Information forwarded to debian-bugs-dist@lists.debian.org, Osamu Aoki <osamu@debian.org>:
Bug#397917; Package gsynaptics.
(full text, mbox, link).
Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Osamu Aoki <osamu@debian.org>.
(full text, mbox, link).
Message #30 received at 397917@bugs.debian.org (full text, mbox, reply):
On Sat, Nov 11, 2006 at 10:20:47AM +0900, Osamu Aoki wrote:
> > > Anyone have suggestion?
> > One possibility is to list the package as Architecture: any, but construct
> > your debian/rules file such that the package fails to build if the
> > architecture is s390.
> That may be a good solution if I did not have package in testing
> including s390. But it is there.
> It will waste of autobuilder time and current package stays in testing
> and unstable for s390.
Uh, no. You need to fix your package to *not* build on s390, and *then* you
can request that the ftp team remove the broken s390 binary from the
archive.
It needs to be done in this order, because if your package is not fixed so
that the source prevents building on the architectures where it's not
supposed to be built, there is a risk that the package will get rebuilt (by
an autobuilder, or by someone being cute), and then the ftp team removal
will have been for nothing.
> As I see now, I have few options. What is right?
> Option 1)
> * Change BTS "#397917: gsynaptics - lists s390 as supported" to "normal"
Wrong.
> * Reassign #397917 to xserver-xorg-input-synaptics
Wrong.
> * Ask xserver-xorg-input-synaptics to be rebuild as Architecture: any .
Wrong.
> I know it is unlikely to hook synaptics device to s390 but then who
> will ever bother to set up xserver to start with.
No, it is *impossible* to hook a synaptics device to s390.
> I understand that it is likely to have s390 run X client softwares on it
> and some X server to be connected to it for display. I see X server on
> s390 so I see no reason not to build xserver-xorg-input-synaptics.
The only X server packages built on s390 are xvfb, xserver-xephyr, and
xnest. None of these operate on real hardware, and none of them can be used
with xserver-xorg-input-synaptics.
> Option 2)
> * Change BTS "#397917: gsynaptics - lists s390 as supported" to "normal"
> * Lazily sit tight.
Wrong.
> Option 3)
> * Set "Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc"
> * Ask ftp-master for removal of package for s390
> * Make entry in quinn-diff not to build on s390
This is an acceptable solution,
> This is a lot of CPU time and work for no real gain other than closing
> bug.
The gain is that it removes a useless package from the archive, saving us a
small amount of archive space and improves the experience of s390 users.
> Option 4)
> * Set "Architecture: any"
> * Have fancy script to fail in s390.
> * Ask ftp-master for removal of package for s390
> * Make entry in quinn-diff not to build on s390
This is an acceptable solution.
> PS: Many device support packages are almost useless for
> non-PC/workstation like hardware. This goes with arm and mips too.
No, you're missing the point. The S/390 port has *no hardware*; in the case
of other architectures, some user *may* hook a synaptics device up to their
computer, but on s390 this is not possible at all because of what s390 is.
Even if the S/390 VM was enhanced somehow to support hooks for this class of
physical hardware, the kernel has no support for it.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#397917; Package gsynaptics.
(full text, mbox, link).
Acknowledgement sent to Osamu Aoki <osamu@debian.org>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #35 received at 397917@bugs.debian.org (full text, mbox, reply):
Hi,
On Fri, Nov 10, 2006 at 05:59:07PM -0800, Steve Langasek wrote:
...
> > Option 3)
> > * Set "Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc"
> > * Ask ftp-master for removal of package for s390
> > * Make entry in quinn-diff not to build on s390
>
> This is an acceptable solution,
...
> > Option 4)
> > * Set "Architecture: any"
> > * Have fancy script to fail in s390.
> > * Ask ftp-master for removal of package for s390
> > * Make entry in quinn-diff not to build on s390
>
> This is an acceptable solution.
I like the latter so I do not interfare with builoding kfreebsd-i386 etc.
...
> > PS: Many device support packages are almost useless for
> > non-PC/workstation like hardware. This goes with arm and mips too.
>
> No, you're missing the point. The S/390 port has *no hardware*; in the case
> of other architectures, some user *may* hook a synaptics device up to their
> computer, but on s390 this is not possible at all because of what s390 is.
> Even if the S/390 VM was enhanced somehow to support hooks for this class of
> physical hardware, the kernel has no support for it.
Considering ease of implimentation, I will be likely to end up with
Option 3. But for kfreebsd-i386 port etc., may be Option 4 is better.
I did some search on how other packages which are likely to face similar
issues by checking likely packages under laptop task and other random
packages which seems to be hardware specific which came to my mind. (I
did not check kernel support for acpi in the source for s390. cpufreq
doc seems to suggest no support for s390)
source Architecture s390-binary
acpi i386 ia64 amd64 no
acpi-support i386 ia64 amd64 no
acpid i386 ia64 amd64 no
hibernate all (no)
hotkey-setup i386 amd64 no
uswsusp i386 amd64 no
xserver-xorg-input-synaptics itemized w/o s390 no
toshset i386 no
toshutils i386 no
tpctl i386 no
thinkpad-base i386 no
thinkpad-source i386 no
motioneye i386 no
i810switch i386 kfreebsd-i386 no
spicctrl i386 no
rsjog i386 no
sjog i386 no
But...
source Architecture s390-binary
apmd any yes
cpufrequtils any yes
pcmciautils any yes
sensors-applet any yes
tpconfig any yes
wireless-tools any yes
wmbattery any yes
Hmmmm I have to do the same for tpconfig since it is also my package.
But none of these with any packages uses Option 4 so I can not take easy
example. (Maybe they deserve bug reports.)
Do I use this line in buid script?
if [ `dpkg-architecture -qDEB_BUILD_ARCH` = "s390" ]; then exit 1; fi
Osamu
Information forwarded to debian-bugs-dist@lists.debian.org, Osamu Aoki <osamu@debian.org>:
Bug#397917; Package gsynaptics.
(full text, mbox, link).
Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Osamu Aoki <osamu@debian.org>.
(full text, mbox, link).
Message #40 received at 397917@bugs.debian.org (full text, mbox, reply):
On Sat, Nov 11, 2006 at 02:11:24PM +0900, Osamu Aoki wrote:
> > > Option 4)
> > > * Set "Architecture: any"
> > > * Have fancy script to fail in s390.
> > > * Ask ftp-master for removal of package for s390
> > > * Make entry in quinn-diff not to build on s390
> > This is an acceptable solution.
> I like the latter so I do not interfare with builoding kfreebsd-i386 etc.
Yes, this is why I recommend it.
> Hmmmm I have to do the same for tpconfig since it is also my package.
> But none of these with any packages uses Option 4 so I can not take easy
> example. (Maybe they deserve bug reports.)
> Do I use this line in buid script?
> if [ `dpkg-architecture -qDEB_BUILD_ARCH` = "s390" ]; then exit 1; fi
Yes, this would do the job fine. You could also do:
if [ `dpkg-architecture -qDEB_BUILD_ARCH` = "s390" ]; then \
echo "not building X server-related packages for s390"; exit 1; \
fi
to give feedback at build time.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Information forwarded to debian-bugs-dist@lists.debian.org, Osamu Aoki <osamu@debian.org>:
Bug#397917; Package gsynaptics.
(full text, mbox, link).
Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Osamu Aoki <osamu@debian.org>.
(full text, mbox, link).
Message #45 received at 397917@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Fri, 2006-11-10 at 15:04 -0800, Steve Langasek wrote:
>
> > Architecture: !s390
>
> No, this syntax is not supported.
What is needed to finally support it? It's been wanted for years now
and is clearly better than not having it.
Thomas
[signature.asc (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Osamu Aoki <osamu@debian.org>:
Bug#397917; Package gsynaptics.
(full text, mbox, link).
Acknowledgement sent to Mattia Dongili <malattia@linux.it>:
Extra info received and forwarded to list. Copy sent to Osamu Aoki <osamu@debian.org>.
(full text, mbox, link).
Message #50 received at 397917@bugs.debian.org (full text, mbox, reply):
On Sat, Nov 11, 2006 at 02:11:24PM +0900, Osamu Aoki wrote:
> Hi,
>
> On Fri, Nov 10, 2006 at 05:59:07PM -0800, Steve Langasek wrote:
> ...
> > > Option 3)
> > > * Set "Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc"
> > > * Ask ftp-master for removal of package for s390
> > > * Make entry in quinn-diff not to build on s390
> >
> > This is an acceptable solution,
> ...
> > > Option 4)
> > > * Set "Architecture: any"
> > > * Have fancy script to fail in s390.
> > > * Ask ftp-master for removal of package for s390
> > > * Make entry in quinn-diff not to build on s390
> >
> > This is an acceptable solution.
>
> I like the latter so I do not interfare with builoding kfreebsd-i386 etc.
Well, the synaptics driver is quite Linux specific, isn't it?
And since xserver-xorg-driver-synaptics is also not built on that
architecture the gsynaptics package will be uninstallable anyway.
--
mattia
:wq!
Reply sent to Osamu Aoki <osamu@debian.org>:
You have taken responsibility.
(full text, mbox, link).
Notification sent to Bastian Blank <waldi@debian.org>:
Bug acknowledged by developer.
(full text, mbox, link).
Message #55 received at 397917-close@bugs.debian.org (full text, mbox, reply):
Source: gsynaptics
Source-Version: 0.9.7-2
We believe that the bug you reported is fixed in the latest version of
gsynaptics, which is due to be installed in the Debian FTP archive:
gsynaptics_0.9.7-2.diff.gz
to pool/main/g/gsynaptics/gsynaptics_0.9.7-2.diff.gz
gsynaptics_0.9.7-2.dsc
to pool/main/g/gsynaptics/gsynaptics_0.9.7-2.dsc
gsynaptics_0.9.7-2_i386.deb
to pool/main/g/gsynaptics/gsynaptics_0.9.7-2_i386.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 397917@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Osamu Aoki <osamu@debian.org> (supplier of updated gsynaptics package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Thu, 16 Nov 2006 18:44:33 +0900
Source: gsynaptics
Binary: gsynaptics
Architecture: source i386
Version: 0.9.7-2
Distribution: unstable
Urgency: low
Maintainer: Osamu Aoki <osamu@debian.org>
Changed-By: Osamu Aoki <osamu@debian.org>
Description:
gsynaptics - configuration tool for Synaptics touchpad driver of X server
Closes: 397917
Changes:
gsynaptics (0.9.7-2) unstable; urgency=low
.
* Matched build architecture with xserver-xorg-input-synaptics package.
(closes: Bug#397917)
* Updated standard version to 3.7.2 (no change).
Files:
1c38c444edc172e3b8dfdbf15f0010f3 703 utils optional gsynaptics_0.9.7-2.dsc
b77c0129fc2d5191e65ef9afac323784 10001 utils optional gsynaptics_0.9.7-2.diff.gz
1d6c073b814ce78e816ae561310b7760 25934 utils optional gsynaptics_0.9.7-2_i386.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFXDhd6A/EwagGHzIRArCVAKCH3w3RyISAnuwhrYWg+KlgjOIF/gCfSW2C
24EFgfUIxiFnX0NsSlMtwEc=
=qgtP
-----END PGP SIGNATURE-----
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Sat, 06 Mar 2010 07:29:40 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Mon Jun 5 03:28:36 2023;
Machine Name:
buxtehude
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.