Bug 2223 - no update advisories in rpmdrake
Summary: no update advisories in rpmdrake
Alias: None
Product: Mageia
Classification: Unclassified
Component: Release (media or process) (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High major
Target Milestone: Mageia 6
Assignee: Sysadmin Team
QA Contact:
: 2823 (view as bug list)
Depends on:
Reported: 2011-07-21 11:46 CEST by AL13N
Modified: 2024-01-20 10:46 CET (History)
10 users (show)

See Also:
Source RPM:
Status comment: Work in progress.


Description AL13N 2011-07-21 11:46:37 CEST
Description of problem:
when try to install updates in rpmdrake, there are no icons indicating the reason for update & no advisory text
Samuel Verschelde 2011-07-21 11:52:49 CEST

CC: (none) => stormi

Manuel Hiebel 2011-08-02 01:41:32 CEST

Source RPM: (none) => rpmdrake

Comment 1 Thierry Vignaud 2011-08-09 16:11:11 CEST
This is because security team isn't filling core/updates/media_info/descriptions & the like

Component: RPM Packages => Release (media, process)
Source RPM: rpmdrake => (none)
Assignee: bugsquad => qa-bugs
CC: (none) => thierry.vignaud

Manuel Hiebel 2011-08-09 16:26:14 CEST

CC: (none) => security, sysadmin-bugs

Comment 2 Samuel Verschelde 2011-08-09 17:34:55 CEST
assigning to sysadmins, as the QA team can do nothing about it yet

Assignee: qa-bugs => sysadmin-bugs

Samuel Verschelde 2011-08-09 17:35:26 CEST

Priority: Normal => High

Comment 3 Nicolas Vigier 2011-08-09 21:09:27 CEST
The tools to generate this file still need to be developed.

CC: (none) => boklm

Comment 4 AL13N 2011-08-09 22:08:01 CEST
in the main time, is this something that can be filled in manually? by secteam or qateam for instance?
Comment 5 Thierry Vignaud 2011-08-10 07:38:33 CEST
I was under impression that was the case back @mdv...
Comment 6 Samuel Verschelde 2011-10-02 21:59:10 CEST
ping for this issue
Comment 7 Manuel Hiebel 2011-12-08 22:43:12 CET
Any news on this one ?

some users are afraid with the updates...

Source RPM: (none) => rpmdrake

Comment 8 AL13N 2011-12-08 23:17:40 CET
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...
Comment 9 Thierry Vignaud 2011-12-09 09:29:21 CET
Again this has nothing to do with rpmdrake but with people pushing updates without filling the descriptions file

Source RPM: rpmdrake => (none)

Comment 10 Manuel Hiebel 2011-12-09 12:39:11 CET
(In reply to comment #9)
> Again this has nothing to do with rpmdrake but with people pushing updates
> without filling the descriptions file

ok sorry
Comment 11 AL13N 2011-12-09 17:19:16 CET
(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?
Comment 12 Nicolas Vigier 2011-12-09 17:23:44 CET
(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.
Comment 13 AL13N 2011-12-09 19:37:31 CET
(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?
Comment 14 Nicolas Vigier 2011-12-12 14:00:20 CET
*** Bug 2823 has been marked as a duplicate of this bug. ***

CC: (none) => marcello.anni

Nicolas Vigier 2012-01-13 23:01:44 CET


Comment 15 Manuel Hiebel 2012-04-25 23:05:12 CEST
Any chance to fix this bug for mga 2 ? should we update the updates_policy ?
Comment 16 Marcello Anni 2012-04-29 14:18:06 CEST
hope so, with mageia 2 the project reaches a mature status, it would be a shame to not have this feature...
Comment 17 Nicolas Vigier 2012-04-29 14:45:10 CEST
Saying that it's a shame something is not yet done does not really help getting it done ...
Comment 18 AL13N 2012-04-29 23:41:56 CEST
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?
Comment 19 Manuel Hiebel 2012-11-05 16:52:25 CET
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
AL13N 2012-11-05 20:12:25 CET

Version: 1 => Cauldron

Nicolas Vigier 2014-03-24 10:47:04 CET

CC: boklm => (none)

Comment 20 Pascal Terjan 2015-02-11 22:59:06 CET
What we have in advisory files:

type: security
subject: Updated kernel packages fix security vulnerabilities
 - CVE-2042-1
     - kernel-42.42.42-1.mga42
description: |
  This kernel update is based on upstream -longterm 42.42.42 and
  fixes the following security issues:
 - 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'

CC: (none) => pterjan

Angelo Naselli 2015-03-13 09:31:29 CET

CC: (none) => anaselli

Comment 21 Angelo Naselli 2015-03-13 10:58:31 CET
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 
Could that file compiled automatically when mageia advisory is compiled by
some magical and automatic tool?
Comment 22 Pascal Terjan 2015-03-13 11:03:15 CET
Yes, my previous comment explains what the tool should do to map the information we have in advisories to what is expected to be in "descriptions" file :)
Comment 23 Angelo Naselli 2015-03-13 11:18:23 CET
another approach could be to improve http://gitweb.mageia.org/software/infrastructure/mgaadvisories/
to be not only a tool but a module to be used to extract advisory and used
in new rpm tool at that aim also. Don't know if it is possible though
Comment 24 Pascal Terjan 2015-03-13 11:26:03 CET
I had started adding the code into it (but didn't get very far).
Comment 25 Angelo Naselli 2015-03-13 12:10:35 CET
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:
- 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?
Comment 26 Thierry Vignaud 2015-03-13 12:40:00 CET
->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.
Comment 27 Thierry Vignaud 2015-03-13 12:43:53 CET
Ah you mean you want rpmdrake to lookup the SRPM...
Then we would need to put the whole generatea package in 'descriptions' list like in the old days
eg: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/MandrivaLinux/official/updates/2010.0/x86_64/media/media_info/descriptions
Comment 28 Thierry Vignaud 2015-03-13 12:44:15 CET
Did anyone asked Oden if it was somewhat automated in mdv days?
Comment 29 Angelo Naselli 2015-03-13 13:06:34 CET
Yes description is a possibility, when writing the advisory.
OTOH we could ask to advisory db directly since
we could improve the api here:
and use them into the rpm tool when a package is selected.
Comment 30 Pascal Terjan 2015-03-13 14:03:57 CET
I was intending to add code to mgaadvisories to generate descriptions file when moving packages, as it has all the information.
Comment 31 Angelo Naselli 2015-03-13 15:29:03 CET
on comment#28 yes Oden confirm it's automatic.
Comment 32 Pascal Terjan 2015-03-15 01:48:38 CET
I have something more or less working but have several problems (including not being able to test).

One strange thing is that the file lists packages without version so there is no way to know which ones apply to a specific update:

Comment 33 Pascal Terjan 2015-03-15 02:01:19 CET
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     :
Release     : 1.mga4
Group       : Development/Other
Size        : 0                            Architecture: x86_64
Source RPM  : git-     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).

- 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
Comment 34 AL13N 2015-03-15 10:55:14 CET
maybe we can extend the descriptions to allow for this, so that multiple fixes could be aggregated by the program reading it? (ie: urpmi, rpmdrake and manadrake)
Comment 35 Thierry Vignaud 2015-03-16 11:10:10 CET
urpmi doesn't use them, those desc were introduced for MgaUpdate, then urpmq started using them in:

Then code was then factored in urpm.pm for both rpmdrake & urpmq:

So it should be possible to keep package versions, then alter rpmdrake to look at all the update descriptions, keep the most urging category & display all update descriptions.

That's another subject & would be for mga6 though since here we're just restoring previous behavior

Also Pascal, previously we kept all updates in descriptions, not just latest one.
Comment 36 Pascal Terjan 2015-03-16 11:23:15 CET
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.
Comment 37 Angelo Naselli 2015-03-16 11:30:39 CET
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.
Comment 38 Pascal Terjan 2016-02-27 14:34:24 CET
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.
Comment 39 Samuel Verschelde 2016-10-10 17:18:28 CEST
Hi Pascal. Do you think you'll be able to do it before Mageia 6 and that I can thus add Mageia 6 as milestone?
Comment 40 Pascal Terjan 2016-10-10 17:36:56 CEST
I can try, I just need to find where is my half working code :)
Samuel Verschelde 2016-10-10 18:32:45 CEST

Target Milestone: --- => Mageia 6
Status comment: (none) => Work in progress.

Comment 41 Aurelien Oudelet 2020-09-19 18:08:48 CEST
This is High priority bug for a good reason.

Making Mageia even better than ever is best direction.
In order to do right thing, this bug should be examined and fixed as soon as possible.

Packagers, please make the status to Assigned when you are working on this.
Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it.

On October 1st 2020, we will drop priority to normal.
Comment 42 Morgan Leijström 2021-02-07 12:57:36 CET

CC: (none) => fri

Comment 43 Nicolas Lécureuil 2021-02-07 14:34:40 CET
we still not have the tool.

Thierry can you provide some informations ? 
we can fix this during mageia 8 lifetime. ( can or must :-) )

Pascal have you found your half working code ?

CC: (none) => mageia

Guillaume Bedot 2024-01-20 10:46:17 CET

CC: (none) => geex+mageia

Note You need to log in before you can comment on or make changes to this bug.