Hi,
Ron, I don't know exactly why you are pissed off and keep rattling on
and venting your frustation in these bug reports. It takes you more
time to discuss than to fix the issues, or even discussing them
calmly.
I send this in public because of your public accusations to me for
lack of due diligence.
For the last time:
1) With libogg, I already applied the fix to libogg locally back in
March, and the issue in OpenRISC/or1k was indeed misdetection of the
machine/architecture, I don't know why you are saying in the last
message that this was not the issue and that I'm inventing things,
because this was the problem. There's no "or1k" when grepping the
source directory.
I submitted the bug at that point, with the patch that I applied to
fix the issue locally (#744721); because if somebody uploaded new
versions to the package without fixing the issue, we would have to
apply the local fix time and again.
For the very same reason, to avoid fixing things locally time and
again with numerous packages, porters working in the 4 new ports
submitted ~900 bug reports so far (likely to increase) to packages
failing to build different architectures, and dh-autoreconf was deemed
the best solution to solve this in most cases. Not because we cannot
do local fixes to packages, but because we don't want to do fixes
again and again to hundreds of packages once that we verify the cause,
and when the fix is well known. Most Debian developers agree with
that.
This was discussed in debian-devel@ months ago, I think that starting
in January.
2) Other Debian developers --including me-- think that not only is
good to use dh-autoreconf (or equivalent, at least autotools-dev) when
needed, but that it's an enhancement to the quality of the packages to
build automatically from configure.ac -- which is the solution that
it's being proposed in these bug report. Or at least update
config.{guess,sub} automatically, which is what Matthias proposed when
reopening the bug report.
So even if using dh-autoreconf would not fix this particular issue, as
you claim, there's value in doing that and it might well become
recommended or mandatory soon.
In any case, again and for the last time, this was discussed in
debian-devel@ in the last few months, and if you do not agree with the
procedure the appropriate place to complain about this is that mailing
list with your fellow developers and try to convince them, instead of
complaining about our behaviour in these bug reports to vent your
frustations and try to convince us about the futility of the method --
we happen to like it, and so seem to do most Debian developers.
3) I was looking at other Xiph packages, and NMUed a few of them with
the agreement of the only developer who bothered to reply after
messages to the mailing list. My uploads allowed to build libvorbis
(among others) automatically (without local fixes) for arm64 [1] and
or1k [2] for the first time (only log entries for my recent upload
1.3.2-1.4, when they've been attempting to build for a long time).
[1] http://buildd.debian-ports.org/status/logs.php?pkg=libvorbis&arch=arm64
[2] http://wannabuild.cmd.nu/logs.php?pkg=libvorbis&arch=or1k
That's how I arrived to opus-tools, being related to Xiph. Seeing bug
report #727481 to opus-tools, I assumed that Matthias Klose had
similar good reasons to the point explained in 1) (that he could not
build ppc64el) to submit the bug.
It didn't build automatically in the wannabuild of OpenRISC/or1k
either, I don't know if due to problems with the package in the
architecture or why, but it built fine with my local fixes updating
the architecture so it's likely related with that. But it doesn't
matter: if it didn't build in ppc64el was enough reason for me/us to
attempt to fix this.
Anything that doesn't build cleanly only months before the freeze on
architectures that intend to be released, is a bug and a blocker, and
will be fixed in one way or another, so your question about "when will
it become a blocker" does not make sense, and you didn't reply to the
bug reports when they were submitted until we/I started nagging.
I was prepared to NMU packages which were apparently unmaintained (the
rest of the Xiph ones are like that). I emailed you for that reason,
after months of you not replying to the bug report, to ask if it was
OK to NMU and declaring my intention. It's a perfectly reasonably
thing to do and supported by recommendations if the guides, if you
don't like it I am sorry.
That's the full story, and it's justified to try to attempt to fix
this, and done in a proper way. If you don't agree, as long as you
fix the problems with your packages in one way or another: fine.
Maybe in the future you don't have that option, but at the moment you
do.
It would help if you just said "I'm not convinced of the merits of
dh-autoreconf just yet, I'll keep it doing by hand at the moment", and
didn't reply in such a confrontational way and rambling.
Now, if you accept suggestions on more productive ways in which to
spend your time in Debian instead of bashing your fellow contributors,
you could also for example use your time in replying to the bug
reports submitted to your packages in time, before other developers
start thinking about NMUing your package due to lack of response.
There is also no shortage of problems to focus your energy on, even
without leaving your own packages and focusing on quality only. Just
to pick libao, there's e.g. #680744 to which you didn't even reply
after 2 years (including missing features introduced after your first
upload of the package. So it's not only NMUs that introduce problems,
and sometimes maintainers are not so careful when testing that their
packages continue to work, is it?).
Or #638741 in which you also spent more time handwaving about
imaginary issues with Multi-Arch than fixing a release goal for
wheezy, when almost all important Debian packages converted to
multi-arch at this point without major problems and many benefits.
End of communication from my side, thanks for the effective (if
reluctant) co-operation.
Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
