can someone just generate a file on svn that gets put on mirrors and link it to rpmdrake?
perhaps a script that runs in a cronjob on primary mirror that fetches a certain file from svn? something quick & dirty? to just get us going?
maybe something like "svn co svn://.../descriptions" (several times) in a every 5 minute cronjob?
then we can put that in the policy that update maintainer can fill that advisory in that file on svn... and worry about the rest later...

(In reply to comment #9)
> Again this has nothing to do with rpmdrake but with people pushing updates
> without filling the descriptions file
so where do we fill in this info? boklm said the tools didn't exist yet?
rpmdrake is where we see the problem.
iiuc rpmdrake looks for the descriptions file on mirrors?
i did some updates but there is nothing about how to make descriptions for updates?
can anyone tell us what exactly we need to do?

(In reply to comment #11)
> iiuc rpmdrake looks for the descriptions file on mirrors?
>
> i did some updates but there is nothing about how to make descriptions for
> updates?
>
> can anyone tell us what exactly we need to do?
Just look at rpmdrake source code, or descriptions file on mandriva mirrors.

(In reply to comment #12)
> (In reply to comment #11)
> > iiuc rpmdrake looks for the descriptions file on mirrors?
> >
> > i did some updates but there is nothing about how to make descriptions for
> > updates?
> >
> > can anyone tell us what exactly we need to do?
>
> Just look at rpmdrake source code, or descriptions file on mandriva mirrors.
i meant, what file do we need to adjust? i don't think we have direct access to primary mirror?

so, afaik, we need to change in the updates policy:
- for people who push the update, (is that sysadmin?)
- after they push the update and sending email,
- change the descriptions file (where? is there an svn location that gets propagated to the primary mirror for this?)
does anyone have any objections for me to put this in the updates policy?

This message is a reminder that Mageia 1 is nearing its end of life.
In approximately 25 days from now, Mageia will stop maintaining and issuing
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it
remains open with a Mageia 'version' of '1'.
Package Maintainer: If you wish for this bug to remain open because you plan to
fix it in a currently maintained version, simply change the 'version' to a later
Mageia version prior to Mageia 1's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not
be able to fix it before Mageia 1 is end of life. If you would still like to see
this bug fixed and are able to reproduce it against a later version of Mageia,
you are encouraged to click on "Version" and change it against that version
of Mageia.
Although we aim to fix as many bugs as possible during every release's lifetime,
sometimes those efforts are overtaken by events. Often a more recent Mageia
release includes newer upstream software that fixes bugs or makes them obsolete.
--
Mageia Bugsquad

What we have in advisory files:
type: security
subject: Updated kernel packages fix security vulnerabilities
CVE:
- CVE-2042-1
src:
42:
core:
- kernel-42.42.42-1.mga42
description: |
This kernel update is based on upstream -longterm 42.42.42 and
fixes the following security issues:
[...]
references:
- https://bugs.mageia.org/show_bug.cgi?id=424242
- https://www.kernel.org/pub/linux/kernel/v42.x/ChangeLog-42.42.42
ID: MGASA-2042-0002
What rpmdrake wants for each package:
{importance} which is 'bugfix', 'security' or 'normal'
{pre} which is the reason for the update
optionaly {description} which is the rpm description, but it's only a fallback if we don't have it from the package
So it shouldn't be too hard to generate the file, putting 'type' into 'importance' and 'description' + maybe 'references' into 'pre'

hmm Pascal, according to get_updates_description in urpm module iiuc it should be
called descriptions.
and here http://advisories.mageia.org/ we have almost all the relevant
information.
Could that file compiled automatically when mageia advisory is compiled by
some magical and automatic tool?

well listadv seems very near to the scope, if the db had package version also
we could get that info by calling something like
MGA::Advisories::listadv(source_pkg, version) and get the advisory
removing the print of course ;)
Note that in the advisory (qt for instance) it seems we add
info such as srpms and version:
SRPMS:
- 4/core/qt3-3.3.8b-33.3.mga4
- 4/core/qt4-4.8.6-1.2.mga4
- 4/core/qtbase5-5.2.0-2.4.mga4
So it should be easy to make them available by a query i believe.
But i found also another problem by following that way
because when we look for advisory we know the binary package name and URPM::Package seems not to say which is the source name of it:
DB<22> l
327==> push @$s, get_advisory_link($update_descr) if $is_update;
[...]
DB<23> x $name
0 'lib64qtcore4'
DB<24> x $pkg->{pkg}
0 URPM::Package=SCALAR(0xe56be20)
-> 240571936
DB<25> x $pkg->{pkg}->sourcerpm
empty array
^^^^^^^^^^^ Why empty array?
DB<26> x $pkg->{pkg}->version
0 '4.8.6'
DB<27> x $pkg->{pkg}->release
0 '1.2.mga4'
have i missed anything?
and could be this way a possible solution?

->sourcerpm() only works if the URPM object has a RPM header attached.
It hasn't if it cames from parsing synthesis b/c there's no header in synthesis (that's the difference with huge hdlists) and not that info, ...
It has one if it comes from parsing hdlist, a rpm file, a spec file or when traversing rpmdb.
ie when calling one of parse_hdlist() parse_rpm(), spec2srcheader(), traverse*() or also update_header() & stream2header()
Where's the code you're talking about?
We may just get the media path then the package path and they create a new URPM object and query it.

Reading urpm::get_updates_description, it will overwrite when reading the file so just use the latest one for each package.
(I guess you will not see that there was a security update before if it is followed by a bugfix, but I have failed to use rpmdrake for the last hour so have no idea how the UI look like anyway).
urpmq --auto-select -i seems happy with my file:
Name : git-core-oldies
Version : 1.8.5.6
Release : 1.mga4
Group : Development/Other
Size : 0 Architecture: x86_64
Source RPM : git-1.8.5.6-1.mga4.src.rpm Build Host: ecosse.mageia.org
Packager : luigiwalser <luigiwalser>
URL : http://git-scm.com/
Summary : Git obsolete commands, bound to extinction
Description :
Git obsolete commands, bound to extinction
Update importance : security
Reason for update :
It was reported that git, when used as a client on a case-insensitive
filesystem, could allow the overwrite of the .git/config file when the client
performed a "git pull". Because git permitted committing .Git/config (or any
case variation), on the pull this would replace the user's .git/config. If
this malicious config file contained defined external commands (such as for
invoking and editor or an external diff utility) it could allow for the
execution of arbitrary code with the privileges of the user running the git
client (CVE-2014-9390).
References:
- https://bugs.mageia.org/show_bug.cgi?id=14849
- http://article.gmane.org/gmane.linux.kernel/1853266
- https://bugzilla.redhat.com/show_bug.cgi?id=1175960

They are all in descriptions, but the code reading it will only keep the latest as it's a hash keyed on the name and the value get overwritten each time we see another update with same package name.
I agree it's not the right time to change how things work, I'll just finish generating the file like it used to be.

Agree as well.
If Pascal has fixed this restoring most of the old behavior, i would release it though. We can then open a new bug to develop at the best this functionality for mga6 and maybe move all the relative bugs that could follow the release to the new one.

I looked at the code again, main problem is to find which media need their descriptions updated as the advisory only lists distrib/media/src.rpm but not architecture.
I guess I'll just do it for all architectures by using a glob.