This is a short version of what currently is done when pushing updates using mgaadv to a stable release (updates_testing to updates). There is another page with more details on How to create an update advisory for use by the QA team.
I here use two terminal windows, one as myself on my local machine and one as root @ duvel. If you haven't already initialized mgaadv on your local machine, do so first.
Contents
Install mgaadv on your local machine
This is a one-time installation of the advisories tool on your local machine. SVN updates must be performed under your own username, not under the shared mga-advisories user on the server:
[root@laptop ~]# urpmi mga-advisories - installs mgaadv
Perform the initial config:
[tmb@laptop ~]$ mkdir ~/.mga-advisories [tmb@laptop ~]$ mgaadv initqaconf - initializes config file (it opens your text editor to let you edit it) - initial download of advisories into ~/mageia-advisories/advisories/
Update advisories repo
Check that you have latest advisories:
[tmb@laptop ~]$ cd ~/mageia-advisories/advisories [tmb@laptop advisories]$ svn up
Check if there is potential problems (for perl advisory parser). This recreates ~/mageia-advisories/html/:
[tmb@laptop advisories]$ mgaadv mksite
If you get any perl warnings/errors here, fix them or the advisory mails wont get pushed and website wont be updated. You only need to do this once at the beginning of your session as adding an ID to an advisory will not break it any further, so provided no-one else introduces an error while you're working, it should be fine!
Usually the error is indentation issues or some special chars. For example indentation issues will show:
YAML Error: Invalid element in map Code: YAML_LOAD_ERR_BAD_MAP_ELEMENT Line: 13 Document: 1 at /usr/lib/perl5/vendor_perl/5.18.1/YAML/Loader.pm line 352.
Assign a new advisory ID
Check at end of https://madb.mageia.org/tools/updates for advisories ready to be pushed.
Pushing updates (using samba update (bug 12999) as an example)
Assign advisory id (note: sometimes there can be split advisories in which case you would use mgaadv publish 12999.mga3 and mgaadv publish 12999.mga4). This performs some checks then updates the advisory file in svn (that the QA team created) with the next available MGASA- or MGAA- number:
[tmb@laptop advisories]$ mgaadv publish 12999 Found Bug: samba new security issue CVE-2013-4496 Checking for QA validation keyword… ✔ Checking dependent bugs… ✔ (None found) Assigning ID to advisory 12999… ✔ MGASA-2014-0138 Do you want to publish now? [Y/n]: ✔ Publishing advisory MGASA-2014-0138… ✔
If an update has a dependent bug that is still open, this function will warn you and ask if you would like to continue anyway. If you will be pushing that dependent update in the same batch as this one, you may normally select that option and publish anyway (but check the comments in both bugs to make sure there isn't some kind of special procedure needed). If not, then abort and don't publish this update at this time. This warning will appear even if you have already published the dependent bug because the bug status is not changed until the update is pushed (which happens in the next step).
This procedure is called "publishing" but it actually doesn't publish anything. That is done as part of the following step.
Push the update
On duvel, use screen or tmux to make avoid breakages during package move (in case you lose the network connection):
[root@duvel ~]# screen
Trigger package move, advisory mail, updating of https://advisories.mageia.org/ and closing of bugs on all advisories that were marked in the previous step:
[root@duvel ~]$ update_mga-advisories Re-running as 'mga-advisories' user. ...
There will be a whole bunch of debug output and both a sysadmin-report and a qa-report mail will be sent afterwards. The whole procedure can take over 15 minutes for a single advisory. Finally, fix the file permissions on files and directories that were touched:
find /distrib/{bootstrap,mirror}/ -user root \! -type l -exec chown schedbot:schedbot {} +
And you are done and can exit all screen and terminal windows on duvel.
Backports
The above procedure is for normal updates to a stable release. Updates to backports do not have an advisory and therefore do not need such an involved process. Instead, follow this process:
- There must be a bug open for the backport. Ensure that QA has tested and approved of the package by ensuring the validated_backport exists in the bug keywords.
- Run a command of this form on duvel:
mga-move-pkg --sync --backport 9/core/foobar-0.1-1.mga10.src.rpm
find /distrib/{bootstrap,mirror}/ -user root \! -type l -exec chown schedbot:schedbot {} +
- 3. Add a comment to the bug manually to confirm that the package has been moved. Assign the bug to qa-bugs@ml.mageia.org. The QA team will then draft an announcement that they will post to backports-announce.
NOTE: This process was developed in 2024 to ensure that users can stay abreast of backports changes. It may change in the future if mga-move-pkg is updated to automatically mail notifications to backports-announce by itself.
Errors
If a problem occurs during the mga-move-pkg stage, then the program may abort without performing all its steps (including package move, update bug, send e-mail, etc.). If the problem was temporary, try just running the command again. If there is still an issue (you may need to read the e-mail sent to qa-reports@ml to see details) then you may need to manually update the advisory status files to continue.
For example, if an error occurred during the package move stage, then the package(s) may have been moved but the status might not have been updated to reflect that. Subsequent invocations will then try to move a package that no longer exists in the updates_testing media where it's expected, causing an error every time. In this case, you will need to edit the appropriate file in /var/lib/mga-advisories/status/ to add a move line to indicate that the move has, indeed, taken place.
