Spec URL: http://ojuba.org/test/mkchroot.spec SRPM URL: http://ojuba.org/test/mkchroot-0.0.1-1.oj35.noarch.rpm Description: Fedora Chroot Directory Maker Fedora Account System Username: moceap
*** Bug 1241382 has been marked as a duplicate of this bug. ***
Hello, It is informal review due to I am not Fedora packages maintainer. Few comments: License: - License is in PDF format instead of text format (waqf2-ar.pdf) - License WAQFv2 is provided in an Arabic language. - I have no idea about this license WAQF2. Could you tell if this license is pointed on following link: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses - In LICENSE file is text "Licened under WAQFv2 or GPLv3". When your script is provided on WAQFv2 and when on GPLv3? - In file LICENSE in text "Licened under WAQFv2 or GPLv3" the word "Licened" should be "Licensed". - SRPM: - You attached link to RPM, not SRPM. Script: - Yum command has been deprecated. You can try to use dnf. - mkchroot requires root account, so the script should be placed in /usr/sbin, not /usr/bin - script does not provide any interface (at least like: usage:, --help, --version ...etc.). - script requres to run (or look inside script) for know how it works and what it do. - this command: "yum -y --nogpg ..." can be dangerous because it skips checking GPG signatures. - in case validation error always is returned exitcode 0 instead of exitcode > 0
Changed when I process another bug :)
Why --nogpgcheck?
@Zbigniew Is it question to Mosaab or to me?
To Mosaab.
Where is it ?
@Mosaab It is in rpm in /usr/bin/mkchroot:47: yum -y --nogpg --installroot="$directory" --disablerepo=* --enablerepo=fcdm install yum
Mmmmmmmmmmm I thought in SPEC. Using --nogpg due to errors in GPG checks when building chrootdir for another Fedora version.
I don't think this makes sense to make this into a package. We are moving to dnf, so new dependencies on yum should not be added. dnf deals with chroot installation just fine, without any futher configuration: On F21: $ sudo dnf --installroot=`pwd`/test/ --disablerepo=* --enablerepo=fedora --releasever=22 install dnf Fedora 22 - x86_64 5.0 MB/s | 41 MB 00:08 Using metadata from Fri Jul 17 12:56:43 2015 (0:00:28 hours old) Dependencies resolved. =========================================================================================== Package Arch Version Repository Size =========================================================================================== Installing: acl x86_64 2.2.52-7.fc22 fedora 76 k ... Total 2.8 MB/s | 68 MB 00:24 warning: /var/tmp/test/var/cache/dnf/x86_64/22/fedora/packages/dnf-1.0.0-1.fc22.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 8e1431d5: NOKEY Importing GPG key 0x8E1431D5: Userid : "Fedora (22) <fedora>" Fingerprint: C527 EA07 A934 9B58 9C35 E1BF 11AD C094 8E14 31D5 From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-22-x86_64 Is this ok [y/N]: y Key imported successfully Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Installing : libgcc-5.1.1-1.fc22.x86_64 1/142 ... So instead, this right command should be made more widely known. It can be added to the wiki, maybe to dnf man page. And the right command seems to be (note added updates repo): dnf --installroot=<somewhere>/ --disablerepo=* --enablerepo=fedora --enablerepo=updates --releasever=<version> install <packages>
@Mosaab, What do you think about the idea from Zbigniew about add this modified command from your script to wiki and about propose dnf maintainers to put this command in dnf man page? This ticket is not moving forward and without any action from your side the ticket will be still open for a long time.
I don't think this package is useful, it's only your script, from my view I only see you enjoy pushing your own almost useless contents to repo and such scripts shouldn't be packaged. +1 for Zbigniew and dnf is preferred.
This project hosted on Github , All your suggestion could be merged . Any fixes welcomed . I don't think it's useless :)
You can submit any change you think important on Github.
I won't submit anything to things I consider useless, and your github project is not a project at all. Also I won't recommend installing it if people can do with bash directly. Make chroot environment can be done in various ways, your github one line script is worst.
It's a try .. not perfect but works .. if you want to improve it , do that ..
(In reply to Mosaab Alzoubi from comment #16) > It's a try .. not perfect but works .. if you want to improve it , do that .. The main point is, review queue in Fedora is being overrun by more and more stuffs like this. Fedora repo doesn't really need any 'try', the main aim is to provide high quality softwares instead of 'try'. Copr is the best place for such kind of stuffs. I don't see points of pushing any stuffs like this to official repo, or I would have long pushed tons of packages like this one.
> URL: http://ojuba.org If there's no web page for this project, pointing at the github repo home would be the way to go. There are more capable tools like "mock" and "mach". Disabling GPG check and bypassing mirror manager is problematic with regard to security. The "SRPM URL:" line during review is supposed to point at the src.rpm package. > Summary: Fedora Chroot Directory Maker Ambiguous. Misleading. Directories are created with commands like "mkdir". The %description also doesn't expand on it. The included README is too brief. "to enabling yum command" is very vague. The script's goal is not explained. It uses Yum to install package "yum" (and any dependencies) into the chroot directory, but what exactly that will pull in and what it will result in is undefined. Does it guarantee that Fedora repo definition files will be installed? The script contains a couple of lines at the end that are commented out. > License: GPLv3 That doesn't match %license. /usr/bin/mkchroot seems under-developed, half-baked. Overwriting /etc/yum.repos.d/fcdm.repo and removing it afterwards is highly questionable, too. This is _not_ inside the chroot. Else I agree with comment 17.
I am very curious how many people will come here and will repeat the same points: - used yum instead of dnf - Srpm package is not real srpm - disabled gpg check - license tag does not match ...etc. Dear reviewers, I would ask you about read all thread and answer in its context, before you write your comment. Then you save your time and time all people that monitors this ticket. I like Zbigniew idea which shows what we CAN do with this package instead of what we CANNOT do. If you think that there is not possible to do anything here with this package - please close this ticket. Thank you in advance for taking any action with this ticket.
It doesn't work like that. I had read all comments before I've taken an independent look nevertheless. It has not been a full review, but some of the things I've pointed out have not been commented on before.
(In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #20) > It has not been a full review, but some of > the things I've pointed out have not been commented on before. Yes, some of your points are new, thanks for them, rest is doubled.
#1246701 is now finished, and it is possible to cleanly make a chroot with: dnf -y --releasever=N --installroot=PATH --disablerepo=* --enablerepo=fedora install PACKAGE... This command was already documented in systemd-nspawn(1), but I submitted https://github.com/systemd/systemd/pull/1646 to remove --nogpg and add --enablerepo=updates, based on the discussion in this ticket. This script also supports the architecture. dnf still cannot do that, but there's a bug open.
csutherl's scratch build of fedora-tomcat-epel?#9661f8da0d7e82b63ef65ebe467e0eb103ae624f for el6-candidate and git://pkgs.fedoraproject.org/fedora-tomcat-epel?#9661f8da0d7e82b63ef65ebe467e0eb103ae624f failed http://koji.fedoraproject.org/koji/taskinfo?taskID=11823023
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time. We're sorry it is taking so long. If you're still interested in packaging this software into Fedora repositories, please respond to this comment clearing the NEEDINFO flag. You may want to update the specfile and the src.rpm to the latest version available and to propose a review swap on Fedora devel mailing list to increase chances to have your package reviewed. If this is your first package and you need a sponsor, you may want to post some informal reviews. Read more at https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group. Without any reply, this request will shortly be considered abandoned and will be closed. Thank you for your patience.
This is an automatic action taken by review-stats script. The ticket submitter failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we consider this ticket as DEADREVIEW and proceed to close it.