Bug 519521
| Summary: | Review Request: kompozer - Web Authoring System | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ismael Olea <ismael> |
| Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
| Status: | CLOSED DEFERRED | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | alekcejk, benjavalero, fedora-package-review, gracca, notting, orion, pablomg+fedora, thomas.canniot |
| 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: | 2011-04-25 09:16:13 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: | |||
|
Description
Ismael Olea
2009-08-26 22:34:07 UTC
$ rpmlint -iv fedora-10/kompozer-0.8a4-3.fc10.i386.rpm kompozer.i386: I: checking kompozer.i386: W: dangling-symlink /usr/lib/kompozer/dictionaries /usr/share/myspell The target of the symbolic link does not exist within this package or its file based dependencies. Verify spelling of the link target and that the target is included in a package in this package's dependency chain. 1 packages and 0 specfiles checked; 0 errors, 1 warnings. (BTW if the provided links doesn't work wait a bit to let the server finish sync) Updated files ready to be reviewed: Spec URL: http://olea.org/tmp/kompozer.spec SRPM URL: http://olea.org/paquetes-rpm/fedora-10/kompozer-0.8a4-4.olea.src.rpm A few comments, as I wait for this to build: Parallel make would really be nice. Is it not working? I note the firefox spec has some bizarre code to conditionally use a limited parallel make. The version does not seem correct. If upstream releases 0.8 (as their web pages indicate that they will) then you will need to use an epoch as 0.8 is less than 0.8a4. The proper way to do this is explained in http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages: kompozer-0.8-0.1.a4 Then you can increment the '1' when you revise the package, changing the "a4" as necessary if upstream releases another alpha, beta, gamma, whatever version, without worrying about whether their suffix sorts. Then when 0.8 is actually released, you can use komopzer-0.8-1 Unfortunately the package has failed to build for me, in mock, on x86_64 rawhide: c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O -fPIC -shared -Wl,-z,defs -Wl,-h,libpipnss.so -o libpipnss.so md4.o nsClientAuthRemember.o nsPSMBackgroundThread.o nsSSLThread.o nsCertVerificationThread.o nsCipherInfo.o nsNSSCallbacks.o nsNSSComponent.o nsNSSIOLayer.o nsNSSModule.o nsSSLSocketProvider.o nsTLSSocketProvider.o nsSDR.o nsPK11TokenDB.o nsNSSCertificate.o nsPKCS12Blob.o nsNSSASN1Object.o nsKeygenHandler.o nsCrypto.o nsPKCS11Slot.o nsKeygenThread.o nsCMSSecureMessage.o nsCMS.o nsCertPicker.o nsCRLInfo.o nsNSSCertCache.o nsNSSCertHelper.o nsNSSCertificateDB.o nsNSSCertTrust.o nsNSSCertValidity.o nsOCSPResponder.o nsUsageArrayHelper.o nsCRLManager.o nsNSSShutDown.o nsNTLMAuthModule.o nsNSSEvent.o nsSmartCardMonitor.o nsSmartCardEvent.o nsStreamCipher.o nsKeyModule.o nsCertTree.o ../../../../dist/lib/libunicharutil_s.a -L../../../../dist/bin -lxpcom -lxpcom_core -L../../../../dist/bin -L/usr/lib64 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -L../../../../dist/bin -lmozjs -Wl,/usr/lib64 -L/usr/lib64 -lssl3 -lsmime3 -lnss3 -lcrmf -Wl,--version-script -Wl,/builddir/build/BUILD/kompozer-0.8a4/mozilla/build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic -ldl -lm gmake[5]: Leaving directory `/builddir/build/BUILD/kompozer-0.8a4/obj-kompozer/security/manager/ssl/src' gmake[4]: Leaving directory `/builddir/build/BUILD/kompozer-0.8a4/obj-kompozer/security/manager/ssl' gmake[3]: Leaving directory `/builddir/build/BUILD/kompozer-0.8a4/obj-kompozer/security/manager' gmake[2]: Leaving directory `/builddir/build/BUILD/kompozer-0.8a4/obj-kompozer' make[1]: Leaving directory `/builddir/build/BUILD/kompozer-0.8a4/obj-kompozer' RPM build errors: /usr/lib64: file not recognized: Is a directory collect2: ld returned 1 exit status I'm afraid I do not completely understand what's gone wrong. I think it's the "-Wl,/usr/lib64" there, as that passes /usr/lib64 directly to ld and I don't think there's any reason to pass a directory name without an option flag to ld. (In reply to comment #3) > A few comments, as I wait for this to build: > > Parallel make would really be nice. Is it not working? I note the firefox > spec has some bizarre code to conditionally use a limited parallel make. I've just tried with the parallel flag and it didn't liked. For writing this spec I've based on the seamonkey one, which seems a bit outdated, BTW. > The version does not seem correct. If upstream releases 0.8 (as their web > pages indicate that they will) then you will need to use an epoch as 0.8 is > less than 0.8a4. The proper way to do this is explained in > http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages: > kompozer-0.8-0.1.a4 Fine! Done. > Unfortunately the package has failed to build for me, in mock, on x86_64 > rawhide: > [...] > > I'm afraid I do not completely understand what's gone wrong. I think it's the > "-Wl,/usr/lib64" there, as that passes /usr/lib64 directly to ld and I don't > think there's any reason to pass a directory name without an option flag to ld. I've tried to add x64 support asked by a user but my system is x32 so is hard to detect troubles like this :-/ The updated spec: http://olea.org/tmp/kompozer.spec It shouldn't be hard to detect build failures on x86_64 systems; you have access to the build system so you can do all the builds you like. There's also http://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers You should also supply an updated srpm so that reviewers can build your package. Ok. Now builds on x86_64[1] too. The updated spec: http://olea.org/tmp/kompozer.spec SRPM: http://koji.fedoraproject.org/koji/getfile?taskID=1718380&name=kompozer-0.8-0.1.a4.fc11.src.rpm [1] http://koji.fedoraproject.org/koji/getfile?taskID=1718380&name=kompozer-0.8-0.1.a4.fc11.x86_64.rpm b1 release: The updated spec: http://olea.org/tmp/kompozer.spec SRPM: http://olea.org/paquetes-rpm/fedora-11/kompozer-0.8-0.2.b1.fc11.src.rpm OK, this does build for me. I'm not really ready to review this; it will probably take work my more than one person. But I do have some comments:
Source0: should be a URL, so that spectool -g will work if possible. I don't suppose there's a URL for the manpage, but if there is then you should inclide that as well.
I'm not sure what the nvu-related Provides: and Obsoletes: is about; is nvu available in any Fedora repository currently?
You have Requires(pre): desktop-file-utils, but no %pre scriptlet at all. Similarly, you call update-desktop-database and ldconfig in %post and %postun, but have no dependencies for them.
This provides a whole lot of libraries that are also provided by xulrunner. I think this is a significant problem. Seamonkey manages to avoid this by turning off the dependency generator and managing some of the dependency generation itself. I can't really offer any suggestions on how to do it properly, though I'd bet the firefox/xulrunner/seamonkey maintainers (all the same people) would have some suggestions.
The correct set of Fedora compiler flags are not used, and the debuginfo package seems to be broken. These are related. You will need to get the propler set of compiler flags (from %{optflags}) passed to the compiler. Seamonkey seems to do this properly.
The biggest issue I see, however, is that this is basically yet another forked mozilla. Distributing a forked copy of something that's updated with security issues once a week isn't something we should go about lightly; I'd want to see discussion with the firefox/xulrunner maintainers and probably FESCo as well (the latter due to the requirements of the no-bundled-libraries policy).
Language packs http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b1/ could be added in rpm? Ismael are you still interested in this package? Please update to version 0.8b3, this package is interesting. Regards, German. Excuse me all. I'm in a new job which keeps me really busy. Anyhow I advanced the 0.8b3 release but didn't announced here. My plan would be to include l10n packs inside the package. It's needed to test if it's really working. I'll look for time but I can't promise anything. Current release (uploading to server): http://olea.org/paquetes-rpm/fedora-13/kompozer-0.8-0.4.b3.fc13.src.rpm http://olea.org/tmp/kompozer.spec (In reply to comment #8) > Source0: should be a URL, so that spectool -g will work if possible. Well, this is a sourceforge URI. Attending to http://fedoraproject.org/wiki/Packaging/SourceURL#Sourceforge.net the URI supposed to be http://downloads.sourceforge.net/projects/kompozer/kompozer-0.8b3-src.tar.bz2 but it don't works. Instead, the one SF generates is http://sourceforge.net/projects/kompozer/files/current/0.8b3/kompozer-0.8b3-src.tar.bz2/download which confuses rpmbuild (it believes the file is named «download». > I don't > suppose there's a URL for the manpage, but if there is then you should inclide > that as well. I added the URL to the git web frontend to it. > I'm not sure what the nvu-related Provides: and Obsoletes: is about; is nvu > available in any Fedora repository currently? No as far as I know. But you know: Kompozer is obsoleting it... > You have Requires(pre): desktop-file-utils, but no %pre scriptlet at all. > Similarly, you call update-desktop-database and ldconfig in %post and %postun, > but have no dependencies for them. Ok: I added the post and postun and removed the pre. I didn't added glibc (for ldconfig) as a Requires(post) since feel is extremelly redundant. Hope I'm right. > This provides a whole lot of libraries that are also provided by xulrunner. I > think this is a significant problem. Seamonkey manages to avoid this by > turning off the dependency generator and managing some of the dependency > generation itself. I can't really offer any suggestions on how to do it > properly, though I'd bet the firefox/xulrunner/seamonkey maintainers (all the > same people) would have some suggestions. I'll wait for it. I recognize Mozilla/Kompozer's makefile is a little hell to manage. > The correct set of Fedora compiler flags are not used, and the debuginfo > package seems to be broken. These are related. You will need to get the > propler set of compiler flags (from %{optflags}) passed to the compiler. > Seamonkey seems to do this properly. > > The biggest issue I see, however, is that this is basically yet another forked > mozilla. Distributing a forked copy of something that's updated with security > issues once a week isn't something we should go about lightly; I'd want to see > discussion with the firefox/xulrunner maintainers and probably FESCo as well > (the latter due to the requirements of the no-bundled-libraries policy). I see your point for these thing. Again: Kompozer makefiles are a beast that barely upstream can control. Maybe an experienced maintainer of Seamonkey or similars would better guide us. I would be more than glad for enhancing the compiling scripts. The same applies with the duplicated code from Mozilla: upstream didn't be able to optimize it, or maybe they couldn't get the time for it. And I currently don't have neither time or skills for it. Obviously the best thing I can say about Kompozer in it's current presentation is it's the best and only app available in its class AFAIK :-) Suggestions are welcome! Current release (uploading to server): http://olea.org/paquetes-rpm/fedora-13/kompozer-0.8-0.5.b3.fc13.src.rpm http://olea.org/tmp/kompozer.spec Source0 should be: Source0: http://downloads.sourceforge.net/kompozer/current/0.8b3/%{name}-%{upstream_version}-src.tar.bz2 Also, langpacks appear to have moved: Source2: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.ca.xpi Source3: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.cs.xpi Source4: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.da.xpi Source5: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.de.xpi Source6: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.en-US.xpi Source7: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.eo.xpi Source8: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.es-ES.xpi Source9: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.fi.xpi Source10: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.fr.xpi Source11: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.hu.xpi Source12: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.hsb.xpi Source13: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.it.xpi Source14: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.ja.xpi Source15: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.ko.xpi Source16: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.nl.xpi Source17: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.pl.xpi Source18: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.pt-BR.xpi Source19: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.pt-PT.xpi Source20: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.ru.xpi Source21: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.sl.xpi Source22: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.uk.xpi Source23: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.zh-CN.xpi Source24: http://kompozer.sourceforge.net/l10n/langpacks/kompozer-0.8b3/kompozer-0.8b3.zh-TW.xpi I retire this request. |