[L2Ork-dev] Purr Data 2.4.7 released

Albert Graef aggraef at gmail.com
Sat Jan 6 05:35:04 UTC 2018


Welcome to the Debian bureaucracy. :) Stable Debian releases move at
glacial speed, so I doubt that the valgrind version can be updated there.
The best bet is probably to submit a bug report with a patch to the
existing package which backports this specific bugfix.

NB: I digged some more, and according to
https://packages.debian.org/jessie/valgrind, Jessie uses an even older
version of valgrind (3.10.0) which doesn't exhibit this bug because it just
doesn't check sizeof(TTEntryC) at all. So that's why it works on Jessie,
but not in Stretch.

As far as Ubuntu on ARM is concerned: There's a MATE version of Xenial
(16.04) for the Raspberry Pi 2 and Raspberry Pi 3, which has valgrind
3.11.0 (according to https://packages.ubuntu.com/xenial/valgrind). Looking
at the source, this doesn't appear to check sizeof(TTEntryC) either, so it
*may* work. I'm not sure how useful a version built on that system would be
for Pi users, though, as most Pi users will probably go with Raspbian, and
that means Stretch for now.

The only other possible option I see is to just disable the valgrind check
on ARM for now. That would at least give you a binary that we can upload
(maybe with an "untested" disclaimer) so that Pi users can try it on their
own.

On Fri, Jan 5, 2018 at 11:30 PM, Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> On Fri, Jan 5, 2018 at 4:26 PM, Albert Graef <aggraef at gmail.com> wrote:
> > Bad luck. :( That's clearly a regression in Debian, maybe some kind soul
> > will report it on the Debian bug tracker.
>
> Interesting part of the `reportbug` tool:
>
> Getting status for valgrind...
> Checking for newer versions at madison...
> Your version (1:3.12.0~svn20160714-1+b1) of valgrind appears to be out of
> date.
> The following newer release(s) are available in the Debian archive:
>   testing: 1:3.13.0-1
>   unstable: 1:3.13.0-1
> Do you still want to file a report [y|N|q|?]?
>
> I'm clicking "N" and bailing. If anyone else wants to follow through
> and figure out
> how in the world newer versions of a package in testing and unstable
> are relevant
> to a crasher in the stable package for the chief memory-debugging tool in
> Linux,
> be my guest.
>
> -Jonathan
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
>



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  aggraef at gmail.com
WWW:    https://plus.google.com/+AlbertGraef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20180106/06a57ae6/attachment.html>


More information about the L2Ork-dev mailing list