Re: Usage of real m68k hardware
Hi Andreas,
I second Wouter's suggestion to file bugs at severity levels impacting
release criteria only if the bug has been reproduced on actual hardware.
And I can also understand Adrian's frustration well - a long time ago, I
did host crest and kullervo and dealt with quite a few packages not
building from source on these (we didn't have qemu or even ARAnyM
buildds then).
Regarding ARAnyM: that would be a step between qemu and hardware in the
chain to reproduce faults.
And yes - I still run m68k hardware, though for the purpose of kernel
work these days.
Cheers,
Michael
Am 30.03.2018 um 01:07 schrieb Wouter Verhelst:
> On Wed, Mar 28, 2018 at 08:38:10AM +0200, Andreas Tille wrote:
>> Hi,
>>
>> recently some R packages received bugs that seem to stem from a problem
>> with the build setup (specifically, a qemu bug). When I asked back in
>> one of the bugs[1] whether there are real m68k users I've got the answer
>>
>> ... there are still some users with actual hardware, but the
>> autobuilders use qemu for better performance and/or reliability
>>
>> I conclude that the Debian project is running no real m68k hardware any
>> more (please correct me if I'm wrong) and we are possibly doing a
>> service for some users who potentially also run qemu (wild guess of
>> mine). I'm wondering when it might be time to fully drop a hardware
>> port instead of draining developer time for ethernity.
>
> I understand your desire to not be bothered with bugs that are not
> yours. That makes sense.
>
> However, it does *not* make sense to then tell others that their work is
> not welcome anymore. If people want to spend time doing what you think
> is useless busywork, then, as long as they don't bother you with things
> that aren't your fault, why not let them?
>
> Under "don't bother you with things", I mean to say that:
> - Bugs should not be filed unless it can be reproduced on actual
> hardware.
> - Bugs should not be filed at RC severity unless the bug is reproducible
> on a release architecture, or can be proven to be an actual bug in the
> package
>
> As for the former: Adrian, I recently passed a bunch of m68k machines to
> you. Would it make sense to set (some of) those up as secondary buildd
> hosts? That is, try to build everything on emulated machines first
> (because those are much faster). If something FTBFS, try to rebuild it
> on hardware. If it FTBFS there, bugs can be filed; if not, upload the
> package and track down the emulator bug...?
>
> (if you're already working on that, then ignore what I said :-)
>
Reply to: