Re: dnf update args and wiki update
On 09/27/2016 12:54 AM, Catalin wrote: Dear team. About dnf -help under I used fc25 . I don't see the update argument output of command: dnf --help. The dnf args is in progress ? This will be fixed in DNF-2.0 release. Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
On 09/08/2016 01:48 PM, Dominik 'Rathann' Mierzejewski wrote: On Thursday, 08 September 2016 at 13:37, Michal Luscon wrote: On 09/08/2016 01:05 PM, Peter Robinson wrote: [...] Given it's the updates system there, at least IMO, needs to be full contingency plans etc. Sorry, the history of the dnf team not breaking stuff even on small bumps gives me little faith this will be smooth. The internal DNF testing stack undergone radical improvements during the last year. Core DNF functionality is now covered by functional tests. Therefore, we expect only minor issues with adoption of 2.0. Those are famous last word, you know. ;) It's better to have a solid contingency plan and never use it than not have it and be forced to scramble in the unlikely case something goes wrong because you "expected only minor issues". Regards, Dominik Yes, we are on the same page here. Michal -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
On 09/08/2016 01:05 PM, Peter Robinson wrote: Sounds like this scope would warrant a Change? The components should be already prepared for DNF-2 and the changes are not huge. There's the FESCO ticket [5]. If it is not accepted then we will submit a Change. Actually, the preferred approach would be for this to come to FESCo *as* a Change. Mostly because the Change Process requires you to explain the situation fully and establish a contingency plan. Completely agree, we (rel-eng and I'm sure others) don't want to find out one day everything is broken due to this change and the compose is up the spout. Core components such as dnf need to follow the process properly and communicate far and wide so people are aware of the changes in flight that could affect everything from builds to users updating. FESCo requested that a System Wide Change should be submitted for this. Regards, Dominik Ok, we will file a System Wide Change then. Yet it's not filed here [1] as a system wide change. Why? The change proposal is in WIP state. Given it's the updates system there, at least IMO, needs to be full contingency plans etc. Sorry, the history of the dnf team not breaking stuff even on small bumps gives me little faith this will be smooth. The internal DNF testing stack undergone radical improvements during the last year. Core DNF functionality is now covered by functional tests. Therefore, we expect only minor issues with adoption of 2.0. Michal -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
On 09/05/2016 03:52 PM, Dominik 'Rathann' Mierzejewski wrote: On Friday, 02 September 2016 at 19:32, Peter Robinson wrote: [...] Sounds like this scope would warrant a Change? The components should be already prepared for DNF-2 and the changes are not huge. There's the FESCO ticket [5]. If it is not accepted then we will submit a Change. Actually, the preferred approach would be for this to come to FESCo *as* a Change. Mostly because the Change Process requires you to explain the situation fully and establish a contingency plan. Completely agree, we (rel-eng and I'm sure others) don't want to find out one day everything is broken due to this change and the compose is up the spout. Core components such as dnf need to follow the process properly and communicate far and wide so people are aware of the changes in flight that could affect everything from builds to users updating. FESCo requested that a System Wide Change should be submitted for this. Regards, Dominik Ok, we will file a System Wide Change then. Thank you. Michal -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF Issue, packages being incorrectly removed - was: Re: corebird
Below is the output of dnf autoremove from my system. Am I correctly interpreting this that dnf thinks that all these packages can be removed? If that is the case, I would think we have a serious issue. Even if this issue has been identified and corrected going forward, there is a big mess to clean up. Are we assuming that when systems upgrade to F24 this will be resolved? If so, I can accept that, but we really need to put out some kind of explicit and obvious warning to F23 customers if this is the case. If the issue is that people aren't correctly expressing dependencies in their spec files, then something should be done about that. NetworkManager-adsl x86_64 1:1.0.12-2.fc23 @updates-testing 31 k NetworkManager-bluetooth x86_64 1:1.0.12-2.fc23 @updates-testing 93 k NetworkManager-config-connectivity-fedora x86_64 1:1.0.12-2.fc23 @updates-testing 88 NetworkManager-openswan x86_64 1.0.8-3.fc23 @updates-testing 278 k NetworkManager-wwan x86_64 1:1.0.12-2.fc23 @updates-testing 103 k adobe-source-han-sans-tw-fontsnoarch 1.004-2.fc23 @updates-testing 38 M bluedevil x86_64 5.6.4-1.fc23 @updates-testing 1.8 M breeze-gtkx86_64 5.6.4-1.fc23 @updates-testing 2.0 M dnf-plugin-system-upgrade noarch 0.7.1-1.fc23 @updates-testing 87 k dpkg x86_64 1.17.25-6.fc23@@commandline 6.1 M dpkg-perl noarch 1.17.25-6.fc23@@commandline 564 k execstack x86_64 0.5.0-9.fc23 @@commandline 227 k js-jquery noarch 2.1.3-2.fc23 @@commandline 478 k kde-gtk-configx86_64 5.6.4-1.fc23 @updates-testing 719 k kdeplasma-addons x86_64 5.6.4-1.fc23 @updates-testing 7.8 M kf5-bluez-qt x86_64 5.22.0-1.fc23 @updates-testing 744 k kf5-kross-corex86_64 5.22.0-1.fc23 @updates-testing 1.0 M kf5-kross-ui x86_64 5.22.0-1.fc23 @updates-testing 783 k kf5-kwindowsystem-devel x86_64 5.22.0-1.fc23 @updates-testing 208 k khelpcenter x86_64 1:5.6.2-1.fc23@kde-unstable 3.3 M kinfocenter x86_64 5.6.4-1.fc23 @updates-testing 7.3 M kscreen x86_64 1:5.6.4-1.fc23@updates-testing 803 k ksshaskpass x86_64 5.6.4-1.fc23 @updates-testing 98 k ksysguard x86_64 5.6.4-1.fc23 @updates-testing 2.5 M ksysguarddx86_64 5.6.4-1.fc23 @updates-testing 156 k kwalletmanagerx86_64 15.04.3-3.fc23@updates-testing 903 k kwayland-integration x86_64 5.6.4-1.fc23 @updates-testing 111 k liberation-fonts noarch 1:1.07.4-6.fc23 @@commandline 0 liberation-narrow-fonts noarch 1:1.07.4-6.fc23 @@commandline 476 k libgudev-develx86_64 230-2.fc23 @@commandline 282 k libreswan x86_64 3.17-2.fc23 @updates-testing 3.6 M live555-libs x86_64 2016.03.14-2.fc23 @fedora-HandBrake 1.2 M lttng-ust x86_64 2.6.2-2.fc23 @@commandline 809 k lxqt-config x86_64 0.10.0-5.fc23 @kde-unstable 1.1 M nodejs-couch-loginnoarch 0.1.18-3.fc23 @@commandline 20 k p7zip x86_64 15.14.1-1.fc23@updates-testing 1.9 M pam-kwallet x86_64 5.6.4-1.fc23 @updates-testing 40 k perl-IO-Tty x86_64 1.12-3.fc23 @@commandline 79 k perl-IPC-Run noarch 0.94-3.fc23 @@commandline 317 k perl-encoding x86_64 3:2.17-4.fc23 @updates-testing 128 k perl-open
Re: dnf remove qemu-img uninstall kernel
On 02/15/2016 08:53 AM, Jan Zelený wrote: On 12. 2. 2016 at 18:42:50, Sérgio Basto wrote: On Sex, 2016-02-12 at 19:36 +0100, Mattia Verga wrote: Il 12/02/2016 19:22, Sérgio Basto ha scritto: On Sex, 2016-02-12 at 19:18 +0100, Mattia Verga wrote: I've installed qemu to play with arm virtualization, now I want to uninstall it, but it seems that trying to uninstall anything qemu related also removes all installed kernels Is this a DNF bug? no this is : clean_requirements_on_remove=true in /etc/dnf/dnf.conf Thanks, setting it to "false" avoid kernel uninstalling. But if it's not a bug, I can hardly see the reason to have a "feature" that removes the kernel... dnf should not autoremove mandatory system components. But that's my opinion, there's probably an important reason for which I'm wrong. This behavior might not be caused by a bug in dnf. There has recently been a bug in PackageKit which you might be hitting. Most likely #1259865 is causing this issue. -- Michal -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf output to STDOUT/STDERR
Would you mind filling a proper bugzilla report on bugzilla.redhat.com? Regards, Michal Luscon On 08/31/2015 08:16 AM, Joachim Backes wrote: Some dnf messages are not relevant me, so I redirect STDERR to /dev/null if using dnf. But this has the disadvantage the the prompt "Is this ok [y/N]:" gets lost too. Obviously it is written to STDERR. So my proposal for dnf: write the prompt "Is this ok [y/N]:" to STDOUT and not to STDERR. Kind regards Joachim Backes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rawhide users beware! (Re: DNF 1.1.0 and DNF-PLUGINS-CORE 0.1.10 Released)
This has been already resolved by dnf-1.1.0-2. On 08/12/2015 02:28 PM, Michael Schwendt wrote: On Tue, 11 Aug 2015 15:43:15 -0400 (EDT), Honza Šilhan wrote: Hi. Another crucial release of DNF is out with a lot of new features and over 20 bug fixes. # dnf update Last metadata expiration check performed 2:18:33 ago on Wed Aug 12 12:09:11 2015. Dependencies resolved. Traceback (most recent call last): File /bin/dnf, line 35, in module main.user_main(sys.argv[1:], exit_code=True) File /usr/lib/python3.4/site-packages/dnf/cli/main.py, line 193, in user_main errcode = main(args) File /usr/lib/python3.4/site-packages/dnf/cli/main.py, line 84, in main return _main(base, args) File /usr/lib/python3.4/site-packages/dnf/cli/main.py, line 146, in _main ret = resolving(cli, base) File /usr/lib/python3.4/site-packages/dnf/cli/main.py, line 168, in resolving base.do_transaction(display=displays) File /usr/lib/python3.4/site-packages/dnf/cli/cli.py, line 165, in do_transaction pkg_str = self.output.list_transaction(trans) File /usr/lib/python3.4/site-packages/dnf/cli/output.py, line 1024, in list_transaction for pkg in self._skipped_broken_deps(skipped_conflicts): File /usr/lib/python3.4/site-packages/dnf/cli/output.py, line 947, in _skipped_broken_deps goal_diff -= skipped_conflicts TypeError: unsupported operand type(s) for -=: 'set' and 'map' -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
On 04/09/2015 05:01 PM, Przemek Klosowski wrote: Using metadata from Fri Apr 3 03:24:08 2015 ^^^ the key part of DNF output -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf debug-info-install
On 04/07/2015 02:38 PM, Michael Catanzaro wrote: On Tue, 2015-04-07 at 12:25 +, Tim Lauridsen wrote: debug-info-install is in dnf-plugins-core Ah, OK. So two problems: * The yum2dnf man page says the command is 'debug-info-install' but it is 'debuginfo-install'. gdb gets the name right; no change needed there. * The man page says the command is in 'dnf-plugins-extras' but it really is in 'dnf-plugins-core'. I have just corrected the package name for plugin, but don't see any debug-info-install in yum2dnf man page. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
