Build failure: reiser4progs and partitionmanager after staging-next 2024-12-04 #361878

[spiage]

Steps To Reproduce

Steps to reproduce the behavior:

1. build reiser4progs or partitionmanager at nixpkgs/master

Build log

error: builder for '/nix/store/8y7805npjq8h21khs1qhjkm3wd2y5hzp-reiser4progs-2.0.5.drv' failed with exit code 2;
       last 25 log lines:
       >   146 |                           "(%llu). Use -f to force over.",
       >   147 |                           result, block_count);
       >       |                                   ~~~~~~~~~~~
       >       |                                   |
       >       |                                   uint64_t {aka long unsigned int}
       > volume.c: At top level:
       > volume.c:174:31: error: initialization of 'int (*)(uint64_t *, uint64_t,  uint32_t,  int,  int)' {aka 'int (*)(long unsigned int *, long unsigned int,  unsigned int,  int,  int)'} from incompatible pointer type 'int (*)(uint64_t *, uint32_t,  uint64_t,  int,  int)' {aka 'int (*)(long unsigned int *, unsigned int,  long unsigned int,  int,  int)'} []
       >   174 |         .advise_stripe_size = advise_stripe_size_simple,
       >       |                               ^~~~~~~~~~~~~~~~~~~~~~~~~
       > volume.c:174:31: note: (near initialization for 'simple_vol_plug.advise_stripe_size')
       > volume.c:177:34: error: initialization of 'uint64_t (*)(uint64_t,  int)' {aka 'long unsigned int (*)(long unsigned int,  int)'} from incompatible pointer type 'uint64_t (*)(uint64_t)' {aka 'long unsigned int (*)(long unsigned int)'} []
       >   177 |         .default_data_capacity = default_data_capacity_simple
       >       |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
       > volume.c:177:34: note: (near initialization for 'simple_vol_plug.default_data_capacity')
       > volume.c:186:31: error: initialization of 'int (*)(uint64_t *, uint64_t,  uint32_t,  int,  int)' {aka 'int (*)(long unsigned int *, long unsigned int,  unsigned int,  int,  int)'} from incompatible pointer type 'int (*)(uint64_t *, uint32_t,  uint64_t,  int,  int)' {aka 'int (*)(long unsigned int *, unsigned int,  long unsigned int,  int,  int)'} []
       >   186 |         .advise_stripe_size = advise_stripe_size_asym,
       >       |                               ^~~~~~~~~~~~~~~~~~~~~~~
       > volume.c:186:31: note: (near initialization for 'asym_vol_plug.advise_stripe_size')
       > make[3]: *** [Makefile:419: libvolume_static_la-volume.lo] Error 1
       > make[3]: Leaving directory '/build/reiser4progs-2.0.5/plugin/vol'
       > make[2]: *** [Makefile:613: all-recursive] Error 1
       > make[2]: Leaving directory '/build/reiser4progs-2.0.5/plugin'
       > make[1]: *** [Makefile:463: all-recursive] Error 1
       > make[1]: Leaving directory '/build/reiser4progs-2.0.5'
       > make: *** [Makefile:372: all] Error 2
       For full logs, run 'nix log /nix/store/8y7805npjq8h21khs1qhjkm3wd2y5hzp-reiser4progs-2.0.5.drv'.
error: 1 dependencies of derivation '/nix/store/5pyrc6y1ri4f92sf067qbkckdyipa64n-partitionmanager-23.08.5.drv' failed to build

Additional context

Metadata

Notify maintainers

@peterhoeg
@oxalica

---

Note for maintainers: Please tag this issue in your PR.

---

Add a 👍 reaction to issues you find important.

[oxalica]

IIRC, ReiserFS is deprecated for quite some time and is removed in the next Linux 6.13 release. The last release of reiser4progs is also 3 years ago.

Could we consider removing all relevant packages and disable these features from downstream programs? I'm not sure how many ReiserFS users are there though...

[spiage]

@oxalica I think it could be an option, disabled by default )
Or can be removed until someone asked...

[spiage]

@oxalica @peterhoeg
could it be useful?
00a8abb

[peterhoeg]

We should absolutely remove reiser4progs as a dependency for partition manager. The number of users of that combination is bound to be very small. I think we should otherwise leave in reiser4progs.

[oxalica]

could it be useful?
00a8abb

No. The error from reiser4progs is an real error (mismatched parameter order, resulting in mismatched type) rather than a false alarm. I don't really wanna fix it because it's unmaintained anyway.

I opened #368474