Add metadata to packages #190

Manually merged
abonerib merged 3 commits from add-meta into master 2025-10-10 16:39:05 +02:00
Collaborator

Add meta field with license and other information to our packages.

Add meta field with license and other information to our packages.
abonerib added 9 commits 2025-10-07 16:44:14 +02:00
Even if we do an override to papi get the proper configure flags for
cross-compiling, the memory fences are not defined for risc-v:

mb.h:67:2: error: #error Need to define rmb for this architecture!
Fix nanos6 cross-compilation for riscv
All checks were successful
CI / build:all (pull_request) Successful in 16s
c5563ab111
Add missing pre/postInstall hooks to intel 2023
Some checks failed
CI / build:all (pull_request) Failing after 15s
80b42c302e
abonerib force-pushed add-meta from 80b42c302e to 4555293442 2025-10-07 17:13:10 +02:00 Compare
abonerib force-pushed add-meta from 4555293442 to ed0cda5eda 2025-10-07 17:17:16 +02:00 Compare
abonerib force-pushed add-meta from ed0cda5eda to 66df874b4a 2025-10-08 14:59:10 +02:00 Compare
abonerib changed title from Add meta to packages and create nix-support/private file for unfree packages + fixes for risc-v cross compile to Add meta to packages and create nix-support/private file for unfree packages 2025-10-08 14:59:33 +02:00
abonerib changed title from Add meta to packages and create nix-support/private file for unfree packages to WIP: Add meta to packages and create nix-support/private file for unfree packages 2025-10-08 14:59:39 +02:00
abonerib force-pushed add-meta from 66df874b4a to 2c15bfd5b9 2025-10-09 17:08:02 +02:00 Compare
abonerib changed title from WIP: Add meta to packages and create nix-support/private file for unfree packages to Add metadata to packages 2025-10-09 17:09:44 +02:00
abonerib force-pushed add-meta from 2c15bfd5b9 to da3d76213c 2025-10-09 17:12:32 +02:00 Compare
abonerib force-pushed add-meta from da3d76213c to ec1da8f88f 2025-10-09 17:33:06 +02:00 Compare
rarias reviewed 2025-10-09 17:38:33 +02:00
rarias left a comment
Owner

Maybe it would be good to write somewhere what exactly means to be put as the maintainer of a package, because they have different levels of "maintenance status". Some are broken or commented in the overlay.

Maybe it would be good to write somewhere what exactly means to be put as the maintainer of a package, because they have different levels of "maintenance status". Some are broken or commented in the overlay.
flake.nix Outdated
@ -49,2 +49,3 @@
# propagate nixpkgs lib, so we can do bscpkgs.lib
inherit (nixpkgs) lib;
lib = nixpkgs.lib // {
bsc.maintainers = import ./maintainers/maintainer-list.nix;
Owner

I would move this to pkgs/maintainers.nix so that m completes to m/ and it doesn't litter the root dir.

I would move this to pkgs/maintainers.nix so that m<tab> completes to m/ and it doesn't litter the root dir.
abonerib marked this conversation as resolved
overlay.nix Outdated
@ -123,1 +123,4 @@
in bscPkgs // {
lib = prev.lib // {
bsc.maintainers = import ./maintainers/maintainer-list.nix;
Owner

Same here, also indentation is missing one space.

Same here, also indentation is missing one space.
abonerib marked this conversation as resolved
@ -114,0 +115,4 @@
meta = with lib; {
homepage = "https://github.com/bsc-performance-tools/extrae";
description = "Instrumentation framework to generate execution traces of the most used parallel runtimes";
maintainers = with maintainers.bsc; [ rarias ];
Owner

I think we can leave this one unmaintained, and maybe set the broken=true flag.

I think we can leave this one unmaintained, and maybe set the broken=true flag.
abonerib marked this conversation as resolved
@ -104,0 +105,4 @@
meta = with lib; {
homepage = "https://www.intel.com/content/www/us/en/developer/tools/overview.html";
description = "Intel compiler";
Owner

This one is only Intel MPI

This one is only Intel MPI
abonerib marked this conversation as resolved
@ -89,0 +93,4 @@
description = "nix bubblewrap wrapper";
maintainers = with lib.maintainers.bsc; [ rarias ];
platforms = lib.platforms.linux;
license = lib.licenses.gpl3Plus; # TODO: license?
Owner

You can use MIT as it was the original license we had in bscpkgs. Also this is likely unmaintaned + broken.

You can use MIT as it was the original license we had in bscpkgs. Also this is likely unmaintaned + broken.
abonerib marked this conversation as resolved
@ -18,0 +22,4 @@
description = "nix bubblewrap wrapper";
maintainers = with lib.maintainers.bsc; [ rarias ];
platforms = lib.platforms.linux;
license = lib.licenses.gpl3Plus; # TODO: license?
Owner

I didn't put one, can it be left unset?

I didn't put one, can it be left unset?
Author
Collaborator

Sure, but we will later have to decide the default behavior for unset licenses if we do the nix-support/private for the cache.

Sure, but we will later have to decide the default behavior for unset licenses if we do the nix-support/private for the cache.
Owner

For this one is okay as rebuilding it is fast. I think I can use MIT but I need to check how I wrote that. We probably want to avoid distributing packages without a license or with a non-redistributable license. Maybe a meta.redistributable = false attribute is easier, as unfree doesn't necessary mean non-redistributable.

For this one is okay as rebuilding it is fast. I think I can use MIT but I need to check how I wrote that. We probably want to avoid distributing packages without a license or with a non-redistributable license. Maybe a `meta.redistributable = false` attribute is easier, as unfree doesn't necessary mean non-redistributable.
Author
Collaborator

I'll leave it empty for now.

licenses are attribute sets with {unfree, redistributable::Bool, ...} we can either check for unfree or redistributable later on.

I'll leave it empty for now. licenses are attribute sets with `{unfree, redistributable::Bool, ...}` we can either check for unfree or redistributable later on.
abonerib marked this conversation as resolved
@ -62,0 +63,4 @@
meta = {
homepage = "https://gitlab.bsc.es/nos-v/nos-v";
description = "Tasking library enables the co-execution of multiple applications with system-wide scheduling and a centralized management of resources";
maintainers = with lib.maintainers.bsc; [ abonerib ];
Owner

I would need to review changes in nosv as well as it affects ovni, so you may add me as well as maintainer.

I would need to review changes in nosv as well as it affects ovni, so you may add me as well as maintainer.
abonerib marked this conversation as resolved
abonerib force-pushed add-meta from ec1da8f88f to 5dfa211f08 2025-10-09 18:10:25 +02:00 Compare
abonerib force-pushed add-meta from 5dfa211f08 to 4b4e6e9327 2025-10-09 18:15:39 +02:00 Compare
abonerib force-pushed add-meta from 4b4e6e9327 to ed8d6d1ec7 2025-10-09 18:19:14 +02:00 Compare
abonerib force-pushed add-meta from ed8d6d1ec7 to 5d861077b4 2025-10-10 12:23:59 +02:00 Compare
abonerib force-pushed add-meta from 5d861077b4 to dd7744358f 2025-10-10 12:30:13 +02:00 Compare
Author
Collaborator

Maybe it would be good to write somewhere what exactly means to be put as the maintainer of a package, because they have different levels of "maintenance status". Some are broken or commented in the overlay.

I think we can do something similar to what is done with nixpkgs maintainers:

The main responsibility of a maintainer is to keep the packages they maintain in a functioning state, and keep up with updates. In order to do that, they are empowered to make decisions over the packages they maintain.

That being said, the maintainer is not alone in proposing changes to the packages. Anybody (both bots and humans) can send PRs to bump or tweak the package.

Mainly, a maintainer should be expected to keep up with the updates of the package and should be pinged in Gitea when someone proposes a change in the package so they can test it.

Additionally, if we decide to use hydra, maintainers could opt-in to get notified of build failures for their packages.

> Maybe it would be good to write somewhere what exactly means to be put as the maintainer of a package, because they have different levels of "maintenance status". Some are broken or commented in the overlay. I think we can do something similar to what is done with [nixpkgs maintainers](https://github.com/NixOS/nixpkgs/tree/master/maintainers#readme): > The main responsibility of a maintainer is to keep the packages they maintain in a functioning state, and keep up with updates. In order to do that, they are empowered to make decisions over the packages they maintain. > > That being said, the maintainer is not alone in proposing changes to the packages. Anybody (both bots and humans) can send PRs to bump or tweak the package. Mainly, a maintainer should be expected to keep up with the updates of the package and should be pinged in Gitea when someone proposes a change in the package so they can test it. Additionally, if we decide to use hydra, maintainers could opt-in to get notified of build failures for their packages.
abonerib force-pushed add-meta from dd7744358f to e9754aa8d7 2025-10-10 12:47:30 +02:00 Compare
Owner

I think we can do something similar to what is done with nixpkgs maintainers:

The main responsibility of a maintainer is to keep the packages they maintain in a functioning state, and keep up with updates. In order to do that, they are empowered to make decisions over the packages they maintain.

That being said, the maintainer is not alone in proposing changes to the packages. Anybody (both bots and humans) can send PRs to bump or tweak the package.

Mainly, a maintainer should be expected to keep up with the updates of the package and should be pinged in Gitea when someone proposes a change in the package so they can test it.

That seems reasonable, is mostly what we currently do already. It might be good to write this in a similar doc/maintainers.md doc file linking to that nixpkgs section.

Additionally, if we decide to use hydra, maintainers could opt-in to get notified of build failures for their packages.

I'm okay maintaining the last release of OmpSs-2 packages, as that only happens twice a year. But I don't think I would be ok making them for each commit that lands on master of each project. I would accept patches though.

> I think we can do something similar to what is done with [nixpkgs maintainers](https://github.com/NixOS/nixpkgs/tree/master/maintainers#readme): > > > The main responsibility of a maintainer is to keep the packages they maintain in a functioning state, and keep up with updates. In order to do that, they are empowered to make decisions over the packages they maintain. > > > > That being said, the maintainer is not alone in proposing changes to the packages. Anybody (both bots and humans) can send PRs to bump or tweak the package. > > Mainly, a maintainer should be expected to keep up with the updates of the package and should be pinged in Gitea when someone proposes a change in the package so they can test it. That seems reasonable, is mostly what we currently do already. It might be good to write this in a similar `doc/maintainers.md` doc file linking to that nixpkgs section. > Additionally, if we decide to use hydra, maintainers could opt-in to get notified of build failures for their packages. I'm okay maintaining the last release of OmpSs-2 packages, as that only happens twice a year. But I don't think I would be ok making them for each commit that lands on master of each project. I would accept patches though.
abonerib added 1 commit 2025-10-10 15:47:21 +02:00
Add brief documentation on maintainer roles
All checks were successful
CI / build:cross (pull_request) Successful in 6s
CI / build:all (pull_request) Successful in 15s
f8ab42813d
Author
Collaborator

That seems reasonable, is mostly what we currently do already. It might be good to write this in a similar doc/maintainers.md doc file linking to that nixpkgs section.

Additionally, if we decide to use hydra, maintainers could opt-in to get notified of build failures for their packages.

I'm okay maintaining the last release of OmpSs-2 packages, as that only happens twice a year. But I don't think I would be ok making them for each commit that lands on master of each project. I would accept patches though.

I have added documentation addressing these points, hopefully it's clear enough.

> That seems reasonable, is mostly what we currently do already. It might be good to write this in a similar `doc/maintainers.md` doc file linking to that nixpkgs section. > > > > Additionally, if we decide to use hydra, maintainers could opt-in to get notified of build failures for their packages. > > I'm okay maintaining the last release of OmpSs-2 packages, as that only happens twice a year. But I don't think I would be ok making them for each commit that lands on master of each project. I would accept patches though. I have added documentation addressing these points, hopefully it's clear enough.
rarias approved these changes 2025-10-10 16:12:26 +02:00
rarias left a comment
Owner

Thanks, looks great!

Thanks, looks great!
rarias force-pushed add-meta from f8ab42813d to 4685c36e2f 2025-10-10 16:37:33 +02:00 Compare
abonerib manually merged commit 4685c36e2f into master 2025-10-10 16:39:05 +02:00
Sign in to join this conversation.
No Reviewers
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rarias/jungle#190
No description provided.