Learn more about these different git repos.
Other Git URLs
rawhide's dnf enabled buildsystem seems unable to find /bin/csh, rsp. to process " {{{ BuildRequires: /bin/csh }}} " correctly.
cf. [https://koji.fedoraproject.org/koji/taskinfo?taskID=11414044]
from: [https://kojipkgs.fedoraproject.org//work/tasks/4089/11414089/root.log ] {{{ ... DEBUG util.py:393: Using metadata from Mon Oct 12 11:54:56 2015 (0:01:58 hours old) DEBUG util.py:393: No matching package to install: '/bin/csh' DEBUG util.py:393: Error: Not all dependencies satisfied ... }}} Note: "package /bin/csh"!
Using a yum-enabled local mock for rawhide, this package builds fine.
This is expected from dnf:
http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#id15
You will need to change your BuildRequires to /usr/bin/csh or convince dnf maintainers to reverse their stance.
Replying to [comment:1 kevin]:
This is expected from dnf: http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#id15 You will need to change your BuildRequires to /usr/bin/csh or convince dnf maintainers to reverse their stance.
Bummer - Incredible.
These BRs exist because scripts are executed via #!/bin/csh shebangs. Also, even in rawhide /bin/csh is an explict Provides from the tcsh-package => dnf must provide /bin/csh.
The dnf guy's advise is harmful and short-sighted.
Unfortunately, the trac doesn't seem to allow me reopen bugs (I can't find this to be respectful), otherwise I would have reopened this (IMO, prematurely closed) bug.
This is odd... (to me). On my f23 box at least, all of these work as expected to pull in tcsh:
1. $ dnf install /bin/csh
2. and a foo.spec that has BuildRequires: /bin/csh
$dnf builddep foo.spec
3. $ dnf builddep foo-1-1.src.rpm
pulls in tcsh for me. Do the koji builder's version of dnf work differently for some reason?
Wel the usrmove feature went in in F-17, the packages have long packaged /usr/bin/csdh and /bin is just a link to /usr/bin
I don't believe it is, the move of contents of /bin -> /usr/bin happened a number of years ago.
This isn't a rel-eng/koji migration issue so a rel-eng ticket isn't the place to discuss this, there are better forums to do so
Possibly, builders are still running F-21, with the dnf from updates-testing
Replying to [comment:5 pbrobinson]:
pulls in tcsh for me. It must - Otherwise dnf would be entirely FUBARed and unusable. Do the koji builder's version of dnf work differently for some reason? Possibly, builders are still running F-21, with the dnf from updates-testing Somebody recently (last week?) reported a similar issue one of the fedora lists. Unfortunately, I can't find it, ATM.
pulls in tcsh for me. It must - Otherwise dnf would be entirely FUBARed and unusable. Do the koji builder's version of dnf work differently for some reason?
pulls in tcsh for me. It must - Otherwise dnf would be entirely FUBARed and unusable.
Do the koji builder's version of dnf work differently for some reason?
Possibly, builders are still running F-21, with the dnf from updates-testing Somebody recently (last week?) reported a similar issue one of the fedora lists. Unfortunately, I can't find it, ATM.
The only other issue that I'm aware of, https://fedorahosted.org/rel-eng/ticket/6273 , was fixed
Sorry, I thought it was expected... but it seems they did fix/change it sometime along the way (but didn't modify their FAQ).
It's likely something with the f21 dnf.
FWIW: I can reproduce this dnf-bug on FC21:
{{{
.. INFO: enabled dnf cache Start: cleaning dnf metadata Finish: cleaning dnf metadata INFO: enabled ccache Mock Version: 1.2.13 INFO: Mock Version: 1.2.13 Finish: chroot init INFO: installing package(s): /bin/csh Using metadata from Mon Oct 12 19:08:01 2015 (0:00:01 hours old) }}}
No package /bin/csh available. Error: no package matched: /bin/csh
On FC22 (w/ dnf enabled mock) this bug does not appear: {{{
mock Version: 1.2.13 INFO: Mock Version: 1.2.13 Finish: chroot init INFO: installing package(s): /bin/csh Last metadata expiration check performed 0:00:00 ago on Mon Oct 12 19:09:28 2015. Package tcsh-6.19.00-3.fc23.i686 is already installed, skipping. ... }}}
=> FC21's dnf is broken.
Bug filed against fc21's dnf: [https://bugzilla.redhat.com/show_bug.cgi?id=1271053]
Yes, mock -r fedora-rawhide-i386 --install /bin/sh also is affected => likely it's a general bug somewhere in dnf.
Also, thanks to this bug, I am facing the unpleasant situation of being able to build a package for fc23, but not for rawhide, and not being able to push it to fc23, because this would break the upgrade path.
Any progress on this? This defect of the build system still seems to be present and I haven't noticed any glimpse of an attempt to fix it.
What shall I think of this?
Replying to [comment:11 corsepiu]:
We're in the process of moving builders to F-23, buildvm 01 - 09 are already running F-23, I believe it should be fixed in the version of dnf shipped in F-23.
Replying to [comment:12 pbrobinson]:
We're in the process of moving builders to F-23, buildvm 01 - 09 are already running F-23, OK, provided what you wrote, I gave the package exposing this issue a retry:
I am now seeing what I would call random results and build-lottery: - Successful scratch-build: https://koji.fedoraproject.org/koji/taskinfo?taskID=11811493 - Failed real build: https://koji.fedoraproject.org/koji/taskinfo?taskID=11811923 - Successful real build: https://koji.fedoraproject.org/koji/taskinfo?taskID=11811984
I believe it should be fixed in the version of dnf shipped in F-23. Possibly, dnf on f23 isn't as crappy as in f21 (totally unusable, with the dnf-devs violently refusing to fix bugs), but provided my experiences with dnf, my opinion and expectations on dnf are lower than ever. I regret having to say so, but dnf development communicates an experience, RH and Fedora should fell concerned about.
If you look at the builder hostnames the two successes are on the 1-9 range, and the failure is buildvm-27 so is consistent with the above.
Opinions about dnf are irrelevant in this technical issue bug.
https://lists.fedoraproject.org/pipermail/devel/2015-November/216795.html
All builders that could be used for your build are now on F-23 so I believe the problem is now resolved.
Replying to [comment:14 pbrobinson]:
How about you contacting the dnf-devs managers/supervisors/managers and you to complain about them, because they broke Fedora's infrastructure?
RH needs to comprehend that the low quality of works some parts of RH perform and confront the Fedora with, is a shame for RH.
@FESCO: Instead of being concernd about the name for "rawhide", these are the real issues, which are driving away contributors.
Login to comment on this ticket.