Description of problem(s): When configuring media, after clicking on one of the checkboxes, a requester pops up "This medium needs to be updated to be usable. Update it now?" If you choose "No", then the checkmark is not shown, but the entry was adapted in /etc/urpmi/urpmi.cfg. Regardless what you choose (No or Yes) the list view always scrolls to the top while the requester is displayed and to a different location when it disappears, which makes it very hard to select media. Version-Release number of selected component (if applicable): rpmdrake-6.20 How reproducible: Always Steps to Reproduce: 1. run drakrpm-editmedia or drakrpm-edit-media 2. scroll down the list 3. select an unselected Medium Reproducible: Steps to Reproduce:
I can't reproduce this on 32bit Mga5, neither with drakrpm-editmedia nor with drakrpm-editmedia --expert I don't get that popup, and enabling e.g. nonfree-updates-testing works fine. On ± 20 tests, enabling and disabling again, it occurred one time that the just enabled medium jumped to the top of the screen, the other 19 times it stayed where it was. All 20 tests, the checked checkbox was visibly checked, and the checkmark disappeared when unchecking. However, I'm not using online media, but a local mirror, for which the behaviour of this tool might differ. CC'ing maintainer. @ Herbert I do not know whether the invisible checkmark is the same bug, or a different one. For that reason I didn't add it to the summary. I suppose it becomes visible after restarting drakrpm-editmedia?
Keywords: (none) => NEEDINFOCC: (none) => marja11, thierry.vignaudSummary: Confusing drakrpm-editmedia (or drakrpm-edit-media) display => Confusing auto-scroll of drakrpm-editmedia after "This medium needs to be updated...." popup
ah, and you do indeed use online media?
Yes, you can probably get my media state by doing: urpmi.removemedia -a urpmi.addmedia --dist --mirrorlist http://mirrors.mageia.org/api/mageia.5.x86_64.list Best, Herbert
CC: (none) => herbert
(In reply to Marja van Waes from comment #1) > @ Herbert > > I do not know whether the invisible checkmark is the same bug, or a > different one. For that reason I didn't add it to the summary. > > I suppose it becomes visible after restarting drakrpm-editmedia? No, it doesn't, but it will get a comment on the commandline: unable to access synthesis file of "Core Backports Testing", medium ignored (selected "Core Backports Testing" and answered with "No") Best, Herbert
CC: (none) => anaselli
(In reply to Herbert Poetzl from comment #4) > (In reply to Marja van Waes from comment #1) > > @ Herbert > > > > I do not know whether the invisible checkmark is the same bug, or a > > different one. For that reason I didn't add it to the summary. > > > > I suppose it becomes visible after restarting drakrpm-editmedia? > > No, it doesn't, but it will get a comment on the commandline: > > unable to access synthesis file of "Core Backports Testing", medium ignored > > (selected "Core Backports Testing" and answered with "No") > Ah, I had overlooked that it only doesn't show when you answered "no". I think disabling a medium when there's no synthesis file found is desired behaviour. (Besides, Core Backports Testing for Mga 5 does not contain any packages at all, atm. media_info/synthesis.hdlist.cz exists, but is identical to the one in Cauldron)
Keywords: NEEDINFO => (none)
"Core Backports Testing" was just an example, pick any other you like, the only requirement is that it is "new" because if you already have the synthesis, the popup will not be shown. Best, Herbert
(In reply to Marja van Waes from comment #5) > I think disabling a medium when there's no synthesis file found is desired > behaviour. Not sure about that, the reason why I chose the "No" path in the first place was because I hoped to avoid the (for me rather long) download time after each media I enable (adding all the debug media for example), and have them all downloaded in one run either on close or when the tool is restarted - what a naive idea :) Best, Herbert
The problem is that once you answer yes it works well instead, because the source is upd2date. urpmi.cfg is updated removing ignore also we answer no, but if the media is not updated rpmdrake (but dragora-edit-media.pl as well) does not change the state. I wonder if urpmi.update -a updates also that media and if, after that rpmdrake view it as checked?
And the answe(In reply to Angelo Naselli from comment #8) > I wonder if urpmi.update -a updates also that media and if, after that > rpmdrake > view it as checked? The answer is clearly yes :)
Just remove the content into /var/lib/urpmi/Core\ Release\ Debug/ e.g. MD5SUM and synthesis.hdlist.cz allows to replicate the problem if the media was updated for any reasons.
A comment in the code says this: # reread media failed to un-ignore an ignored medium# probably because urpm::media::check_existing_medium() complains # about missing synthesis when the medium never was enabled before; # thus it restored the ignore bit I wonder if it's better to force the udpate without asking then... since a negative answer does not work either.... tv?
IMHO the best option would be to allow enabling/disabling media without downloading required synthesis lists and once the selection is complete and the user confirms the selection (OK button) then the downloading of new/required synthesis files starts. Best, Herbert
On comment #12, well as far as i can say rpmdrake code requires a huge (but not impossible) work for that. Since I'm for manatools where that dialog is a little bit different and you can enable just only one I won't fix it in that way. I will wait for a tv comment though, because if the bug is in urpm behavior i don't see why continue to get workarounds
@ Angelo @ Herbert Since I picked the wrong one of the issues Herbert reported for the summary: Could one of you please correct it to something better? (Please don't start discussing the auto-scrolling, that should go into a different report)
Well as far as i can say the problem is the first one, e.g. enabling a media that has no synthesis files and denying the media update means disabling it, even if urpmi.config is saved with the media enabled.
@Marja as far as I understood Helbert propose to "save" the list of the new enabled media and just after the final "Ok" downloading the synthesis files (e.g. update them all), he didn't talk about scrolling... a good approach imo, but not applicable in manatools, e.g. rpmdragora and dragora-edit-media.pl since there, a scrollable checkboxes are not present for enabling media.
(In reply to Angelo Naselli from comment #16) > he didn't talk about scrolling (In reply to Herbert Poetzl from comment #0) > > Regardless what you choose (No or Yes) the list view always scrolls to the > top while the requester is displayed and to a different location when it > disappears, which makes it very hard to select media. > He did talk about that, too, and I just picked the "wrong" issue for the summary. (In reply to Angelo Naselli from comment #15) > Well as far as i can say the problem is the first one, e.g. enabling a media > that > has no synthesis files and denying the media update means disabling it, even > if urpmi.config is saved with the media enabled. I'll try to make a better summary, feel free to correct
Summary: Confusing auto-scroll of drakrpm-editmedia after "This medium needs to be updated...." popup => Denying medium update disables a just enabled medium when there's no synthesis file, even if urpmi.cfg is saved with that medium enabled
(In reply to Herbert Poetzl from comment #7) > (In reply to Marja van Waes from comment #5) > > I think disabling a medium when there's no synthesis file found is desired > > behaviour. > > Not sure about that, the reason why I chose the "No" path in the first place > was because I hoped to avoid the (for me rather long) download time after > each media I enable (adding all the debug media for example), and have them > all downloaded in one run either on close or when the tool is restarted - > what a naive idea :) > Well, IINM, if you still choose "No" and then close drakrpm-editmedia and start urpmi.update -a All media that are enabled in urpmi.cfg will get updated in one go :-)
(In reply to Marja van Waes from comment #18) > > urpmi.update -a > > All media that are enabled in urpmi.cfg will get updated in one go :-) and there's "urpmi.update -f" to Force updating synthesis and "urpmi.update -ff" to Really force updating synthesis
(In reply to Marja van Waes from comment #18) > Well, IINM, if you still choose "No" and then close drakrpm-editmedia and > start > > urpmi.update -a > > All media that are enabled in urpmi.cfg will get updated in one go :-) Yes as I stated in Comment #9, that's why this is a bug because it is not really disabled, but it will be later at some points, by some tools (rpmdrake & co?), if no one updates media...
Assignee: bugsquad => mageiatools
@ Herbert Thank you for having taken the needed time to report this issue! @ Anaselli Thank you for having looked into it :-) Did this bug get fixed? If so, please change its status to RESOLVED - FIXED If it didn't, then we regret that we weren't able to fix it in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/ It only continued to get important security updates since then, because we are waiting for a big Plasma5 update in Mageia 6, that'll fix many of the Mageia 5 => 6 upgrade issues. If you haven't seen that this bug got fixed, then please check whether this bug still exists in Mageia 6. If it does, then please change the Version (near the top, at the left) to "6". If you know it exists in Cauldron, then change Version to Cauldron. If you see it in both Cauldron and Mageia 6, then please set Version to Cauldron and add MGA6TOO on the Whiteboard. Thanks, Marja
No reply, so closing as OLD
Resolution: (none) => OLDStatus: NEW => RESOLVED