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

Re: [rt.cpan.org #93585] Test failures on armel, kfreebsd-amd64, mips



[Adding mips and armhf porters; please see
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721421> for
context.

On Fri, Aug 29, 2014 at 03:53:52PM -0400, Karen Etheridge via RT wrote:

> 11:49 <ether> did you see this? https://rt.cpan.org/Ticket/Display.html?id=93585
> 12:32 <rafl> i did just now for the first time, and i'm not entirely sure how i feel about it
> 12:33  * rafl ponders
> 12:36 <rafl> so, that module is really just a debugging aid for developers and end users
> 12:36 <rafl> the initial motivation to write it was people coming to me with thing segfaulting and me needing a backtrace to make any sense of it
> 12:37 <rafl> but repeatedly walking users through how to use gdb was a big hassle, so i automated it
> 12:38 <rafl> i have a hard time believing there are developers or endusers on mips, armel, and kfreebsd-amd64
> 12:38 <ether> heh
> 12:38 <rafl> that's probably more true for armel and mips than for kfreebsd, but still
> 12:38 <rafl> so i think this would be useful to keep for the architectures it works on
> 12:39 <rafl> cause realistically everyone uses amd64 linux
> 12:39 <rafl> i also think there's a lot of value to having this in debian
> 12:40 <rafl> cause saying "apt-get install libdevel-bt-perl" is a lot easier than walking a newcomer through the four dozen ways of installing modules
> 12:40 <rafl> that's kind of why i asked the perl group to package it in the first place
> 12:41 <rafl> i totally would like to get it working on all platforms, just for the sake of it, but i'm not sure if that's gonna be effort well spent
> 12:41 <rafl> and debian does have ways of providing packages only for certain architectures
> 12:41 <ether> sounds like they should only package it for those architectures where tests pass, then
> 12:42 <ether> or the Makefile.PL can do that check and exit otherwise?
> 12:42 <rafl> well.. 'make test' already bails out if things don't work. i think it'd be better to not hardcode any platform names in Makefile.PL
> 12:43 <rafl> but yeah. if debian could limit the availability of that package to the platforms it's known to work on, i think that'd be ideal
> 12:43 <rafl> though i haven't really been involved much in debian recently, so i'm not sure what the policy on doing that is
> 12:43 <rafl> might be that they only do it for things that are truly platform dependant
> 12:44 <rafl> stuff like grub or yaboot, for example
> 12:45 <rafl> i also know that Leon has been working on a similar module that's using a very different implementation technique
> 12:45 <rafl> rather than spawning gdb he's walking the c call stack and symbol tables and whatnot manually
> 12:45 <rafl> which may or may not be more portable
> 12:46 <rafl> it might be a good idea to investigate if his module provides something functionally equivalent that Devel::bt could be deprecated in favour of
> 12:46 <rafl> i really just want the functionality to be there and easily available to relatively unskilled users - i don't really care if that functionality is provided by Devel::bt or something else
> 12:47 <ether> should I paste this conversation into the ticket and show it to leont?
> 12:47 <rafl> that'd be really nice of you!
> 12:52 <ether> kk!

Hi Karen,

Thanks for fowarding this! Some more details have been discussed on the
Debian BTS, and I've just asked Leon if the new logs are any use for
debugging.

Debian policy has this to say on the matter:
"Specifying a list of architectures or architecture wildcards other than
any is for the minority of cases where a program is not portable or is
not useful on some architectures. Where possible, the program should be
made portable instead."[1]

I don't think excluding mips and armhf (the two architectures where it
used to work) would be an absolute no-go area but it would be frowned
upon.

I'm also CCing the Debian arm and mips porters, in case they can help.

Cheers,
Dominic.

[1] <https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture>


Reply to: