Your message dated Tue, 6 Nov 2018 17:23:07 +0100
with message-id
<cafuez4yrexantuzfcoznbzi5adnxtcepmhmfbko0fkgm4ze...@mail.gmail.com>
and subject line Can be closed
has caused the Debian Bug report #912834,
regarding xiphos: missing build on ppc64el: suggestion to remove it there
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
912834: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912834
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: xiphos
Version: 4.0.7.1-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Dear Maintainers,
The package xiphos currently does not build on architecture ppc64el.
There is a patch for it, and this patch is in libsword.
But this libsword is not going into auto-transition mode soon.
In the mean time package xiphos as is now in testing is not linked to the
correct libsword version.
So it won't run on testing right now.
And this was due to me not following the proper route of the transition.
A new build of xiphos was made.
That new build links to the correct libsword.
So Xiphos works with that new build.
But now a missing build on ppc64el will prevent this correctly working xiphos
package
from being migrated to testing.
See this link:
https://qa.debian.org/excuses.php?package=xiphos
My suggestion is to now request removal of xiphos version 4.0.7.1-4
from architecture ppc64el.
So the remaining xiphos binaries will migrate to testing soon.
Is there a problem with this approach?
If there's no problem with this, I intend to move on with this.
This bug is actually to keep track of this issue.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
Generally a RM request is practically a last resort and isn't needed when a
future upload will fix the problem.
--
Teus Benschop
[email protected]
0318 712046
--- End Message ---
