#6276 rawhide buildsys unable to find /sbin/csh
Closed: Fixed None Opened 4 years ago by corsepiu.

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?

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.

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

The dnf guy's advise is harmful and short-sighted.

I don't believe it is, the move of contents of /bin -> /usr/bin happened a number of years ago.

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 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

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.

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

The dnf guy's advise is harmful and short-sighted.

I don't believe it is, the move of contents of /bin -> /usr/bin happened a number of years ago.

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 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

pulls in tcsh for me. 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

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.

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:

{{{

mock -r fedora-rawhide-i386 --install /bin/csh

..
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 -r fedora-rawhide-i386 --install /bin/csh

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]:

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.

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.

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

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.

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.

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]:

Opinions about dnf are irrelevant in this technical issue bug.

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.

Metadata