Hello Jonas, On Tue, 31 Dec 2024 16:59, Jonas Smedegaard <[email protected]> wrote: >Hi Manos, > >Thanks for caring about this downstream packaging of your project!
Always! Debian has been my distro since I was a young child learning
about computers and it will forever be in my heart :)
>
>Quoting Manos Pitsidianakis (2024-12-31 13:50:01)
>
>> I'm not familiar with the semantics here, is the Severity "serious"
>> because it failed the entire build?
>
>Yes (I didn't file this bug, but agree with its severity)
>
>> Technically speaking this is a failure in the text fixture from
>> dependency "rusty-fork" used only when compiling tests. So it's not
>> originating from meli.
>>
>> Was this failure reproducible in subsequent build jobs? If not, could we
>> repeat the build to make sure it was not some temporary flakiness in the
>> build runner machine?
>>
>> In the case where it's reproducible, the test can be disabled with a
>> quilt patch. In any case, it's not really a bug in the package itself,
>> but in the test dependency.
>
>From the point og view of Debian, the "package" is the upstream project
>*and* the Debian packaging routines combined.
>
>Failure in access rights related to XDG_DATA_DIR is most often related
>to the intentionally restricted setup of automated build daemons in
>Debian, where the default $HOME directory is not writable.
>
>If that is the cause here, then it is not a bug in the dependency, but
>instead a bug in the Debian packaging of the project, which needs to
>setup a writable XDG_DATA_DIR if truly needed by the project or its
>dependencies.
>
Could it be that the test is inheriting an XDG_DATA_DIR env var from the
builder environment? And that did not happen before.
I see in the test code, file `meli/tests/test_cli_subcommands.rs`, this
env var is not reset:
for var in [
"PAGER",
"MANPATH",
"EDITOR",
"MELI_CONFIG",
"HOME",
"XDG_CACHE_HOME",
"XDG_STATE_HOME",
"XDG_CONFIG_DIRS",
"XDG_CONFIG_HOME",
"XDG_DATA_DIRS",
"XDG_DATA_HOME",
] {
std::env::remove_var(var);
}
The test continues to set only the `MELI_CONFIG` var afterwards which is
contained in the tempdir created for the test:
std::env::set_var("MELI_CONFIG", &conf_path);
But we could also attempt to set new values for the environment
variables we resetted earlier:
for var in [
"HOME",
"XDG_CACHE_HOME",
"XDG_STATE_HOME",
"XDG_CONFIG_DIRS",
"XDG_CONFIG_HOME",
// new entry! <---
"XDG_DATA_DIR",
"XDG_DATA_DIRS",
"XDG_DATA_HOME",
] {
std::env::set_var(var, tmp_dir.path());
}
@Jonas, I can prepare this patch on upstream if you would like to pick
it up, unless there's an easier way to do this on your end. I would
prefer to help as much a possible to spare you going through trouble for
this :)
I got an email about an automatic removal of `meli` from `testing`
because of this bug also, it'd be nice if I can help the process to fix
it in time before it happens also :)
Thanks and happy new year, everyone!
Manos
signature.asc
Description: Digital signature
