Bug 236162
Summary: | Review Request: kadischi - Fedora based LiveCD/LiveDVD creation utility | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jasper O. Hartline <jasperhartline> | ||||
Component: | Package Review | Assignee: | John Mahowald <jpmahowald> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Package Reviews List <fedora-package-review> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | chitlesh, dev, jpmahowald, mtasaka | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-07-07 22:09:50 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 201449 | ||||||
Attachments: |
|
Description
Jasper O. Hartline
2007-04-12 06:53:21 UTC
kadishi is already in Fedora (Extras). Hrm, now I'm confused, kadischi is listed in owners.list Fedora Extras|kadischi|An application for Fedora-based LiveCD generation| cgoorah.au|extras-qa| but I can't do a cvs checkout: $ cvs co kadischi cvs server: cannot find module `kadischi' - ignored cvs [checkout aborted]: cannot expand modules So, I'll re-open this (pending a better explanation, other than my being clueless). According to fedora-extras-comments Jasper made several commits to /cvs/devel/kadischi which brings up the question how can this require a sponsor (I thought CVS access was a sign of been already sponsored). But yeah, /cvs/devel/kadischi seems to be where it's located at the moment. (And I think I might be going crazy at the same time) The root purpose for me creating this review request is because I am the primary
upstream Kadischi maintainer and developer.
I am looking to gain control of the bugs files under Kadischi since cgoorah
Chitlesh Goorah has abandoned the project. Here is my message to the
accounts and a response from Jesse Keating:
On Wednesday 11 April 2007 21:55:50 Jasper Hartline wrote:
> > I am curious how to go about becoming the assignee for bugs filed under
> > component "Kadischi"
> > in the http://bugzilla.redhat.com Bugzilla system. Chitlesh Goorah
> > (cgoorah) has abandoned the project
> > and bugs are not being taken care of.
> >
> > Just as a reference I am the primary developer/maintainer for Kadischi
> > at this time.
> > If I could get some guidance on this issue that would be helpful.
You'd have to take over the packaging of it for Fedora Extras. The bugzilla
entry is for the package in Extras, not necessarily the upstream of kadischi.
-- Jesse Keating Release Engineer: Fedora
I will notify Jesse Keating of this bugzilla review request and see what he
says, I assumed this was the proper process. Thank you.
This is the proper process, yes, for new packages, no worries. Ownership change was requested: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237402 (In reply to comment #0) > I am a new packager and require a sponser. > Thanks. I'm sponsoring you Jasper. from now on there's no need to use %ghost for *.pyc *.pyo file The package doesn't seem to want to build with %ghost removed for *.pyc and *.pyo files, take a look: error: Installed (but unpackaged) file(s) found: /usr/share/kadischi/kadischi.pyc /usr/share/kadischi/kadischi.pyo /usr/share/kadischi/lib/functions.pyc /usr/share/kadischi/lib/functions.pyo /usr/share/kadischi/lib/shvar.pyc /usr/share/kadischi/lib/shvar.pyo /usr/share/kadischi/movefiles.pyc /usr/share/kadischi/movefiles.pyo /usr/share/kadischi/post_install_scripts/03fstab.pyc /usr/share/kadischi/post_install_scripts/03fstab.pyo /usr/share/kadischi/post_install_scripts/05fsclean.pyc /usr/share/kadischi/post_install_scripts/05fsclean.pyo /usr/share/kadischi/post_install_scripts/06sysconfig.pyc /usr/share/kadischi/post_install_scripts/06sysconfig.pyo RPM build errors: Installed (but unpackaged) file(s) found: /usr/share/kadischi/kadischi.pyc /usr/share/kadischi/kadischi.pyo /usr/share/kadischi/lib/functions.pyc /usr/share/kadischi/lib/functions.pyo /usr/share/kadischi/lib/shvar.pyc /usr/share/kadischi/lib/shvar.pyo /usr/share/kadischi/movefiles.pyc /usr/share/kadischi/movefiles.pyo /usr/share/kadischi/post_install_scripts/03fstab.pyc /usr/share/kadischi/post_install_scripts/03fstab.pyo /usr/share/kadischi/post_install_scripts/05fsclean.pyc /usr/share/kadischi/post_install_scripts/05fsclean.pyo /usr/share/kadischi/post_install_scripts/06sysconfig.pyc /usr/share/kadischi/post_install_scripts/06sysconfig.pyo [autopsy@localhost ~]$ Here is the new SRPM: http://autopsy.podzone.org/~autopsy/kadischi-3.5-2.20070423cvs.src.rpm Here is the new SPEC file: http://autopsy.podzone.org/~autopsy/kadischi.spec Hello Jasper, * being the one who sponsored you * and having received several unpleasing (private) emails concerning your personal character in the Fedora World (irc,mailing list...) * having worked which you on the kadischi project in the past, I'm thereby pointing to you from my own perspective that you have proven yourself to be quite disagreeable and quick to lash out at people trying to help you on IRC who don't give you exactly the answer you want, very quickly resorting to profanity and name-calling. However I respect the way you are pushing the dying project "Kadischi" to the surface, I guess you need support, so do any other fedora maintainer. Maintaining a package "X" in the Fedora Universe requires good communication with other fedora maintainers and with steering community members eventually. I know, the kadischi project is very dear to you and I'm sure that you will cooperate without any inconvenience in any situation to any fedora contributor. Am I right ? It is important for me to know where you stand to continue kadischi's review. I'm sure I've been harsh in some situations, and or not fully understanding of what is being presented to me by people who are unsure of some of my requests and what I am meaning, but yes I am very willing to participate and contribute to the Fedora Project with my maintaining and packaging of Kadischi without inconvenience to other Fedora Controbutors. I think the major issue is that the newer project livecd-tools/Pilgrim/Punji is said to "obsolete" or "make Kadischi irrelevant" which may be the case, however it doesn't hold weight in the sense that providing Kadischi in Fedora Extras, or what is now to be just Fedora, gives users flexibility in the tools they choose to use, and options or choices to use several different tools or all of the tools provided to do a single task. In any case, to answer your main question, No.. I have no problem cooperating with current Fedora Contributors and maintainers. Thanks. (In reply to comment #12) > In any case, to answer your main question, No.. I have no problem cooperating with current Fedora Contributors and maintainers. > Thanks. Thanks, the quick answer. You'll need to add me as your co-maintainer of kadischi for cvsextras when approved. %{?dist} is missing in the spec file. Can you make some informal reviews of some packages queued for review so that you can grasp the fedora packaging guidelines quickly. Don't forget to add me in the CC: list of the bug you are reviewing. - Strigi ( 223586 ) - ruby-gettext-package (237380) might be simple Here is the new SPEC file and SRPM: http://autopsy.podzone.org/~autopsy/kadischi.spec http://autopsy.podzone.org/~autopsy/kadischi-3.5-3.fc6.src.rpm I have done an informal package review for package reviews BZ# 223586 and 237380 Just from I checked your spec file: * Some of the directories which should be owned by this package are actually not owned. * Please specify the full URL of the source or provide the way we can get the source of this package. * The group of this package "Applications/System" is correct? For example, pungi has "Development/Tools" (In reply to comment #16) > Just from I checked your spec file: > > * Some of the directories which should be owned by > this package are actually not owned. Can you specify which directories you are talking about? > * Please specify the full URL of the source or provide the > way we can get the source of this package. The URL is a pointer to the Wiki page on FedoraProject.org where it can be retrieved using CVS. > * The group of this package "Applications/System" is correct? > For example, pungi has "Development/Tools" Yes, System/Applications is correct to my knowledge, since there is no development package associated with this package, nor is it built against in any form or fashion. It isn't an IDE for programming, or any sort of compiler. (In reply to comment #17) > (In reply to comment #16) > > Just from I checked your spec file: > > > > * Some of the directories which should be owned by > > this package are actually not owned. > Can you specify which directories you are talking about? > > * Please specify the full URL of the source or provide the > > way we can get the source of this package. > The URL is a pointer to the Wiki page on FedoraProject.org where it can be > retrieved using CVS. > > > * The group of this package "Applications/System" is correct? > > For example, pungi has "Development/Tools" > Yes, System/Applications is correct to my knowledge, since there is no > development package associated with this package, nor is it built against in any > form or fashion. It isn't an IDE for programming, or any sort of compiler. And mockbuild failed on FC-devel i386. The build log shows that -lz is needed on some compiling. Created attachment 153866 [details] mock build log of kadischi-3.5-3 on FC-devel i386 Sorry, the previous my comment was a draft. Please ignore it... (In reply to comment #17) > (In reply to comment #16) > > Just from I checked your spec file: > > > > * Some of the directories which should be owned by > > this package are actually not owned. > Can you specify which directories you are talking about? They are: -------------------------------------------------- %{_datadir}/%{name}/lib/ %{_datadir}/%{name}/post_install_scripts/ %{_datadir}/%{name}/initrd/ %{_datadir}/%{name}/ks_examples/ ......... --------------------------------------------------- Not only the files under these directories but also these directories themselves must be owned. NOTE: When you write: ------------------------------------- %files %defattr(-,root,root,-) %dir foo/ ------------------------------------- (where foo/ is a directory), this means the directory foo/ only, where when you write ------------------------------------- %files %defattr(-,root,root,-) foo/ ------------------------------------- this means the directory foo/ itself and all files/directories/etc.. under foo/. > > * Please specify the full URL of the source or provide the > > way we can get the source of this package. > The URL is a pointer to the Wiki page on FedoraProject.org where it can be > retrieved using CVS. In this case, you have to write as comments how you created the source tarball (please check the section "Using Revision Control" of http://fedoraproject.org/wiki/Packaging/SourceURL . And in that case, it is mandatory that the date when you created the tarball by cvs is included into release number. http://fedoraproject.org/wiki/Packaging/NamingGuidelines#SnapshotPackages And mockbuild failed on FC-devel i386. The build log shows that -lz is needed on some compiling. Sorry, two more issues: E: kadischi non-executable-script /usr/share/kadischi/desktop/userhome.sh 0644 W: kadischi spurious-executable-perm /usr/share/doc/kadischi-3.5/COPYING The formar: * This script has shebang (/bin/bash) but is not executable. - If this script is only sourced, then it should not have shebang - Otherwise (i.e. if this scripts can be executed directly), then it should be executable The latter: * Permission is incorrect (0755), which should be 0644. (In reply to comment #20) > E: kadischi non-executable-script /usr/share/kadischi/desktop/userhome.sh 0644 Actually, this script isn't used by kadischi, but a script which is called during the live environment of kadischi's output (the Live iso). Perhaps, kadischi could set the file permission of userhome.sh properly before copying it to the iso image. And hence, that might fix the rpmlint error. A Request for Enhancement to kadischi. The new SRPM and SPEC are here: http://autopsy.podzone.org/~autopsy/kadischi.spec http://autopsy.podzone.org/~autopsy/kadischi-3.5-4.20070501.src.rpm About the rpmlint warnings and errors: I have removed and replaced the items mentioned from rpmlint in CVS, they keep inheriting the permissions it is complaining about. Kadischi already sets this files permissions to 755 after copying it to the LiveCD environment. So that RFE is not neccessary. About the Mock build errors: I am not certain I understand this one. From the looks of it, this is an error in the pciutils-devel or pciutils package in Mock, since the reference of the error is like so: /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `pci_load_name_list': (.text+0x6e8): undefined reference to `gzopen' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `pci_load_name_list': (.text+0x781): undefined reference to `gzgets' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L174': (.text+0x886): undefined reference to `gzclose' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L174': (.text+0x8a8): undefined reference to `gzeof' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L174': (.text+0x945): undefined reference to `gzclose' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L174': (.text+0xd74): undefined reference to `gzopen' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L177': (.text+0xf17): undefined reference to `gzerror' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L177': (.text+0xf3a): undefined reference to `gzclose' collect2: ld returned 1 exit status libpci.a nor names.o is part of the Kadischi package, if -lz was added which made the package compile, I do believe this is an issue with Mock, not Kadischi. Can you clear this up and show me how -lz is needed in Kadischi? (In reply to comment #17) > The URL is a pointer to the Wiki page on FedoraProject.org where it can be > retrieved using CVS. True. However I guess you misunderstood me for the %{?dist}, which confused Mamuro that you pulled the kadischi sources from the cvs. Your Release: should be Release: 3{alphatag}%{?dist} > Yes, System/Applications is correct to my knowledge, since there is no > development package associated with this package, nor is it built against in any form or fashion. It isn't an IDE for programming, or any sort of compiler. I chose System/Applications for kadischi for the same reason that Jasper explained. (In reply to comment #19) > ------------------------------------- > %files > %defattr(-,root,root,-) > foo/ > ------------------------------------- > this means the directory foo/ itself and all > files/directories/etc.. under foo/. In this case the %files section can be reduced to: %files %defattr(-,root,root,-) %doc FAQ README TODO COPYING CREDITS %{_datadir}/%{name} %{_libexecdir}/%{name} %{_sbindir}/%{name} %dir %{_sysconfdir}/%{name} %config(noreplace) %{_sysconfdir}/%{name}/buildstamp %config(noreplace) %{_sysconfdir}/%{name}/%{name}.conf %{_mandir}/man1/%{name}.1.gz %{_mandir}/man5/%{name}.conf.5.gz > And mockbuild failed on FC-devel i386. The build log shows > that -lz is needed on some compiling. > libz-devel is missing as BR. Below is from the rpmbuild: [...] /usr/bin/install -c -m 644 'userhome.desktop' '/var/tmp/kadischi-3.5-2.20070501cvs-root-chitlesh/usr/share/kadischi/desktop/userhome.desktop' /usr/bin/install -c -m 644 'userhome.sh' '/var/tmp/kadischi-3.5-2.20070501cvs-root-chitlesh/usr/share/kadischi/desktop/userhome.sh' /usr/bin/install -c -m 644 'install.desktop' '/var/tmp/kadischi-3.5-2.20070501cvs-root-chitlesh/usr/share/kadischi/desktop/install.desktop' [...] You can see that that the "-p" argument is missing which for preserving timestamps. Timestamps should be preserved. This can be done by using make INSTALL="install -p" DESTDIR=%{buildroot} install instead of make install DESTDIR=%{buildroot} Another thing the package entails an empty folder: /usr/share/kadischi/patches Actually when I was maitaining kadischi with you, Jasper, this folder contained patches for kadischi itself. However for a user using kadischi it is useless. Please, correct me if that has changed. (In reply to comment #22) > About the Mock build errors: > I am not certain I understand this one. > From the looks of it, this is an error in the pciutils-devel or > pciutils package > in Mock, since the reference of the error is like so: <snip> > collect2: ld returned 1 exit status > > libpci.a nor names.o is part of the Kadischi package, > if -lz was added which > made the package compile, I do believe this is an issue with Mock, > not Kadischi. > Can you clear this up and show me how -lz is needed in Kadischi? zlib compression support is added from pciutils 2.2.4 (not available on FC-6 pciutils 2.2.3) and linkage against libz.so is needed to use libpci.a in pciutils (i.e. libpci.a uses libz.so, however as this is a static archive, linkage cannot be done beforehand). > libz-devel is missing as BR. > There is no libz-devel package in either Fedora Core 6 or the RAWHIDE tree that I can see. I've added -lz though to the linker flags, the new package with all changes is below. > Another thing the package entails an empty folder: > /usr/share/kadischi/patches > > Actually when I was maitaining kadischi with you, Jasper, this folder > contained patches for kadischi itself. However for a user using kadischi it is > useless. Please, correct me if that has changed. Originally this directory contained patches for Anaconda, which have since been merged into Anaconda. While the directory is not in use anymore, I can't simply delete it from CVS since I do not have cvsadmin priviliges. The new SRPM and SPEC are here: http://autopsy.podzone.org/~autopsy/kadischi.spec http://autopsy.podzone.org/~autopsy/kadischi-3.5-5.20070501cvs.fc6.src.rpm (In reply to comment #25) > > libz-devel is missing as BR. > > > There is no libz-devel package in either Fedora Core 6 or the RAWHIDE tree that Sorry, its zlib-devel chitlesh(SPECS)[0]$rpm -ql zlib-devel | grep so /usr/lib/libz.so > Originally this directory contained patches for Anaconda, which have since been > merged into Anaconda. While the directory is not in use anymore, I can't simply > delete it from CVS since I do not have cvsadmin priviliges. But you can delete it from the rpm package :) (In reply to comment #22) > About the rpmlint warnings and errors: > I have removed and replaced the items mentioned from rpmlint in CVS, they keep > inheriting the permissions it is complaining about. > Kadischi already sets this files permissions to 755 after copying it to the > LiveCD environment. So that RFE is not neccessary. Similar to comment 26, you can fix the permission in the spec file. You don't have to fix the permission in CVS. ---------------------------------------------------- %define alphatag %(date +%%Y%%m%%d)cvs ---------------------------------------------------- IMO this %alphatag should be hardcoded, i.e. you should write alphatag as 20070501cvs directly. When I rebuilt 20070501cvs srpm, the result binary rpms has 20070502cvs name because I live in Japan (UTC+0900) and currently it is May 2! So this results in different name binary rpms according to where rebuilder lives. (And I go to sleep for now...) > Similar to comment 26, you can fix the permission in the spec > file. You don't have to fix the permission in CVS. I'm pretty sure this is outside the realm of SPEC file usage. I would rather have the permissions fixed within CVS, rather than have multiple perm lines in %files or have chmod hacks in the SPEC file. Also about the %[alphatag}, I read that the tagging must not be overridden by local build specifications. This is also how it shows on the wiki to provide a package from CVS. Here is the new SPEC file and SRPM: http://autopsy.podzone.org/~autopsy/kadischi.spec http://autopsy.podzone.org/~autopsy/kadischi-3.5-6.20070501cvs.fc6.src.rpm Here are the new SPEC and SRPM files which fix the permissions errors/warnings from rpmlint: http://autopsy.podzone.org/~autopsy/kadischi.spec http://autopsy.podzone.org/~autopsy/kadischi-3.5-7.20070502cvs.fc6.src.rpm > Also about the %[alphatag}, I read that the tagging must not be overridden by > local build specifications. This is also how it shows on the wiki to provide a > package from CVS. what kind of local build specifications ? Actually, what is asked is to have the date hardcoded, because there is a difference between : * cvs checkout and * rpm build Thus with your 3.5-7.20070502cvs spec file, when I build the rpm it will entail the date of build but not the date of cvs checkout. Example : if I rpmbuild --rebuild kadischi-3.5-7.20070502cvs.fc6.src.rpm the output rpms will be: Wrote: /home/chitlesh/rpmbuild/RPMS/i386/kadischi-3.5-7.20070510cvs.fc7.i386.rpm Wrote: /home/chitlesh/rpmbuild/RPMS/i386/kadischi-debuginfo-3.5-7.20070510cvs.fc7.i386.rpm You can clearly see the difference over here. I'll fix the above issue in CVS. There is a more important issue however with this: http://fedoraproject.org/wiki/Kadischi/Documentation#head-df51ce5d2556a74228a37c021481b062363ba6ff Paul Jones has told me this is fine in the short term, compiling the twi binaries statically, but we need to find a long term solution. Do you have any ideas? I'm also talking this over with other Fedora Contributors. All issues have been corrected. The new SPEC and SRPM are located here: http://autopsy.podzone.org/~autopsy/kadischi.spec http://autopsy.podzone.org/~autopsy/kadischi-3.6-2.20070511cvs.fc6.src.rpm Package has been rebuilt. The SRPM and SPEC files are here: http://autopsy.podzone.org/~autopsy/kadischi.spec http://autopsy.podzone.org/~autopsy/kadischi-3.6-3.20070528cvs.fc6.src.rpm rpmlint: W: kadischi strange-permission kadischi.spec 0600 Still works. Ignore. E: kadischi no-binary Python scripts. Ignore. W: kadischi-tools no-documentation Docs in main package. Ignore. Follows naming guidelines for cvs snapshot. Instructions for snapshot in spec. License (GPL), COPYING in %doc Builds in mock on x86_64. BuildRequires look sane. %files section with %defattr Owns directories it creates, doesn't own other package's files. %clean section Use of macros. Have not tested this on any ppc hardware. I don't see anything dealing with yaboot explicitly. So two issues: does it build, and does it build live media on this arch. Using mock and rpmbuild on a PPC machine and target architecture as "ppc" Kadischi builds fine. Until I am able to obtain PPC hardware or a chroot'ed PPC shell account with root priveliges, I cannot do any work on Kadischi to make it operate properly, as in build a working LiveCD image. Anaconda requires root access to be able to install to the fake root which it uses, this is a function of Anaconda, not Kadischi it's self. It does build however under PPC. Thanks. + BuildRoot good + Uses SMP flags + documentation tagged with %doc + good Summary and %description + files in the right places, %{_sysconfdir} for configs, %{_datadir} for scripts and data, %{_libexecdir} for the tools %description says Fedora Core, you might want to remove Core when building on F7+ :) Comment 34 still applies. APPROVED Jasper, please try to import this to Fedora. Please define what you think needs noting in the release notes for which version of Fedora, or remove the fedora_requires_release_note flag. Thanks. What is the state of this bug? Well, sounds like Jasper is no more interested in kadischi. I'll say, I'll close this bug as WONTFIX on 6 July 2007 (in 2 days) if Jasper doesn't reply. I don't like sponsoring someone who vanishes out of the blue ! (In reply to comment #40) Oh... > I don't like sponsoring someone who vanishes out of the blue ! Are there any guidance to deal this situation? Actually I also have a problem that I reviewed one person's review request, I decided to sponsor him, but then he disappeared suddenly and the package is not yet imported... Not to what I know of. However I'll start discussion on the mailing list. Toshio, I'm afraid that this link doesn't help us, since Mamoru and I were referring to the state of packager's (whom we granted sponsorship) status. The wiki page lacks such information. Closing bug as NOTABUG ! |