The "drakrpm-update" program crashed. Drakbug-16.103 caught it. Hi! I saw in the very first column of drakrpm-update some icon I did not recognise (was there an icon already or did the icon change?) As no help popup appeared when I put my cursor on it, I tried right-click... seems like it was a bad idea: it crashed I hope my report will help some way undefined value for mandatory argument 'uri' encountered at /usr/lib/perl5/vendor_perl/5.20.1/Gtk3.pm line 901. Perl's trace: drakbug::bug_handler() called from /usr/lib/perl5/vendor_perl/5.20.1/Gtk3.pm:295 Gtk3::__ANON__() called from /usr/lib/libDrakX/mygtk3.pm:1521 mygtk3::main() called from /usr/lib/libDrakX/ugtk3.pm:859 ugtk3::main() called from /usr/libexec/drakrpm-update:282 main::run_treeview_dialog() called from /usr/libexec/drakrpm-update:293 Theme name: Adwaita Kernel version = 4.1.15-desktop-2.mga5 Distribution=Mageia release 5 (Official) for x86_64 CPU=Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
It has in fact nothing to do with my right-click: left click on a package to look at the description gives the same behaviour.
Severity: normal => major
This is likely due to the descriptions files. I removed them from the mirrors for now.
CC: (none) => pterjan
CC: (none) => thierry.vignaud
*** Bug 17833 has been marked as a duplicate of this bug. ***
CC: (none) => jm.sarat
CC: (none) => marja11Summary: drakrpm-update crashed => drakrpm-update crashed (undefined value for mandatory argument 'uri')
*** Bug 17835 has been marked as a duplicate of this bug. ***
CC: (none) => laidlaws
*** Bug 17840 has been marked as a duplicate of this bug. ***
CC: (none) => repacjp-magg
Summary: drakrpm-update crashed (undefined value for mandatory argument 'uri') => drakrpm-update crashed / drakrpm crashed (undefined value for mandatory argument 'uri')
*** Bug 17841 has been marked as a duplicate of this bug. ***
CC: (none) => bill
(In reply to Pascal Terjan from comment #2) > This is likely due to the descriptions files. I removed them from the > mirrors for now. So is the bug in those files, or should rpmdrake be able to handle them without crashing?
CC: (none) => anaselli
I unfortunately failed to debug this more as I couldn't find a way to start rpmdrake over ssh. I will probably upload a package like null to updates_testing and generate a fake advisory for it so that it does not impact users.
(In reply to Pascal Terjan from comment #8) > I unfortunately failed to debug this more as I couldn't find a way to start > rpmdrake over ssh. > I will probably upload a package like null to updates_testing and generate a > fake advisory for it so that it does not impact users. Thanks :-) I saw: commit 69d785fc6d7147c29ff261b7674d70b62fe9fd55 Author: Pascal Terjan <pterjan@gmail.com> Date: Mon Feb 29 17:01:04 2016 +0000 Add URL to descriptions But didn't see null land in updates_testing... is it too early for tests, or too late? ;-)
Too early :) I have a few other local changes I haven't pushed yet
*** Bug 17946 has been marked as a duplicate of this bug. ***
CC: (none) => monsteriname
*** Bug 17977 has been marked as a duplicate of this bug. ***
CC: (none) => khangyi
*** Bug 18052 has been marked as a duplicate of this bug. ***
CC: (none) => oboschini
I've been seeing this bug also. Based on a sample of one, disabling local (HD) repo, install of virtualbox now works. It was crashing by simply selecting virtualbox. HTH
CC: (none) => pf
The file has been removed from the mirrors a month ago, I don't know why this is still happening :( It may remain in the local cache...
I don't see what file you're referring to... can i get a clue? If said file is still in my local repo, I can remove it and retest...
The file is called "descriptions"
Hmmm.... turns out my local repo was not mounted (external drive)... Gotta go to work -- will dig into this more this evening... Could this file be cached?
*** Bug 18073 has been marked as a duplicate of this bug. ***
CC: (none) => lloyd.osten
*** Bug 18078 has been marked as a duplicate of this bug. ***
(In reply to Marja van Waes from comment #20) > *** Bug 18078 has been marked as a duplicate of this bug. *** From that report: (from Sam Khangyi's description): > > I do think this is package related, it crashes with some packages and it > doesn't with others consistently. > > Installed kdevelop4-php the older version, crashes with kdevelop4-php 1.7.3 > 1.mga5 x86_64 to pinpoint a crashing package for testing >
*** Bug 18152 has been marked as a duplicate of this bug. ***
CC: (none) => rolfpedersen
I experienced this bug on one machine but not on another, at the same time, both running Mageia release 5 (Official) for x86_64, while clicking on the same rpm in the list of updates, sourced from, afaict, the same mirror. So, I'm not seeing how the DESCRIPTIONS file would be the trigger, unless there is an intermittent condition or some other factor. On one machine, drakrpm-update crashed when I clicked on java-1.8.0-openjdk-1.8.0.77-1.b03.1.mga5.x86_64 in the list. Update succeeded when I didn't click on a package: [rolf@localhost ~]$ rpm -qa --last | grep java-1.8.0-openjdk-1.8.0.77-1.b03.1.mga5.x86_64 java-1.8.0-openjdk-1.8.0.77-1.b03.1.mga5.x86_64 Wed 06 Apr 2016 05:33:28 PM PDT [rolf@localhost ~]$ urpmq --sources java-1.8.0-openjdk-1.8.0.77-1.b03.1.mga5.x86_64 http://mirror.easthsia.com/mageia/distrib/5/x86_64/media/core/updates/java-1.8.0-openjdk-1.8.0.77-1.b03.1.mga5.x86_64.rpm [rolf@localhost ~]$ cat /etc/release Mageia release 5 (Official) for x86_64 On the machine where clicking on java-1.8.0-openjdk-1.8.0.77-1.b03.1.mga5.x86_64 and viewing the Changelog did not cause a crash, the rsync protocol is being used at mirror.easthsia.com but would that make a difference? [rolf@p8z68 ~]$ rpm -qa --last | grep java-1.8.0-openjdk-1.8.0.77-1.b03.1.mga5.x86_64 java-1.8.0-openjdk-1.8.0.77-1.b03.1.mga5.x86_64 Wed 06 Apr 2016 05:14:50 PM PDT [rolf@p8z68 ~]$ urpmq --sources java-1.8.0-openjdk-1.8.0.77-1.b03.1.mga5.x86_64 rsync://mirror.easthsia.com/mageia/distrib/5/x86_64/media/core/updates/java-1.8.0-openjdk-1.8.0.77-1.b03.1.mga5.x86_64.rpm [rolf@p8z68 ~]$ cat /etc/release Mageia release 5 (Official) for x86_64 If this seems relevant, I've written more information in my now-discredited https://bugs.mageia.org/show_bug.cgi?id=18152 ;p
*** Bug 18166 has been marked as a duplicate of this bug. ***
CC: (none) => bliss-SF4ever
*** Bug 18170 has been marked as a duplicate of this bug. ***
CC: (none) => Gchoyman
*** Bug 18179 has been marked as a duplicate of this bug. ***
*** Bug 18180 has been marked as a duplicate of this bug. ***
(In reply to Pascal Terjan from comment #15) > The file has been removed from the mirrors a month ago, I don't know why > this is still happening :( > It may remain in the local cache... Is there a way to remove it with a rpmdrake update? Assigning to rpmdrake maintainer, even if he didn't cause this.
Assignee: bugsquad => thierry.vignaud
I can't test it right now, because there are no updates. I rarely look at descriptions for updates.
*** Bug 18200 has been marked as a duplicate of this bug. ***
CC: (none) => paul
CC: repacjp-magg => (none)
(In reply to Pascal Terjan from comment #17) > The file is called "descriptions" Where should that file be, in /var/lib/rpm/ or somewhere else? Can anyone still affected by this bug now, please give the output of (as root): find / | grep -i descriptions
I encountered the bug once. Subsequently, I have clicked on packages in the updater and viewed the Changelog without triggering the crash, again. FWIW: [root@HP-Kodi rolf]# find / | grep -i descriptions /var/lib/urpmi/Core 32bit Updates/descriptions /var/lib/urpmi/Core Updates/descriptions /usr/share/doc/HTML/en/digikam/menu-descriptions.docbook
(In reply to Rolf Pedersen from comment #32) > /var/lib/urpmi/Core 32bit Updates/descriptions > /var/lib/urpmi/Core Updates/descriptions @ pterjan IIUC, he should not have those two files, correct?
as requested [root@localhost dash]# find / | grep -i descriptions /home/dash/Calibre Library/Fearing Burr/The Field and Garden Vegetables of America Containing Full Descriptions of Nearly Eleven Hundre (130) /home/dash/Calibre Library/Fearing Burr/The Field and Garden Vegetables of America Containing Full Descriptions of Nearly Eleven Hundre (130)/metadata.opf /home/dash/Calibre Library/Fearing Burr/The Field and Garden Vegetables of America Containing Full Descriptions of Nearly Eleven Hundre (130)/cover.jpg /home/dash/Calibre Library/Fearing Burr/The Field and Garden Vegetables of America Containing Full Descriptions of Nearly Eleven Hundre (130)/The Field and Garden Vegetables of America - Fearing Burr.azw find: â/run/user/1000/gvfsâ: Permission denied /usr/share/doc/HTML/en/digikam/menu-descriptions.docbook [root@localhost dash]# $ cd LibreOffice_*_Linux_x86-64_rpm/RPMS bash: $: command not found [root@localhost dash]# $ wget http://download.documentfoundation.org/libreoffice/stable/5.0.4/rpm/x86/LibreOffice_5.0.4_Linux_x86_rpm.tar.gz bash: $: command not found [root@localhost dash]# googleearth bash: googleearth: command not found [root@localhost dash]#
I am no longer seeing this bug. It must have moved to the vegetables! In reply to Comment 31, I can find no relevant files containing "descriptions." But I have reinstalled at least once, and I format /var each time. That may be what is different.
*** Bug 18213 has been marked as a duplicate of this bug. ***
CC: (none) => herakles
@ William Moses Please run (as root) find /var/lib/urpmi/ | grep descriptions and give us the output. Thanks :-)
(In reply to Marja van Waes from comment #37) > @ William Moses > > Please run (as root) > > find /var/lib/urpmi/ | grep descriptions > > and give us the output. > > Thanks :-) Here is what showed up: "[root@localhost bill948]# find /var/lib/urpmi/ | grep description /var/lib/urpmi/Core Updates (distrib3)/descriptions /var/lib/urpmi/Core 32bit Updates (distrib32)/descriptions" I worked around this issue with Thunderbird by installing the previous version then a day later running an update which updated my Thunderbird to the version, I had originally was trying to get.
(In reply to William Moses from comment #38) > > Here is what showed up: > > "[root@localhost bill948]# find /var/lib/urpmi/ | grep description > /var/lib/urpmi/Core Updates (distrib3)/descriptions > /var/lib/urpmi/Core 32bit Updates (distrib32)/descriptions" Those files should no longer be there. You can remove both with, as root: rm -v /var/lib/urpmi/Core*/descriptions > > I worked around this issue with Thunderbird by installing the previous > version then a day later running an update which updated my Thunderbird to > the version, I had originally was trying to get. I'm glad you managed :-)
We can probably put some empty ones to get those replaced but that needs to be tested
(In reply to Pascal Terjan from comment #40) > We can probably put some empty ones to get those replaced but that needs to > be tested I just added some empty description files in my cauldron: [root@cldrn_64 urpmi]# find | grep descriptions ./Nonfree 32bit Release (RedHD236)/descriptions ./Nonfree Release (RedHD211)/descriptions ./Core Release (RedHD21)/descriptions ./Core 32bit Release (RedHD231)/descriptions [root@cldrn_64 urpmi]# And then installed pidgin from Core Release. It installed (+dependencies/recommends) without problems
Thanks. I hope they don't get ignored on non update media, I think I'll first add them to updates_testing to be safe
(In reply to Pascal Terjan from comment #42) > Thanks. > I hope they don't get ignored on non update media, Thanks for thinking of that! > I think I'll first add > them to updates_testing to be safe Good :-)
*** Bug 18212 has been marked as a duplicate of this bug. ***
*** Bug 18313 has been marked as a duplicate of this bug. ***
CC: (none) => contact
Depends on: (none) => 18306
Depends on: 18306 => (none)
This file has been in updates_testing for a week, I guess we would have heard if people testing updates could no longer use rpmdrake, so I'll create it in updates too now
CC: (none) => doktor5000
(In reply to Pascal Terjan from comment #46) > This file has been in updates_testing for a week, I guess we would have > heard if people testing updates could no longer use rpmdrake, so I'll create > it in updates too now Thanks, Pascal :-) It's weeks later, now, and there were no more reports of users hitting this bug, closing.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
*** Bug 18846 has been marked as a duplicate of this bug. ***
CC: (none) => vibranium12
*** Bug 18967 has been marked as a duplicate of this bug. ***
CC: (none) => kmmos1
*** Bug 19071 has been marked as a duplicate of this bug. ***
CC: (none) => ktech_wa
Reopening, because there were 3 duplicates since this bug was closed. @ anyone still hitting this: Please run, as root, the following command in a konsole/terminal, and tell us what the output is: find /var/lib/urpmi/ | grep descriptions
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
I had an early duplicate of this from the bug catcher. Haven't had any problem for a while, but I usually install updates from mgaapplet. # find /var/lib/urpmi/ | grep descriptions /var/lib/urpmi/Core Updates/descriptions /var/lib/urpmi/Core Updates (distrib3)/descriptions /var/lib/urpmi/Core 32bit Updates/descriptions /var/lib/urpmi/Core 32bit Updates (distrib32)/descriptions
The file /var/lib/urpmi/Core Updates/descriptions seems to have a newline and nothing else, "file" returns: /var/lib/urpmi/Core Updates/descriptions: very short file (no magic)
*** Bug 19081 has been marked as a duplicate of this bug. ***
CC: (none) => cdillahay
@ Doug Thx for the feedback. I've been mixing things up: removing the original description files locally fixed the problem for me, but removing them from the mirrors did not remove them on local systems. So, other than I remembered pterjan replaced them with empty files, which works, too. Maybe the problem is with some users (and mirrors?) still having the not-empty description files? I just checked on my local mirror, and /mageia/distrib/5/i586/media/core/updates/media_info/descriptions /mageia/distrib/5/x86_64/media/core/updates/media_info/descriptions /mageia/distrib/5/i586/media/core/updates_testing/media_info/descriptions /mageia/distrib/5/x86_64/media/core/updates_testing/media_info/descriptions are all empty, as they should be. However, there are mirrors that still have original description files, like this one when I write this ftp://mirrors-usa.go-parts.com/mageia/distrib/5/x86_64/media/core/updates/media_info/descriptions (They seem to be currently trying to sync their mirror again, btw: the time stamp of their Mageia mirror changed for the first time since many months ago!) So, if someone still hits this: please check whether one of your description files still contains text.
*** Bug 19142 has been marked as a duplicate of this bug. ***
(In reply to Marja van Waes from comment #55) > @ Doug > > Thx for the feedback. I've been mixing things up: removing the original > description files locally fixed the problem for me, but removing them from > the mirrors did not remove them on local systems. > > (They seem to be currently trying to sync their mirror again, btw: the time > stamp of their Mageia mirror changed for the first time since many months > ago!) > > So, if someone still hits this: please check whether one of your description > files still contains text. After a reinstall, I now have only 2 description files left. Both contain nothing more than a newline. I have no problem with that.
9-21-16 Could someone please email me instructions as to what I need to do to fix this rmpdrak error. I am in Mageia 6 sta 1. dlocklear01@gmail.com I went to the terminal and used a urmpi command that I found somewhere, but it did not help.
CC: (none) => dlocklear01
(In reply to David Locklear from comment #58) > 9-21-16 > > > Could someone please email me instructions as to what I need to do to fix > this rmpdrak error. I am in Mageia 6 sta 1. > <snip> > > I went to the terminal and used a urmpi command that I found somewhere, but > it > did not help. Did you get a crash and see this message: undefined value for mandatory argument 'uri' encountered at /usr/lib/perl5/vendor_perl/5.20.1/Gtk3.pm ? If so, then run, in a terminal/konsole as root: LC_ALL=C rm /var/lib/urpmi/*/descriptions You'll be asked several times for confirmation. Press the Y key to continue. However, if you're not sure you got the 'uri' error, then you may just have hit bug 19406.
s/this message/such a message/ ;-)
*** Bug 18586 has been marked as a duplicate of this bug. ***
CC: (none) => sebateo78
I haven't seen it for a while. I thought it was fixed!
(In reply to Rémi Verschelde from comment #61) > *** Bug 18586 has been marked as a duplicate of this bug. *** (In reply to Doug Laidlaw from comment #62) > I haven't seen it for a while. I thought it was fixed! It is fixed. Bug 18586 was filed on 2016-05-30 13:10:12 CEST The really last filed bug report that was closed as duplicate of this one, was bug 19142, filed at 2016-08-07 07:59 CEST Closing
Status: REOPENED => RESOLVEDResolution: (none) => FIXED