On 2014-08-28 20:49:53, DOM wrote:
Show quoted text> Dear Maintainer,
>
> The Debian perl group is reviewing packages with bugs which make them
> un-releasable; in particular when they are not heavily used by Debian
> users. We would like to remove such modules from Debian if we don't
> think they are likely to be fixed.
>
> Devel::BT is one such module, owing to this bug, and we would like to
> know whether you have any plans to look at the bug in the foreseeable
> future before we remove the package from Debian.
>
> If we don't hear anything we will remove the package from Debian on or
> around 19th September. This of course does not affect the standing of
> your module on CPAN.
>
> Thank you for maintaining this module so far!
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!
