View Issue Details

IDProjectCategoryView StatusLast Update
0005893GNUnetbuild processpublic2022-09-26 05:01
Reporternikita Assigned Towillow  
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionopen 
Target Version0.17.7 
Summary0005893: replace /tmp in src and elsewhere with something like GNUNET_TMP, again
DescriptionThis comes from reading a bug report never filed with us from a rather creative nixpkg.

For pkgsrc I am in the same position as nixpkgs, /tmp might not always exist (see previous discussions on and the implementation of GNUNET_TMP for config files).
We still hardcode /tmp in some files, and we should use something which is similar to GNUNET_TMP.
Tagschore

Relationships

related to 0006114 closedschanzen Tests failing on Guix System 

Activities

willow

2022-08-28 22:57

developer   ~0019066

I've made some progress with this. I pushed a small branch that removed a lot of references to /tmp in the C files, though a lot of what remains is in Python, shell scripts, and configuration files. I know that it's possible to get configuration values for paths in C source code, but is there a standard way to obtain GNUNET_TMP for Python/shell?

schanzen

2022-08-29 09:05

administrator   ~0019070

Use `gnunet-config` CLI from withing python and parse the output:

$ gnunet-config -f -s PATHS -o GNUNET_TMP

willow

2022-08-29 20:08

developer   ~0019073

Last edited: 2022-08-29 20:36

Thanks for the command.

I'm noticing a lot of duplicated code (sometimes slightly different) to obtain a temporary file path (examples in src/arm/test_gnunet_arm.py.in, src/statistics/test_gnunet_statistics.py.in). I notice that it reads certain environment variables first to find it, then falls back on "/tmp". What is the desired behaviour here? Should the other variables be checked, falling back to GNUNET_TMP, or should we just jump straight to GNUNET_TMP?

There are similar checks in a few of the shell files: ${TMPDIR:-/tmp}

There's at least one FIXME comment that indicates a desire to break those reused bits of code into a separate module. Where exactly would that go?

Tangentially, what does that .in extension specify? I assume it's short for "input" to a macro expander or something similar.

schanzen

2022-08-29 23:03

administrator   ~0019074

I think the goal was to make everything more portable. I am not sure _how_ exactly this issue is supposed to be fixed, however.

".in" files are files produced by automake. They get converted to the "actual" file then ./configure is run. You can, for example, get build time variables and put them into your script using "sed". Useful sometimes for OS-specific paths or binary locations.

Issue History

Date Modified Username Field Change
2019-09-13 19:35 nikita New Issue
2019-11-16 18:38 Christian Grothoff Target Version 0.12.0 =>
2020-04-29 12:20 nikita Relationship added related to 0006114
2020-06-01 00:49 Adminknox Issue cloned: 0006303
2020-10-29 11:15 schanzen Assigned To => schanzen
2020-10-29 11:15 schanzen Status new => acknowledged
2020-10-29 11:15 schanzen Target Version => 0.15.0
2020-11-11 11:03 schanzen Target Version 0.15.0 => 0.14.1
2021-02-21 11:00 schanzen Tag Attached: chore
2021-04-05 11:25 schanzen Target Version 0.14.1 => 0.14.2
2021-06-10 19:37 schanzen Target Version 0.14.2 => 0.15.0
2021-07-31 10:58 schanzen Target Version 0.15.0 => 0.15.1
2022-02-26 23:14 schanzen Target Version 0.15.1 => 0.17.0
2022-06-04 23:13 schanzen Target Version 0.17.0 => 0.18.0
2022-08-28 22:57 willow Note Added: 0019066
2022-08-29 09:05 schanzen Note Added: 0019070
2022-08-29 10:33 schanzen Target Version 0.18.0 => 0.17.4
2022-08-29 10:34 schanzen Target Version 0.17.4 => 0.17.5
2022-08-29 10:35 schanzen Assigned To schanzen => willow
2022-08-29 20:08 willow Note Added: 0019073
2022-08-29 20:08 willow Status acknowledged => assigned
2022-08-29 20:36 willow Note Edited: 0019073
2022-08-29 23:03 schanzen Note Added: 0019074
2022-09-04 11:05 schanzen Target Version 0.17.5 => 0.17.6
2022-09-26 05:01 schanzen Target Version 0.17.6 => 0.17.7