Re: dnf install just stops - no explanation
From: Tonet Jallo tonet6...@gmail.com In Peru i have the same problem, my ISP is implememtating NAT 3 in its networks and i found more dnf hangs in some networks with NAT 3, but when i try use dnf in other ISP network dnf works perfectly, the degmbug results say some thing like banned client by web server but i not remember exactly. On Tue, Jun 9, 2015 at 9:41 AM, Richard Fearn richardfe...@gmail.com wrote: I've experienced the same problem with a F22 VM running in VirtualBox. (Is yours a VM?) Disabling IPv6 seemed to help a bit, but the problem never went away completely. There a few bugs that talk about similar issues, e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=1206878 https://bugzilla.redhat.com/show_bug.cgi?id=1214538 There are various ideas out there for how to fix this, e.g. `dnf clean all`, or using LIBREPO_DEBUG=1. But none of these worked definitively for my VM. Regards, Richard Hi, these bugs should be fixed in dnf-1.0.1-2.fc22 (in testing now). Can anyone of you confirm? From: Zdenek Kabelac zkabe...@redhat.com count me in - https://bugzilla.redhat.com/show_bug.cgi?id=1223803 Zdenek Zdenek, this stops during transaction - different bug. I am assuming this is packaging problem. Probably scriplet of some package is executing rpm inside and lead to deadlock. Can you see any of these scriplets in the last installed package in the transaction? Thanks, Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
DNF 1.0.1 Released
The new release brings fixes of the most occurred errors in Fedora 22. Moreover adds SSL support in repository configuration and random sleep dnf-automatic feature. Read more in 1.0.1 release notes [1] on DNF documentation page, try it from testing and give it a karma. [1] http://dnf.readthedocs.org/en/latest/release_notes.html#id44 [*] http://dnf.baseurl.org/2015/06/12/dnf-1-0-1-released/ Honza by DNF team -- 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
From: Kevin Fenzi ke...@scrye.com There's some confusion around this, so I thought I would post to try and clear up things. In the event I am wrong on any of the below, please do feel free to correct me. ;) In the past the proposal was to have a yum-dnf package that provided /usr/bin/yum, called dnf and conflicted with the yum package. I was against that plan, but I think the one we settled on is worth doing. It's somewhat of a middle ground between yum is gone right now, deal with it and you can keep using yum forever. For f22 (and rawhide): * dnf is installed by default. By that I mean it is in the 'core' group in comps. * dnf-yum is installed by default. By that I mean it is in the 'core' group in comps next to dnf. * yum is installed if something that depends on yum pulls it in or say a user installs it manually. * yum requires dnf-yum. So, if you install yum manually you will also pull in dnf-yum (and the dnf plugin that handles history migrate). * When you run 'yum' you get: % sudo yum list foobar Yum command has been deprecated, use dnf instead. See 'man dnf' and 'man yum2dnf' for more information. To transfer transaction metadata from yum to DNF, run 'dnf migrate' Redirecting to '/usr/bin/dnf list foobar' ...then the ouput from dnf list foobar... * If you wish to still use yum, the yum package provides now a /usr/bin/yum-deprecated command that is the old yum command renamed. It also has the notice message as above on it. * If you are using the yum python bindings directly, that will continue to work if you have the yum package installed. Note that this landed before Beta freeze, but there were some issues with the initial package doing this. There is an update available: https://admin.fedoraproject.org/updates/yum-3.4.3-505.fc22 I think this helps those users who read any of the docs out there that say to 'yum install foo' at the cost of those people who need some specific command line behavior from yum. The second group is much better positioned to use yum-deprecated or know whats going on than the first group. Exactly, thanks for writing this, Kevin. All man pages / warnings were updated according to these changes so there should be no harm / confusion during yum to DNF transition. BTW new migration plugin [1] was created to import transactions, installed packages and group metadata from yum to DNF. [1] http://dnf-plugins-extras.readthedocs.org/en/latest/migrate.html DNF team -- 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 search as braindead as yum search
On Sun, 22 Mar 2015 21:10:05 +0100, Michael Schwendt wrote: # dnf search libtoolize Using metadata from Sat Mar 21 15:38:26 2015 = Matched: libtoolize == libedit.x86_64 : The NetBSD Editline library libedit.i686 : The NetBSD Editline library D'oh! It's a false positive, because the word libtoolized is found in the package description of libedit. The package libtool is not found, because dnf search doesn't search filelists by default. A highly questionable decision. Yum manual page claims that yum search only searches package names and summaries. However, the word libtoolize only appears in the package _description_ of libedit, _not_ in its package name or %summary. Manual page claims that yum search all … should search in description and URL. Something's wrong here. DNF man: ...By default the command will only look at package names and summaries, failing that (or whenever all was given as an argument) it will match against package descriptions and URLs... yum man: ...By default search will try searching just package names and summaries, but if that fails it will then try descriptions and url... I get the same result from dnf search and yum search. It wasn't found in package name nor summary so it's searched in description. Further differences: # dnf whatprovides libtoolize Using metadata from Sun Mar 22 23:13:16 2015 Error: No Matches found Compare with: # yum whatprovides libtoolize libtool-2.4.2-32.fc22.x86_64 : The GNU Portable Library Tool Repo: fedora Matched from: Filename: /usr/bin/libtoolize DNF doesn't match substrings by default in (what)provides command. You have to use '*': e.g. `dnf whatprovides *libtoolize` [1]. Although DNF doesn't show what file it matched from the package. We already have this reported in BZ [2]. Btw fedora devel list doesn't serve for reporting DNF bugs. Next time see the yum x dnf differences page [3] and eventually file it here [4], please, so we have it tracked ;). Thanks. [1] http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#dnf-provides-complies-with-the-yum-documentation-of-the-command [2] https://bugzilla.redhat.com/show_bug.cgi?id=1192811 [3] http://dnf.readthedocs.org/en/latest/cli_vs_yum.html [4] https://bugzilla.redhat.com/enter_bug.cgi?product=Fedoracomponent=dnf Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
DNF 0.6.4 and DNF-PLUGINS-CORE 0.1.5 Released
Hi, new version of DNF and DNF-PLUGINS-CORE is available for F21 and F22. The update fixes over 25 bugs, exposes more API and enhances plugin options. Read more in release notes [1] and [2]. [1] http://dnf.readthedocs.org/en/latest/release_notes.html#id41 [2] http://dnf-plugins-core.readthedocs.org/en/latest/release_notes.html#release-notes Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
DNF 0.6.3 Released
Hey, I am announcing release of DNF 0.6.3. In more detail here [1]. Try it out! [1] http://dnf.baseurl.org/2014/12/09/dnf-0-6-3-and-dnf-plugins-core-0-1-4-released/ -- 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: Status of weak dependencies support in Fedora 21+
On 10. 11. 2014 at 10:31:55, Kevin Fenzi wrote: On Mon, 10 Nov 2014 10:34:16 +0100 Jan Zelený jzel...@redhat.com wrote: Dnf should already have full support of this feature, at least that is the plan. Some people already tested it and so far it seems it works as expected. The semantics is described here: http://rpm.org/wiki/PackagerDocs/Dependencies Well, if things are fully implemented then... 1. If there's a weak dep (reccomends or supplants) that generates a solving error, dnf drops that weak dep and goes on with no error? (I guess this case would be two packages recommending things that conflict or one recommending something and another package with a supplants for a different package) Weak deps has been supported in libsolv for long time but nobody tried this scenarios in dnf. AFAIK it will ends with error now - no packages installed. 2. For 'very weak' deps (suggests, enhances) does dnf show the matching packages as option to the user ? It doesn't show it but it could. 3. The page says The depsolver may offer to treat the weak like very weak relations or the other way round does dnf do that? or not? DNF doesn't do that and never will. IMO that would be too hackish behavior. Perhaps some folks would like to step up to help out with this? Make a wiki page or document of various cases people might use it, make a test copr with those cases? Draft a FPC guideline for using them? That would be really appreciated. All those can be done simultaneously with the progressing adoption. I'm convinced we should use the test run in F21 to actually know what we need to regulate/control. Writing guidelines without any prior experience with the technology in Fedora is highly unlikely to do any good (remember SCLs?). I would be glad if the packagers/users come with undefined scenarios and file BZ on DNF with: * [weak deps] summary prefix * post link to custom COPR, so we can reproduce it easily * write expected result then RPM team decides how DNF should act, change it accordingly and document this case. FYI I have added to DNF github wiki page [1] how to report different kinds of bugs. [1] https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting#weak-dependencies Cheers, Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
DNF 0.6.2 Released
Hi all, DNF 0.6.2 is released. See: http://dnf.baseurl.org/2014/10/05/dnf-0-6-2-released/ Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
DNF 0.6.1 Released
Hi, DNF 0.6.1 is out. For more info of this version see: http://dnf.baseurl.org/2014/08/28/dnf-0-6-1-released/ Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
