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

Re: Arch: any Packages (Test::Valgrind)

Hi Jonas, and all:

I e-mailed Vincent directly and he said:
"Technically, it's a pure perl module. The XS file is indeed only used
for testing, and it's only build if there's an available C compiler.
So you don't need it at all for using the module, or even for testing

So I propose we move it to an Arch: all package, which should fix our
FTBFS errors (except where valgrind itself is broken, but that's the
responsibility of the valgrind maintainer, rather than



On Mon, Nov 30, 2009 at 11:08 AM, Jonas Smedegaard <dr@jones.dk> wrote:
> On Mon, Nov 30, 2009 at 10:49:53AM -0500, Jonathan Yu wrote:
>> On Mon, Nov 30, 2009 at 6:04 AM, Jonas Smedegaard <dr@jones.dk> wrote:
>>> Hi Jonathan (and others),
>>> On Mon, Nov 30, 2009 at 12:28:57AM -0500, Jonathan Yu wrote:
>>> Build tests in Debian packages do not test if all is possible on all
>>> architectures.  As an example, it is not verified if documentation can be
>>> built on all platforms - it is only built once.
>> True.
>>> So it seems to make most sense to me to *not* build on all archs if the
>>> resulting package is identical on all archs.
>> That's the question, I suppose. From a cursory look, it *does* build
>> the same on all arches, but I think the tests might fail on some
>> platforms while they pass on others. This is why I was considering
>> Arch: any, so at least we'd get FTBFS errors and know which dists
>> don't like valgrind.
> Whether or not _valgrind_ fails on some archs is for valgrind itself to deal
> with, not your Perl wrapper.
> As a comparison, it might be that docbook has a bug that causes some
> documentation package to render its images wrongly when built on some archs
> - but generating that documentation multiple times is insane, as that would
> imply that all other -doc packages should perhaps also build arch-dependent
> "just to be on the safe side".  The sane approach was for docbook to include
> a testsuite that verifies once per arch at build time (and then throws away
> the result) that all features of that package works as intended for that
> arch.
>>> Beware, that it is not only a matter of the resulting package containing
>>> binary stuff or not - if part of the package e.g. contains some lists of
>>> numbers tat are architecture-specific (that is crucial for its
>>> functionality, not just in documentation or similar) then it is *not*
>>> identical across archs and should be arch any.
>> I don't believe they do, but I haven't looked in depth yet. I'll take
>> a closer look and get md5sums later to compare them all.
> md5sums will only tell you that something is different - make diffs to
> figure out _what_ is different (in non-binary chunks) to be able to make a
> qualified judgement if the changes are important (i.e. variations in spacing
> is often irrelevant but cause md5sum mismatch).
> Kind regards,
>  - Jonas
> P.S.
> Please do not cc me - I am subscribed to the list (and adding me explicitly
> confuses my MUA sorting routines).
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
> Version: GnuPG v1.4.10 (GNU/Linux)
> YtapOe0Ri7sR5jBUUaCRaLXU0ns3W89KNIEkK3sl06elwghX7wt7biWJxoovGohA
> RG+2V/0YOtc5EvEnx/Uu41x0WDJsU+Yp0/LSe21t7IUvLCeyhIqyy4BwiPVQ0gQ0
> Hg8ZJGW8Yj6RbPMtqvOGGIw7VhByY5I2xkjVEMrKNuzChSxuvirnGBG2XTSuWvu4
> P4KM/jiHiijGUdx28WtFlaFW7M1mRH0veQMpTgkjYJy/8kp1bE88QvEMZ+4fotoA
> D08dCfko9x/5uudaePYKEmWbHEOXQSFG/lrh6y62vbXW8Lx1FE1Nel46ou4LQ7vK
> 6GRhC5M7qwvDZ2D6RflgswbNEA1ZvZ684prL4a65doLw9Fq6ZHcnkj1PGu0pc0hy
> CTM/8+wzJGr4aM7HVWv80Goz8IMiNXQWgSFNxKo0kksrdATAkP2P4aUW2uoncj1+
> UW8ECo6vVTw7EsJcg8ilWEmm1Lhz3ZbaQp3mk6lhVWl8B3xPUbE5pNpPmhCUMCAz
> JKSXlMZTtLoFcCW/RF9a2uc1Ejx+lGyiBS0Y4Dkbthigu6JoUmspOwS+e/1kQZ69
> PRyBQOTHq/reHizwlb8S
> =e2f/

Reply to: