NethServer YUM repositories permissions and management

Continuing the discussion from NS7 as new default target for nethserver-mock:

The current layout of YUM repositories for each NethServer version is

  • base
  • updates
  • testing
  • nethforge
  • nethforge-testing

Since was born everyone can upload RPMs to testing and nethforge-testing repositories, provided I receive the developer’s public ssh/rsa key.

Upload access to other repositories is restricted to a few people from the @dev_team. Actually, only me and @giacomo use to upload RPMs on those repositories.

The newly released nethserver-mock package contains the helper script, upload-rpms that sends RPM files to, using sftp and ssh/rsa keys.


what are the folders I can upload and please explain what are the differences between them

how push rpm from nethforge-testing to nethforge ?

therefore once my rpm are tested in nethforge-testing, I do send the same rpms to nethforge, or I have the possibility to do a cp to another folder ?

Moreover, nobody stated on srpm ?

This was the original question

You should already have the rights to upload directly to nethforge. So the first step is


You should upload the rpms to nethforge. I guess after the testing stage the developer should tag and re-build the RPM, as stated here

BTW, I’m adapting that page for NS7+GitHub

Then the upload command for the second step should be


The make-rpms command produces also .src.rpm files.

You should upload also SRPMs, but there is no strict requirement on this. The server side dispatch each RPM type/arch in the right slot (hopefully…).

What is required and checked automatically are the RPM dependencies. If they’re not satisfied the RPM is not added to the repository.


I just removed urbbackup packages from nethserver-testing, packages are correctly available from nethforge-testing (thanks Stephane).

No nethforge-testing on my repository

Not sure it is normal ?

so If I understand well

a) I build test rpm that I push to nethforge-testing
b) once they are ready/verified, I push them to nethforge a second time…like a new rpm

my concern is that it can introduce issues…once verified, a rpm just need to move by a cp, not by another rpm pushed to a new folder.


Yes, testing repos are not served by mirrors (these could be not synchronized) to ease the quality team job.

I understand your concerns. Anyway we build RPMs on pristine code from a git repository. Our builds are reproducible, no way for dirty checkouts!

The release-tag command alters only the .spec file, namely %changelog and %version tags.

This semi-automated process is running with its enhancements since 2012 and I never found any problem with it!

1 Like

Sure but I don’t use it, did I never say it :slight_smile:

Trust @davidep man, it knows a bit about NethServer :slight_smile:

be no longer in doubt but have belief

It is not concerning Nethserver, but the way how to build the rpm

For what I recall, (I tried a LONG time ago) the rpm/srpm are built in the git folder and I don’t like it.

The first ‘git add .’ and you add the rpms to the git history

It’s possible to ignore whatever artifact the build produces with a global gitignore file

Thank for sharing the tip :slight_smile: