Spec URL: <spec info here> SRPM URL: <srpm info here> Description: <DOSEMU is a user-level program which uses certain special features of the Linux kernel and the 80386 processor to run MS-DOS/FreeDOS/ DR-DOS, DOS programs, and many DPMI applications in what we in the biz call a `DOS box'.> I don't have any place to host the spec file and SRPM, this is my first package, and I am looking for a sponsor. Thanks.
Create a Fedora account, sign the CLA and apply for fedorabugs group. https://admin.fedoraproject.org/accounts/group/view/fedorabugs I will sponsor you for that group which will you give free space in http://fedorapeople.org in an hour after that. Meanwhile, feel free to email me or ping me in #fedora-devel, nick is mether and I will be happy to host them for you.
OK, thanks. all done, here are the links to the spec file and SRPM: Spec URL: <http://jzygmont.fedorapeople.org/dosemu.spec> SRPM URL: <http://jzygmont.fedorapeople.org/dosemu-1.4.0-1868svn.i386.rpm>
Silly me, I uploaded the RPM, not the SRPM. Ok, here is the correct info: Spec URL: <http://jzygmont.fedorapeople.org/dosemu.spec> SRPM URL: <http://jzygmont.fedorapeople.org/dosemu-1.4.0-1868svn.src.rpm>
i'm getting stuck, this whole process seems less than straight forward to me. I have followed the process here: http://fedoraproject.org/wiki/PackageMaintainers/Join and I don't know what else to do, this is my first package, do you know where I am on this?
You need patience. We have 800+ packages waiting on review. I would suggest that you either submit more packages or review existing packages. The details are given in http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored
rpmlint output: [rpmbuild@rocky dosemu]$ rpmlint -i dosemu-1.4.0-1868svn.src.rpm dosemu.src:14: W: buildprereq-use bison flex The use of BuildPreReq is deprecated, build dependencies are always required before a package can be built. Use plain BuildRequires instead. dosemu.src:21: W: rpm-buildroot-usage %prep rm -rf $RPM_BUILD_ROOT $RPM_BUILD_ROOT should not be touched during %build or %prep stage, as it will break short circuiting. dosemu.src:24: E: use-of-RPM_SOURCE_DIR You use $RPM_SOURCE_DIR or %{_sourcedir} in your spec file. If you have to use a directory for building, use $RPM_BUILD_ROOT instead. dosemu.src:25: W: configure-without-libdir-spec A configure script is run without specifying the libdir. configure options must be augmented with something like --libdir=%{_libdir} whenever the script supports it. dosemu.src: E: no-cleaning-of-buildroot %install You should clean $RPM_BUILD_ROOT in the %clean section and just after the beginning of %install section. Use "rm -Rf $RPM_BUILD_ROOT". dosemu.src: W: non-standard-group System/Emulators The value of the Group tag in the package is not valid. Valid groups are: "Amusements/Games", "Amusements/Graphics", "Applications/Archiving", ------------- dosemu.src: E: no-changelogname-tag There is no %changelog tag in your spec file. To insert it, just insert a '%changelog' in your spec file and rebuild it. dosemu.src: W: invalid-license GPL The value of the License tag was not recognized. Known values are: "Adobe", ------------ dosemu.src: W: no-url-tag The URL tag is missing. 1 packages and 0 specfiles checked; 3 errors, 6 warnings. rpmlint after building for i386: [rpmbuild@rocky i386]$ rp -i dosemu-1.4.0-1868svn.i386.rpm dosemu.i386: W: symlink-should-be-relative /etc/dosemu/drives/d /usr/share/dosemu/drive_z Absolute symlinks are problematic eg. when working with chroot environments. dosemu.i386: W: file-not-utf8 /usr/share/man/ru/man1/dosemu.1.gz The character encoding of this file is not UTF-8. Consider converting it in the specfile for example using iconv(1). dosemu.i386: W: symlink-should-be-relative /etc/dosemu/drives/c /usr/share/dosemu/drive_z Absolute symlinks are problematic eg. when working with chroot environments. dosemu.i386: E: non-standard-dir-perm /usr/share/dosemu 0775 A standard directory should have permission set to 0755. If you get this message, it means that you have wrong directory permissions in some dirs included in your package. dosemu.i386: W: file-not-utf8 /usr/share/man/ru/man1/mkfatimage16.1.gz The character encoding of this file is not UTF-8. Consider converting it in the specfile for example using iconv(1). dosemu.i386: W: file-not-utf8 /usr/share/doc/dosemu/COPYING.DOSEMU The character encoding of this file is not UTF-8. Consider converting it in the specfile for example using iconv(1). dosemu.i386: E: non-standard-dir-perm /usr/share/dosemu/drive_z/doc/exe2bin 0775 A standard directory should have permission set to 0755. If you get this message, it means that you have wrong directory permissions in some dirs included in your package. dosemu.i386: E: non-standard-dir-perm /usr/share/dosemu/drive_z 0775 A standard directory should have permission set to 0755. If you get this message, it means that you have wrong directory permissions in some dirs included in your package. dosemu.i386: W: dangling-symlink /usr/share/dosemu/drive_z/tmp /tmp The symbolic link points nowhere. dosemu.i386: W: symlink-should-be-relative /usr/share/dosemu/drive_z/tmp /tmp Absolute symlinks are problematic eg. when working with chroot environments. dosemu.i386: W: file-not-utf8 /usr/share/man/ru/man1/dosemu.bin.1.gz The character encoding of this file is not UTF-8. Consider converting it in the specfile for example using iconv(1). dosemu.i386: E: no-changelogname-tag There is no %changelog tag in your spec file. To insert it, just insert a '%changelog' in your spec file and rebuild it. dosemu.i386: W: no-url-tag The URL tag is missing. dosemu.i386: W: unstripped-binary-or-object /usr/lib/dosemu/libplugin_term.so dosemu.i386: W: unstripped-binary-or-object /usr/lib/dosemu/libplugin_X.so dosemu.i386: W: unstripped-binary-or-object /usr/lib/dosemu/libplugin_sdl.so dosemu.i386: W: unstripped-binary-or-object /usr/lib/dosemu/libplugin_gpm.so dosemu.i386: W: unstripped-binary-or-object /usr/lib/dosemu/libplugin_sndfile.so dosemu.i386: W: unstripped-binary-or-object /usr/lib/dosemu/libplugin_alsa.so dosemu.i386: W: dangerous-command-in-%pre mv 1 packages and 0 specfiles checked; 4 errors, 18 warnings. * SPEC file will look sane if different sections have space between. * repetitive patterns are reduced with regular exp or loop constructs -- optional * Changelog present * URL & source url present. * Correct License tag * rpmlint output needs to be clean. removing 'E' are MUST. rpmlint -i shows necessary diagnosing messages. * may be you can consult few example specs from other packages. * And skim Packaging Guideline must items. * use relative sym links -- move to folder and create 'ln -s <target> /path/to/<link_name> * chmod +x /path/to/*so will remove unstripped-binary-or-object warning Note: Wiki and packageDB are down for the moment but hopefully will be soon up. waiting for update..
thanks for this, I have been learning a lot already. ok, I have fixed as many errors as I could with the src.rpm, there are 2 more than I cannot understand easily: # rpmlint -i dosemu-1.4.0-1868svn.src.rpm dosemu.src:27: E: use-of-RPM_SOURCE_DIR You use $RPM_SOURCE_DIR or %{_sourcedir} in your spec file. If you have to use a directory for building, use $RPM_BUILD_ROOT instead. dosemu.src:28: W: configure-without-libdir-spec A configure script is run without specifying the libdir. configure options must be augmented with something like --libdir=%{_libdir} whenever the script supports it. dosemu.src: E: no-cleaning-of-buildroot %install You should clean $RPM_BUILD_ROOT in the %clean section and just after the beginning of %install section. Use "rm -Rf $RPM_BUILD_ROOT". 1 packages and 0 specfiles checked; 2 errors, 1 warnings. I think the first Error just needs to have the freedos tar file in the BUILD directory, Do you have any idea how I can copy the freedos tar file from $RPM_SOURCE_DIR to $RPM_BUILD_ROOT in the %prep section? Also, I cant seem to get rid of the last error no matter what I do: no-cleaning-of-buildroot %install. I have uploaded the new src.rpm and spec file to: http://fedorapeople.org/~jzygmont/ Any suggestions will go a long ways, thanks.
(In reply to comment #7) > # rpmlint -i dosemu-1.4.0-1868svn.src.rpm > dosemu.src:27: E: use-of-RPM_SOURCE_DIR > You use $RPM_SOURCE_DIR or %{_sourcedir} in your spec file. If you have to use > a directory for building, use $RPM_BUILD_ROOT instead. Use: [...] --with-fdtarball=%{SOURCE1} > dosemu.src:28: W: configure-without-libdir-spec > A configure script is run without specifying the libdir. configure options > must be augmented with something like --libdir=%{_libdir} whenever the script > supports it. Use the configure macro and do not call configure directly. %configure --with-fdtarball=%{_sourcedir}/dosemu-freedos-bin.tgz Read here for a description: http://docs.fedoraproject.org/developers-guide/ch-rpm-building.html > dosemu.src: E: no-cleaning-of-buildroot %install > You should clean $RPM_BUILD_ROOT in the %clean section and just after the > beginning of %install section. Use "rm -Rf $RPM_BUILD_ROOT". Just do what is written. Write "rm -rf $RPM_BUILD_ROOT" in the first line after the "%install" line. That is: %install rm -rf $RPM_BUILD_ROOT Moreover, just having a quick glance at your spec, I saw that: * RPM_OPT_FLAGS are not used. * changelog is not in a valid format: https://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs BTW, changelog should refer to the RPM not the main software. There is already a file named ChangeLog for this. * ChangeLog* files are not packaged. * Other doc packages are not packages. For example Bugs. * %{_datadir}/doc/dosemu is not a valid doc directory. It must be %{_docdir}/%{name}-%{version}. %{_docdir} is a macro for %{_datadir}/doc. * %{_datadir}/dosemu is not a valid data directory. It must be %{_datadir}/%{name}-%{version}. * use of macros can be improved: https://fedoraproject.org/wiki/Packaging/Guidelines#Macros * desktop files for GUI programs are missing: https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files * These defines are not needed: %define name dosemu %define version 1.4.0 Just use: Name: dosemu Version: 1.4.0 You will automatically have macros for these. * release tag is not correct: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Package_Release * buildroot is not correct: https://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag * Many BuildRequires are missing. Please recheck them!!! I read in the INSTALL file: - development libraries: X and S-Lang are strongly recommended. For full-screen use with X.org 7 or newer you may also need the libXxf86vm development libraries. GPM, SDL (>= 1.2), SVGALIB (>= 1.9.21), ALSA libraries, and libsndfile can be used when available. * Since this is the first version of dosemu for Fedora, I think that %pre section is not needed. * Why are you packaging a development version? Even thought this is not forbidden, I think is should be motivated. Bye, Andrea.
Ping.
Thanks a lot, your help went a long ways. I have fixed everything you listed, and here is the output of rpmlint: # rpmlint -i dosemu-1.4.0-1868svn.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. # rpmlint -i dosemu-1.4.0-1868svn.i386.rpm dosemu.i386: W: symlink-should-be-relative /etc/dosemu/drives/d /usr/share/dosemu/drive_z Absolute symlinks are problematic eg. when working with chroot environments. dosemu.i386: W: file-not-utf8 /usr/share/man/ru/man1/dosemu.1.gz The character encoding of this file is not UTF-8. Consider converting it in the specfile for example using iconv(1). dosemu.i386: W: symlink-should-be-relative /etc/dosemu/drives/c /usr/share/dosemu/drive_z Absolute symlinks are problematic eg. when working with chroot environments. dosemu.i386: W: file-not-utf8 /usr/share/doc/dosemu-1.4.0/COPYING.DOSEMU The character encoding of this file is not UTF-8. Consider converting it in the specfile for example using iconv(1). dosemu.i386: W: file-not-utf8 /usr/share/man/ru/man1/mkfatimage16.1.gz The character encoding of this file is not UTF-8. Consider converting it in the specfile for example using iconv(1). dosemu.i386: W: dangling-symlink /usr/share/dosemu/drive_z/tmp /tmp The symbolic link points nowhere. dosemu.i386: W: symlink-should-be-relative /usr/share/dosemu/drive_z/tmp /tmp Absolute symlinks are problematic eg. when working with chroot environments. dosemu.i386: W: file-not-utf8 /usr/share/man/ru/man1/dosemu.bin.1.gz The character encoding of this file is not UTF-8. Consider converting it in the specfile for example using iconv(1). 1 packages and 0 specfiles checked; 0 errors, 8 warnings. As well my updated spec file and rpms are here: http://fedorapeople.org/~jzygmont/
Reverted fedora-review flag @Justin - you are not supposed to change flag. When some sponsor comes for review he will first set it to '?' once official review starts. Once it is complete then it is marked as '+' Thanks
(In reply to comment #10) > Thanks a lot, your help went a long ways. I have fixed everything you listed, > and here is the output of rpmlint: You are welcome. Since rpmlint output is not clean, you still have some work to do. Please go on and fix those errors. You might find help here: https://fedoraproject.org/wiki/PackageMaintainers/Common_Rpmlint_Issues
hi, I am not sure how this should be done, iconv needs to know what the file format is, and there doesnt seem to be any type that matches: troff or preprocessor input text ASCII Pascal program text Non-ISO extended-ASCII English text, with LF, NEL line terminators The other warnings might be ok, I don't know I can set the symbolic links with a relative path, and dosemu would never run chroot anyways.
(In reply to comment #13) > hi, I am not sure how this should be done, iconv needs to know what the file > format is, and there doesnt seem to be any type that matches: > > troff or preprocessor input text > ASCII Pascal program text > Non-ISO extended-ASCII English text, with LF, NEL line terminators I haven't looked at the file but most files are usually ISO 8859-1. Russian ones should be ISO 8859-5. Try to convert them and see if the results make sense. > The other warnings might be ok, I don't know I can set the symbolic links with > a relative path, and dosemu would never run chroot anyways. Ehm... no, I don't think they are OK. Search for a solution in Fedora CVS. Moreover, Source URL is missing: https://fedoraproject.org/wiki/Packaging/SourceURL#Sourceforge.net I read in COPYING.DOSEMU: Parts of the code not covered by the GPL are marked explicitly within the code, and the copyrights are also at the end of this file. The rest of the code is covered by the GPL. Therefore you should update License tag accordingly: https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios Bye, Andrea.
Watching closely your new spec file I noticed other things: * %configure --with-fdtarball=%{SOURCE1} is enough to set prefix and mandir (and a lot other things) To understand this, try: $ rpm --eval='%configure' * %setup -q should be enough. Your %setup -q -T -b 0 doesn't make sense: http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html * Release tag is still not correct: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Package_Release * I suggest you to explicit the desktop file in %files in this way: %{_datadir}/applications/%{name}.desktop It is much more readable than: %{_datadir}/applications/* * I don't think this is needed. BuildRequires: binutils Otherwise please explain. * Have you tried building the RPM in mock to test your dependencies? https://fedoraproject.org/wiki/PackageMaintainers/MockTricks * Forget my previous comment about Source URL, but I really want to know why you are packaging a development version. What are pro's and con's compared to the latest stable version? * As Rahul said, you should really need to follow this guide to get sponsored: https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored You only seems to comment on this bug. This is not enough to find a sponsor and get sponsored.
my apologies for the long delay, I will continue to work on this and other packages, and update further. Thanks for everyone's patience and help.
ping, how's the package coming along?
hi, just getting back to it now that I have my Fedora10 test system built, I definitely want to get this going
Ping
ok, i've fixed most of the problems Andrea pointed out in the last message, rpmlint now shows only 2 warnings which I think I have to keep, and I still dont see whats wrong with the release tag so far, I welcome any comments. Ive uploaded the latest RPM's and spec file into: http://fedorapeople.org/~jzygmont/ BTW, the reason why i'm creating an SVN snapshot is because there are important changes in SVN since the last release, and it could be some time before the maintainer creates another main release if ever. In all the years i've been with the project, theres less interest in DOS than there used to be. Having no package available doesnt help, i'd love to have a RPM available for Fedora. This is my first at package building and i've learned a lot so far, i'm also not a developer, i'm a system and network admin. hope this helps....
(In reply to comment #20) > ok, i've fixed most of the problems Andrea pointed out in the last message, > rpmlint now shows only 2 warnings which I think I have to keep, and I still > dont see whats wrong with the release tag so far, I welcome any comments. * Dosemu 1.4.0 (1.4.0 is the version you declared) has already been released. So the one you are packaging is a post-release snapshot version and it must follow this guideline: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Snapshot_packages Therefore 1868svn in the release tag is not acceptable. Release Tag for Post-Release Snapshot Packages is %{X}.%{alphatag}. In this syntax, %{X} is the release number increment and %{alphatag} is the checkout string. * You are still not updating the changelog after each release. This is wrong. I already told you. In this way we cannot read the history of the package. * desktop-file-install \ --vendor=fedora \ --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \ %{SOURCE2} You must not use a vendor. Please read: https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor * Categories=System;Emulator; The Categories in the desktop file should be changed to "Game;Emulator;". This is what other emulators use. * Source: %{name}-%{version}.tgz Source1: %{name}-freedos-bin.tgz Source is missing full URL (which is OK because this is a snapshot package) but you are not following the guidelines on how to create the snapshot. Full URL for Source1 is missing. More info about both issues here: https://fedoraproject.org/wiki/Packaging/SourceURL * BuildRequires: binutils This is not required. This dependency is already pulled in by default. https://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 * BuildRequires: bison flex For constituency with other BR's, please split the above in two lines. * You are still not following the guidelines about licensing. There are parts that are not covered by the GPL. You must identify those parts and understand under what licences they are. After that you must update the License tag accordingly. https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios * I cannot build the rpm ATM, but it seems to me that the following problems where not addressed: - RPM_OPT_FLAGS are not used. - Text files are not UTF-8.
I tried following all the sketchy guidelines, and following your advise, etc. I'm ready to just leave it with comments like this, I can build a fedora RPM.
(In reply to comment #22) > I tried following all the sketchy guidelines, and following your advise, etc. > I'm ready to just leave it with comments like this, I can build a fedora RPM. I cannot follow you. Can you clear your thought? If you need support, please ask. If something is not clear, please ask.
Justin? What's the status of this? (In reply to comment #21) > * Categories=System;Emulator; > > The Categories in the desktop file should be changed to "Game;Emulator;". This > is what other emulators use. This is wrong and silly. System is perfectly valid: http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry
(In reply to comment #24) > > * Categories=System;Emulator; > > > > The Categories in the desktop file should be changed to "Game;Emulator;". This > > is what other emulators use. > > This is wrong and silly. System is perfectly valid: > http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry Please don't put in my mouth words I haven't said. I haven't said that "System;Emulator" is not a valid option. I said that *in Fedora* all other emulators use "Game;Emulator;" therefore I said that it *should* be changed (because that is where the final user expects to find it).
(In reply to comment #21) > (In reply to comment #20) > > ok, i've fixed most of the problems Andrea pointed out in the last message, > > rpmlint now shows only 2 warnings which I think I have to keep, and I still > > dont see whats wrong with the release tag so far, I welcome any comments. > > * Dosemu 1.4.0 (1.4.0 is the version you declared) has already been released. > So the one you are packaging is a post-release snapshot version and it must > follow this guideline: > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Snapshot_packages > > Therefore 1868svn in the release tag is not acceptable. Release Tag for > Post-Release Snapshot Packages is %{X}.%{alphatag}. In this syntax, %{X} is > the release number increment and %{alphatag} is the checkout string. Well, the best I could do to figure what it should be was to look at other spec files and try to guess, so lets see if this is ok now. > * You are still not updating the changelog after each release. This is wrong. I > already told you. In this way we cannot read the history of the package. no, this is the first RPM so it would make no sense why I need to update the changelog at this point, all I have done is corrected the spec file to try and get it released in the first place. > * desktop-file-install \ > --vendor=fedora \ > --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \ > %{SOURCE2} > > You must not use a vendor. Please read: > https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor ok, removed. > * Categories=System;Emulator; > > The Categories in the desktop file should be changed to "Game;Emulator;". This > is what other emulators use. I didnt want this to be a game category because its not just a game emulator, its a dos emulator, but I have changed it anyways. > * Source: %{name}-%{version}.tgz > Source1: %{name}-freedos-bin.tgz > > Source is missing full URL (which is OK because this is a snapshot package) but > you are not following the guidelines on how to create the snapshot. > > Full URL for Source1 is missing. > > More info about both issues here: > https://fedoraproject.org/wiki/Packaging/SourceURL You told me before forget the source URL, you just wanted to know why I was packaging a SVN release, > * BuildRequires: binutils > > This is not required. This dependency is already pulled in by default. > > https://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 > > * BuildRequires: bison flex > > For constituency with other BR's, please split the above in two lines. Thats done now. > * You are still not following the guidelines about licensing. There are parts > that are not covered by the GPL. You must identify those parts and understand > under what licences they are. > > After that you must update the License tag accordingly. > > https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios I tried, from the information I have available. > * I cannot build the rpm ATM, but it seems to me that the following problems > where not addressed: > > - RPM_OPT_FLAGS are not used. I dont know of any opt flags needed, I remember going over all this stuff, and its not because I just dont know anything, > - Text files are not UTF-8. rpmlint only reported certain files needed to be converted, I dont know that I have to convert every file to UTF now. I've uploaded the updated files to the place listed above at fedorapeople.org, I fixed everything I could find, so in case there are still small errors, its not because I didnt bother to read the guidelines, its easy to see who wrote the docs knows everything about it.
(In reply to comment #24) > Justin? What's the status of this? Well, I fixed everything I could in the last few days, so we'll see how far it gets this time. The rpms work, i'm using them now. Thanks for the help.
Good work, I'm sure the reviewer will be much more happy about the package now :o) (In reply to comment #26) > no, this is the first RPM so it would make no sense why I need to update the > changelog at this point, all I have done is corrected the spec file to try and > get it released in the first place. Well, reviewers like to compare to the previous version of the package they were reviewing, and bumping Release and adding %changelog makes them happy :) > > * Categories=System;Emulator; > > > > The Categories in the desktop file should be changed to "Game;Emulator;". This > > is what other emulators use. > > > I didnt want this to be a game category because its not just a game emulator, > its a dos emulator, but I have changed it anyways. Please revert back, this is a violation of the Desktop Menu Specification. I'm sure this is minor enough not to bother you (see comment #24). > > - RPM_OPT_FLAGS are not used. > > > I dont know of any opt flags needed, I remember going over all this stuff, and > its not because I just dont know anything, Please have a look at the guidelines: https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags Just in case you missed anything else there, please make sure that you're familiar with the whole guidelines.
(In reply to comment #28) > > > * Categories=System;Emulator; > > > > > > The Categories in the desktop file should be changed to "Game;Emulator;". This > > > is what other emulators use. > > > > > > I didnt want this to be a game category because its not just a game emulator, > > its a dos emulator, but I have changed it anyways. > > Please revert back, this is a violation of the Desktop Menu Specification. I'm > sure this is minor enough not to bother you (see comment #24). Please do not say inaccurate things! Categories=Game;Emulator; is as legit as Categories=System;Emulator; http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry Additional Category Description Related Categories Emulator Emulator of another platform, such as a DOS emulator System or Game If you want to discuss this further, please let us move this particular discussion in the Fedora devel ML.
Taking this for official review. Justin: until I do it, please address the remaining Andrea's concerns (optflags) except for the Category=Game nonsense :) I'm reasonably satisfied with your packaging abilities, so am willing to sponsor you once you follow the existing practice and do preliminary reviews of some other packages. See comment #5. Thanks!
Reposting the URLS: SPEC: http://jzygmont.fedorapeople.org/dosemu.spec SRPM: http://jzygmont.fedorapeople.org/dosemu-1.4.0-1868svn.src.rpm Jason: Apart from bumping the Release number, it is a good practice to post new URLs each time you change a package, so the reviewer can easily find the latest packages.
I just tried out this RPM and I see the following issue: [warlord@pgpdev bootguard]$ dosemu -t "C:\\build.bat" /usr/bin/dosemu: relocation error: /usr/lib/dosemu/libplugin_term.so: symbol SLtt_get_terminfo, version SLANG2 not defined in file libslang.so.2 with link time reference [warlord@pgpdev bootguard]$ dosemu -t "C:\\build.bat" /usr/bin/dosemu: relocation error: /usr/lib/dosemu/libplugin_term.so: symbol SLtt_get_terminfo, version SLANG2 not defined in file libslang.so.2 with link time reference [warlord@pgpdev bootguard]$ dosemu -t "C:\\build.bat" [warlord@pgpdev bootguard]$ I'm not sure if this is a problem in dosemu or a problem in slang.
(In reply to comment #31) > > Jason: Apart from bumping the Release number, it is a good practice to post new > URLs each time you change a package, so the reviewer can easily find the latest > packages. ok, thanks. My apologies again for the delays, i'm a bit transient right now:) Andrea, do you happen to have an example of RPM_OPT flag? I cant find any reference how to use this, even from the kernel spec file.
(In reply to comment #32) > I just tried out this RPM and I see the following issue: > > [warlord@pgpdev bootguard]$ dosemu -t "C:\\build.bat" > /usr/bin/dosemu: relocation error: /usr/lib/dosemu/libplugin_term.so: symbol > SLtt_get_terminfo, version SLANG2 not defined in file libslang.so.2 with link > time reference > [warlord@pgpdev bootguard]$ dosemu -t "C:\\build.bat" > /usr/bin/dosemu: relocation error: /usr/lib/dosemu/libplugin_term.so: symbol > SLtt_get_terminfo, version SLANG2 not defined in file libslang.so.2 with link > time reference > [warlord@pgpdev bootguard]$ dosemu -t "C:\\build.bat" > > [warlord@pgpdev bootguard]$ > > > I'm not sure if this is a problem in dosemu or a problem in slang. Hi, thanks for testing this. I cannot duplicate this, can you verify your OS, updates? version of slang, etc..
OS: Fedora 10 Updates: updated as of a few days ago slang-2.1.4-1.fc10.i386 I can reproduce it using just: dosemu -t Using 'dosemu' (without the -t) does not exhibit this behavior.
(In reply to comment #33) > Andrea, do you happen to have an example of RPM_OPT flag? I cant find any > reference how to use this, even from the kernel spec file. Here you can find an introduction about CFLAGS: http://en.wikipedia.org/wiki/CFLAGS Fedora guidelines say that CFLAGS (or CXXFLAGS for C++ applications) must honor the applicable compiler flags set in the system rpm configuration. In practice, this means that $RPM_OPT_FLAGS or %{optflags} (they are the same) must be the basis of the CFLAGS/CXXFLAGS actually used by the compiler during the package build. You can see the value of this macro with: rpm --eval %{optflags} You can see in the build process if these flags are used or not (now they are not). Hope this helps.
(In reply to comment #35) > OS: Fedora 10 > Updates: updated as of a few days ago > slang-2.1.4-1.fc10.i386 > > I can reproduce it using just: dosemu -t > Using 'dosemu' (without the -t) does not exhibit this behavior. It looks like an issue with slang then. I tried it on my Fedora 10 system with no problems. However you may not need the -t option, I tend to use dosemu -s most of the time.
The -s and -t options are very different, so I'm not sure why you're suggesting I use one vs. the other: -s requires root, which I dont want to require -t tells dosemu not to open a window I'm not sure if it's a problem with slang or with dosemu, but dosemu is the only app I know of that uses slang and exhibits the problem.
(In reply to comment #38) > The -s and -t options are very different, so I'm not sure why you're suggesting > I use one vs. the other: > > -s requires root, which I dont want to require > -t tells dosemu not to open a window > > I'm not sure if it's a problem with slang or with dosemu, but dosemu is the > only app I know of that uses slang and exhibits the problem. -s allows certain features that need to access the hardware (ie. direct video i/o, etc) so its ok without it, but its the only option most people would ever need. I think -t can be omitted though, the dosemu script now determines the mode, console size, etc. Just let me know if this works ok for you..
The benefit of using -t is that it uses the current terminal instead of opening up a new window. This is especially useful for batch script processing and build systems where there might not be an X session in place. Yes, I do not see this problem when I remove the -t, but then dosemu opens up a new window which is not the behavior I want. I dont want a new window -- I want it to continue in the existing terminal where the dosemu command was run (in my case from a Makefile)
ya I see, are you sure there is any chance of a version conflict? I only have this 1 system to test it on, maybe an strace could give some clues. It doesnt appear to be a problem with dosemu though, I have the same versions of software you have.
Created attachment 336133 [details] strace output of failed "dosemu -t" This is the strace output from "dosemu -t" where the execution fails.
Created attachment 336134 [details] strace output of a successful "dosemu -t" This is an abbreviated strace output of a successful execution of "dosemu -t". I cut it off after 1000 lines in the theory that this is well beyond the failure as seen in the previous attachment. When I was looking at these traces I didn't notice anything truly amiss, but hopefully I overlooked something and it will make more sense to you.
Guys, please don't discuss the functional issues here, until the package is in Fedora. Once there will be a single official build of the package you'll agree on, then it will start to make sense to solve issues, not before then. It makes this review report a lot less legible for the reviewer, and it's increasingly hard to keep track of the packaging issues here. Derek, thank you for the participation though. When it comes to the compiler flags, I see them being properly used, since %configure macro sets them correctly. Probably past use of ./configure instead of %configure resulted into build w/o proper flags, but it all seems OK to me now. (Please be sure you understand it though). Justin, are there any examples of your work that could prove that you understand packaging well? Some informal reviews? I'll need to see it so that I can sponsor you. So here's first crack at the official review (sorry that it took so long): 1.) Source files Please comment on how did you get these: VCS checkout? Which revision? Source: %{name}-%{version}.tgz Full URL? Source1: %{name}-freedos-bin.tgz Original work? Source2: %{name}.desktop Isn't etc/dosemu.xpm from the source tarball sufficient? Source3: %{name}.xpm 2.) FreeDOS image I don't believe this is formally allowed (shipping binaries), though other packages do this (say, qemu includes bochs bios image). I'll ask on packaging list how to deal with this and let you know. It is also probably illegal (if it's GPL) to distribute this without source code, so at the very least, please add also the source code package and, as always, please comment as heavily as you can :) In case we won't be able to this -- do you know if it's very hard to build FreeDOS kernel image and cross-build the basic utilities (at least COMMAND.COM) with the tooling currently in Fedora? Source1: %{name}-freedos-bin.tgz 3.) Please use make flags. Please add %{_smp_mflags} after make, unless it breaks built. If it does, please add a comment instead. See: http://fedoraproject.org/wiki/Packaging/Guidelines#Parallel_make 4.) Legibility Please try not to cross 75 or 80 column boundary: chmod 755 $RPM_BUILD_ROOT%{_datadir}/dosemu $RPM_BUILD_ROOT%{_datadir}/dosemu/drive_z $RPM_BUILD_ROOT%{_datadir}/dosemu/drive_z/doc/exe2bin That is better written as: chmod 755 $RPM_BUILD_ROOT%{_datadir}/dosemu \ $RPM_BUILD_ROOT%{_datadir}/dosemu/drive_z \ $RPM_BUILD_ROOT%{_datadir}/dosemu/drive_z/doc/exe2bin 5.) Group RPMLint complains: dosemu.i586: W: non-standard-group Game/Emulator Indeed, this is not a standard group. Pick one from /usr/share/doc/rpm*/GROUPS. I believe the right one is "Applications/System". Hint: This is not used for anything, so does not matter at all. It can even be omitted since Fedora 10. 6.) .desktop entry Please set the back to Category=System;Emulator from Category=Game;Emulator, which is the only right value in this case. I believe we've have communicated this with Andrea via private mail back then.
7.) Summary Summary: DOS Emulator for linux There's no such thing as "linux" (with lowercase "l"). DOSEmu is not specific to Linux either. This would probably be better "DOS Emulator". Or something like "Environment to run DOS programs in" to be more friendly to a casual user. You decide.
(In reply to comment #44) > Guys, please don't discuss the functional issues here, until the package is in > Fedora. Once there will be a single official build of the package you'll agree > on, then it will start to make sense to solve issues, not before then. It makes > this review report a lot less legible for the reviewer, and it's increasingly > hard to keep track of the packaging issues here. Derek, thank you for the > participation though. ok, thanks for letting us know. > When it comes to the compiler flags, I see them being properly used, since > %configure macro sets them correctly. Probably past use of ./configure instead > of %configure resulted into build w/o proper flags, but it all seems OK to me > now. (Please be sure you understand it though). Thats good to know because I didnt see any place where opt_flags was used. > Justin, are there any examples of your work that could prove that you > understand packaging well? Some informal reviews? I'll need to see it so that > I can sponsor you. ok, I am about to do this, i'll let you know. > So here's first crack at the official review (sorry that it took so long): > > 1.) Source files > > Please comment on how did you get these: You mean comment where I got it in the spec file? > VCS checkout? Which revision? > Source: %{name}-%{version}.tgz > > Full URL? > Source1: %{name}-freedos-bin.tgz > > Original work? > Source2: %{name}.desktop > > Isn't etc/dosemu.xpm from the source tarball sufficient? > Source3: %{name}.xpm I think I got that idea from the dosbox spec file, I can change it if necessary. > 2.) FreeDOS image > > I don't believe this is formally allowed (shipping binaries), though other > packages do this (say, qemu includes bochs bios image). I'll ask on packaging > list how to deal with this and let you know. ok, I guess I overlooked it as shipping binaries because it was just a freedos image. I hope it will be ok. > It is also probably illegal (if it's GPL) to distribute this without source > code, so at the very least, please add also the source code package and, as > always, please comment as heavily as you can :) ok, I guess the source URL in the comments. > In case we won't be able to this -- do you know if it's very hard to build > FreeDOS kernel image and cross-build the basic utilities (at least COMMAND.COM) > with the tooling currently in Fedora? > > Source1: %{name}-freedos-bin.tgz hmm, I guess that would be the ideal way, but the freedos kernel image is trimmed and customized a bit, i'd hate to have to go down that route just for a replaceable image. At this point I dont know what it takes to build that. This .tgz file is not something thats available on the freedos site, for the source code, all they have is a large ISO image. > 3.) Please use make flags. > > Please add %{_smp_mflags} after make, unless it breaks built. If it does, > please add a comment instead. > > See: http://fedoraproject.org/wiki/Packaging/Guidelines#Parallel_make ok thanks. Done. > 4.) Legibility > > Please try not to cross 75 or 80 column boundary: > > chmod 755 $RPM_BUILD_ROOT%{_datadir}/dosemu > $RPM_BUILD_ROOT%{_datadir}/dosemu/drive_z > $RPM_BUILD_ROOT%{_datadir}/dosemu/drive_z/doc/exe2bin > > That is better written as: > > chmod 755 $RPM_BUILD_ROOT%{_datadir}/dosemu \ > $RPM_BUILD_ROOT%{_datadir}/dosemu/drive_z \ > $RPM_BUILD_ROOT%{_datadir}/dosemu/drive_z/doc/exe2bin All done. I just have a URL that is long, should I break that up too? > 5.) Group > > RPMLint complains: > > dosemu.i586: W: non-standard-group Game/Emulator > > Indeed, this is not a standard group. Pick one from /usr/share/doc/rpm*/GROUPS. > I believe the right one is "Applications/System". Hint: This is not used for > anything, so does not matter at all. It can even be omitted since Fedora 10. > > 6.) .desktop entry > > Please set the back to Category=System;Emulator from Category=Game;Emulator, > which is the only right value in this case. I believe we've have communicated > this with Andrea via private mail back then. Yes, thats done. I have also changed "linux" to Linux" :) The summary is accurate though, dosemu doesn't build on other platforms, there used to be a port to netbsd but that was a long time ago. I have uploaded the latest RPM packages and spec file here: http://jzygmont.fedorapeople.org/dosemu.spec
(In reply to comment #46) > > So here's first crack at the official review (sorry that it took so long): > > > > 1.) Source files > > > > Please comment on how did you get these: > > > You mean comment where I got it in the spec file? Exactly. Like: # Get revision 1234 from SVN: # svn co -r1234 http://repoistory-url@1234 dosbox # tar --exclude .svn -czf dosbox.tar.gz dosbox > > Isn't etc/dosemu.xpm from the source tarball sufficient? > > Source3: %{name}.xpm > > > I think I got that idea from the dosbox spec file, I can change it if > necessary. Yup. Just droop the Source3 and replace %{SOURCE3} with etc/dosemu.xpm > > 2.) FreeDOS image > > > > I don't believe this is formally allowed (shipping binaries), though other > > packages do this (say, qemu includes bochs bios image). I'll ask on packaging > > list how to deal with this and let you know. > > > ok, I guess I overlooked it as shipping binaries because it was just a freedos > image. I hope it will be ok. I guess so as well. I've just sent a message: https://www.redhat.com/archives/fedora-packaging/2009-March/msg00053.html > I have uploaded the latest RPM packages and spec file here: > http://jzygmont.fedorapeople.org/dosemu.spec Seems fine. Thanks for resolving those issues, let's do the rest (and... wait for the reply to the binary image issue).
One more issue. In the .desktop entry you say: Exec=dosemu -s which does not seem to make much sense (you'll probably notice why :). Please replace with Exec=xdosemu
Bad news :( Seems like FreeDOS can be built with Watcom C and Borland C Compiler only, both of which are non-free. Building with dev86's bcc is most likely not possible now. Do you think DOSEmu package would actually be usable without the FreeDOS image shipped? I'm wondering if you are in touch with upstream of either FreeDOS, or DOSEmu so that you could ask whether anyone's willing to help switching to free build framework (dev86) and whether there are any known technical difficulties with it? See the thread here: https://www.redhat.com/archives/fedora-packaging/2009-March/thread.html#00053
(In reply to comment #49) > Bad news :( > > Seems like FreeDOS can be built with Watcom C and Borland C Compiler only, both > of which are non-free. Building with dev86's bcc is most likely not possible > now. > > Do you think DOSEmu package would actually be usable without the FreeDOS image > shipped? > > I'm wondering if you are in touch with upstream of either FreeDOS, or DOSEmu so > that you could ask whether anyone's willing to help switching to free build > framework (dev86) and whether there are any known technical difficulties with > it? > > See the thread here: > https://www.redhat.com/archives/fedora-packaging/2009-March/thread.html#00053 I have followed up on this, it seems building with free tools is possible, but not now, and maybe not ever. Its a dam shame, does this mean its finished here? http://sourceforge.net/mailarchive/forum.php?thread_name=op.ura4quaez9dfrf%40isor&forum_name=freedos-devel http://sourceforge.net/mailarchive/forum.php?thread_name=ef6ac8350903231451p2e1e7091n3eebd87a34c456d5%40mail.gmail.com&forum_name=freedos-devel
Just because we cannot build freedos shouldn't imply we cannot distribute it. We /DO/ have the source code, and we can certainly distribute the source code (along with the pre-built binary). That's certainly legal as far as the GPL is concerned, even if we can't reliably reproduce the binary using our compiler of choice.
(In reply to comment #50) > (In reply to comment #49) > > Bad news :( > > > > Seems like FreeDOS can be built with Watcom C and Borland C Compiler only, both > > of which are non-free. Building with dev86's bcc is most likely not possible > > now. > > > > Do you think DOSEmu package would actually be usable without the FreeDOS image > > shipped? Is it? > I have followed up on this, it seems building with free tools is possible, but > not now, and maybe not ever. Its a dam shame, does this mean its finished > here? > > > http://sourceforge.net/mailarchive/forum.php?thread_name=op.ura4quaez9dfrf%40isor&forum_name=freedos-devel > > http://sourceforge.net/mailarchive/forum.php?thread_name=ef6ac8350903231451p2e1e7091n3eebd87a34c456d5%40mail.gmail.com&forum_name=freedos-devel That's pretty bad. On packaging list it was suggested [2] that you join forces with Debian, which also ships pre-built binary, and try to convince them to switch to dev86's bcc. It brings an advantage of being distributed with quite popular Linux distribution. [2] https://www.redhat.com/archives/fedora-packaging/2009-March/msg00065.html (In reply to comment #51) > Just because we cannot build freedos shouldn't imply we cannot distribute it. > We /DO/ have the source code, and we can certainly distribute the source code > (along with the pre-built binary). That's certainly legal as far as the GPL is > concerned, even if we can't reliably reproduce the binary using our compiler of > choice. Derek we're not saying it's illegal. It just doesn't grant the user the freedom to modify the program to suit his needs. See the thread on packaging list for discussion on this [1]: [1] https://www.redhat.com/archives/fedora-packaging/2009-March/msg00056.html
Lubomir, I read the thread. My take on it was exactly what you said, "it just doesn't grant the user the freedom to modify the program to suit his needs." My take as a user of the program is that I'd much rather see the package in the distribution. I just don't care about the freedos portion, as honestly that's not the part that I would feel I need to modify to "suit my needs." And even so, the code is there if I want to see it, even if I can't compile it. If debian is willing to ship it as-is Fedora should most certainly be willing to. While I agree that long-term it would be BETTER to get the code compiling using the Fedora build tools, I think it would behoove users to have access to the program as-is sooner, rather that block distribution waiting on this. To quote many people from the IETF: The Perfect is the enemy of The Good. Just my $0.02.
(In reply to comment #53) > If debian is willing to ship it as-is Fedora should most certainly be willing > to. Debian does not set Fedora policy. The relevant Fedora policy is, I believe, clearly indicated here: http://fedoraproject.org/wiki/Packaging/Guidelines#No_inclusion_of_pre-built_binaries_or_libraries Note that there are exceptions listed to that policy. I don't believe that an argument towards having this accepted as firmware would succeed, honestly. I also don't believe this falls under the exceptions relating to cross-compilation environments. If you believe this package deserves an additional exception, you are welcome to bring the matter before the Packaging Committee. The next meeting is Tuesday, March 31 at 17:00UTC.
(In reply to comment #53) Daniel, this is not just about "Perfect" vs. "Good", this is a matter of "Free" vs. "Non-free". See, if the only precondition for including the software in Fedora would be usability, we'd almost certainly ship non-free nvidia drivers and the such. Being strict about freedom to modify the software is among the important things that makes Fedora special, compared to, say, Ubuntu (which coincidentally goes as far, as shipping binary-only drivers). Now, to be constructive, the effort to get this packaged is definitely not lost. It can be included in RPMFusion repository [1]. I'm willing to review it there, and provide any kind of help that's needed. [1] http://rpmfusion.org/
(In reply to comment #55) > (In reply to comment #53) > Daniel, > > this is not just about "Perfect" vs. "Good", this is a matter of "Free" vs. > "Non-free". See, if the only precondition for including the software in Fedora > would be usability, we'd almost certainly ship non-free nvidia drivers and the > such. Being strict about freedom to modify the software is among the important > things that makes Fedora special, compared to, say, Ubuntu (which > coincidentally goes as far, as shipping binary-only drivers). > > Now, to be constructive, the effort to get this packaged is definitely not > lost. It can be included in RPMFusion repository [1]. I'm willing to review it > there, and provide any kind of help that's needed. > > [1] http://rpmfusion.org/ ya, I guess it would make sense then. Do you know how much is involved to get it into rpmfusion? Because I cant see anyone using dosemu without an included DOS image to boot up with, it would be useless.
(In reply to comment #56) > ya, I guess it would make sense then. Do you know how much is involved to get > it into rpmfusion? Because I cant see anyone using dosemu without an included > DOS image to boot up with, it would be useless. The procedure to join RPMFusion is quite similar to one of Fedora. You need to get sponsored, and convince someone to sponsor you by doing a couple of informal reviews (in either Fedora or RPMFusion). http://rpmfusion.org/Contributors
Sooo... what's happening here? Justin: are you willing to import this into RPMFusion? I'll happily continue the review there.
hi, I got the bug (478) in rpmfusion now, here is the link: https://bugzilla.rpmfusion.org/show_bug.cgi?id=478
Closing, since this continues in RPM Fusion.