Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1161913
Summary: | Yumex does not save 'clean unused requirements is active by default' in preferences | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Minus Zero <minuszero> |
Component: | yumex | Assignee: | Tim Lauridsen <tla> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 21 | CC: | alex.go4more, bugzilla, lnie, micsim2007, projects.rg, tla |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | yumex-3.0.17-1.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-04-26 12:44:44 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Minus Zero
2014-11-09 09:55:44 UTC
I can reproduce this issue, I will look into it I can reproduce too. build 3.0.16-1.fc21 i686 on MATE-Compiz spin. Reproducible for Fedora 21. yumex-3.0.16-1.fc21.noarch What is the yumex.conf entry for 'cleanup unused requirements is active by default'? Is it remove_requirements? If so it is being ignored. I was just wondering if there was another entry missing. My yumex.conf currently shows the following. [yumex] autorefresh = 1 recentdays = 14 proxy = exclude = debug = 0 color_install = darkgreen color_update = red color_normal = black color_obsolete = blue plugins = 1 yumdebuglevel = 2 win_height = 753 win_width = 1126 remove_requirements = 1 This is a broken feature. Setting Severity to high. I can reproduce this too. Until this is fixed, users will simply have to click options>"clean unused requirements" when uninstalling packages. I have same problem. Here is my yumex.conf: [yumex] autorefresh = 1 recentdays = 14 proxy = exclude = debug = 0 color_install = darkgreen color_update = red color_normal = black color_obsolete = blue plugins = 1 yumdebuglevel = 2 win_height = 740 win_width = 1210 win_sep = 379 typeahead_search = 0 use_sortable_view = 1 use_sudo = 1 check_for_updates = 1 remove_requirements = 1 remove_requirements = 1 remove_requirements = 1 remove_requirements = 1 Interesting that, even if you have already 1 entry set to 1, each time you set it to true again, a new entry will be created at the end of the file. But, it does not get "sticky" under settings (in the same session)... Seems as this item does not get parsed/recognized at startup. Output log (German): <...> 19:49:29 : INFO - Using config file : /home/XYZ/.config/yumex/yumex.conf 20:01:09 : DEBUG - Netzwerkschnittstelle wlp4s0b1 (brcmsmac) ist verbunden 20:01:09 : INFO - Yum-Option skip_broken wird auf False gesetzt 20:01:10 : INFO - Yum-Option clean_requirements_on_remove wird auf False gesetzt 20:01:10 : INFO - 13 Pakete zurückgegeben 20:01:10 : INFO - 0 Pakete zurückgegeben 20:01:12 : INFO - YUM: --> Transaktionsprüfung wird ausgeführt <...> The latest (testing) version of Yum Extender from the yumex-dnf COPR repository does not have this issue. However, this is not a solution to this problem since several features are still yet to be implemented. More information is available at yumex.dk fixed upstream https://github.com/timlau/yumex/commit/48027f5ffb4ef66a4d483eac25811b164aec9f24 Very weird case, look like iniparse don't like option there starts with remove so i renamed the option to clean_requirments in yumex.conf and it work like a charm. Thanks Tim! I'll try and hopefully leave some positive karma it as soon as it hits the updates-testing for F21 and F22. Glad you managed to find the cause anyhow. yumex-3.0.17-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/yumex-3.0.17-1.fc22 yumex-3.0.17-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/yumex-3.0.17-1.fc21 yumex-3.0.17-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/yumex-3.0.17-1.el7 Package yumex-3.0.17-1.el7: * should fix your issue, * was pushed to the Fedora EPEL 7 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing yumex-3.0.17-1.el7' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5908/yumex-3.0.17-1.el7 then log in and leave karma (feedback). yumex-3.0.17-1.fc22 works yumex-3.0.17-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. yumex-3.0.17-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. yumex-3.0.17-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |