Skip to content

source path prefix stripping is odd on Debian #2358

@dkg

Description

@dkg

In #2146 there was a nice cleanup to make sure the full source path isn't embedded in the error strings. I appreciate this for reproducibility.

However, test_warning_source_path_prefix_cropping is failing in debian with error messages like this:

AssertionError: Regex didn't match: '(?s)^.*\\[signature_validate\\(\\) [/\\\\]lib[/\\\\]crypto[/\\\\]signatures.cpp:[0-9]*\\] Insecure hash algorithm [0-9]*, marking signature as invalid.*$' not found in '[signature_validate() es.cpp:170] Insecure hash algorithm 2, marking signature as invalid.\n[signature_validate() es.cpp:170] Insecure hash algorithm 2, marking signature as invalid.\n'

That's a little hard to read, but i think what's happening is that the prefix cropping is somehow being applied twice when built in the debian environment (you can see that rather than [signature_validate() /lib/crypto/signatures.cpp:170] the actual warning string is: [signature_validate() es.cpp: 170]) i don't fully understand b618d20 but it looks like it might be related to -fmacro-prefix-map=OLD=NEW which was used by the reproducible-builds project (see also gcc docs).

I think i can work around this in Debian by reverting b618d20 (i think debian's standard build process doesn't have the same problem because it's fixed systemically), but it'd be nice to have things work on platforms which have a clean/reproducible implementation of __FILE__ anyway.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions