Spec URL: http://repo.calcforge.org/f9/okteta.spec SRPM URL: http://repo.calcforge.org/f9/okteta-0.0.1-0.1.20080102svn755662.fc8.src.rpm Description: This is the replacement for khexedit, which has been dropped from kdeutils for the KDE 4.0 release. The RPM %description follows: Okteta allows the user to load data from any file, view and edit it in either hex or ASCII. Okteta uses the KDE 4 libraries. I tested the package on F8 i386 and it starts up fine and loads all the files I tried correctly. Packaging note: I am not packaging the oktetapart because it conflicts with the version in kdeutils (kdeutils 4.0 only contains the KPart, not the full application, which is scheduled to be merged in 4.1) and because the application doesn't actually use the KPart, only the common libraries.
Hmmm, it looks like kdeutils-4.0.0 contains some oktetapart sources, but the directory is missing a CMakeLists.txt and thus not actually being built. I guess I'll just reenable the oktetapart in this package, it's newer anyway.
Could you list the requirements for testing this on F8? I've only seen KDE4 packages for Rawhide so far, and when I tried installing kdebase from Rawhide it's pulling too many updates that I don't feel comfortable installing on my main machine.
Build-time: kdelibs4-devel Run-time: kdelibs4, kdebase-runtime (It may sort-of run without kdebase-runtime, but it'll definitely be missing icons and such, so installing kdebase-runtime is recommended.) These can be found in F8 updates (currently the old 3.96.2 version) or updates-testing (4.0.0).
rpmlint complains about library files that are not ldconfig-ed, though it does not seem to affect the package's running. $ rpmlint ../RPMS/okteta-0.0.1-0.1.20080102svn755662.fc8.x86_64.rpm okteta.x86_64: W: no-documentation okteta.x86_64: E: library-without-ldconfig-postin /usr/lib64/liboktetacore_b.so.4.0.0 okteta.x86_64: E: library-without-ldconfig-postun /usr/lib64/liboktetacore_b.so.4.0.0 okteta.x86_64: E: library-without-ldconfig-postin /usr/lib64/liboktetagui_b.so.4.0.0 okteta.x86_64: E: library-without-ldconfig-postun /usr/lib64/liboktetagui_b.so.4.0.0
Oops, good catch.
Note that it would be nice to test this with package_kpart set back to 1 as this will probably be how it'll end up when actually imported (see comment #1). (I can respin a new SRPM if needed.)
Updated: Spec URL: http://repo.calcforge.org/f9/okteta.spec SRPM URL: http://repo.calcforge.org/f9/okteta-0.0.1-0.1.20080115svn761510.fc8.src.rpm - Update to revision 761510 - Enable package_kpart - Add missing ldconfig scriptlets for the shared libraries The only rpmlint complaint left is the no-documentation one which is basically upstream's fault for not including a COPYING file.
Almost done -- one question about desktop-file-utils, and another about macros. Also, on a system without KDE4 installed, the application menu does not show any icon (khexedit icon is not on the system), and the application itself does not have any icons (presumably because oxygen theme is not installed). MUST Passed: • rpmlint • package name • spec file name • package guideline-compliant • license complies with guidelines • license field accurate • license file not deleted • spec in US English • spec legible • source matches upstream • builds under >= 1 archs, others excluded • build dependencies complete • locales handled using %find_lang, no %{_datadir}/locale • library -> ldconfig • own all directories • no dupes in %files • permission • %clean RPM_BUILD_ROOT • Package contains code • clean buildroot before install • filenames UTF-8 N/A: • large docs => -doc • doc not runtime dependent • headers in -devel • static in -static • if contains *.pc, req pkgconfig • if libfiles are suffixed, the non-suffixed goes to devel • devel requires versioned base package Unknown: • macros used consistently Question: are those _kde4_* macros going to be present for the foreseeable future? FAILED: • desktop file uses desktop-file-install
The _kde4_* macros will be present forever, they allow us to define e.g. _kde4_includedir to %{_includedir}/kde4. For desktop-file-install, unfortunately KDE has always had its own ways of installing .desktop files, we'd have to reinstall the already installed one. :-( It will also lead to the .desktop file landing in a different place as upstream (they use kde4/*.desktop rather than kde4-*.desktop as you get with desktop-file-install --vendor).
Actually it turns out it's easy to run desktop-file-install on the installed .desktop file to validate it (thanks to Rex Dieter for clearing that up). This does the trick: desktop-file-install %{buildroot}%{_datadir}/applications/kde4/okteta.desktop --vendor "" --dir %{buildroot}%{_datadir}/applications/kde4 So I'm fixing this.
Updated: Spec URL: http://repo.calcforge.org/f9/okteta.spec SRPM URL: http://repo.calcforge.org/f9/okteta-0.0.1-0.2.20080115svn761510.fc8.src.rpm - Use desktop-file-install to ensure the .desktop file is valid
Changes look fine - APPROVED
New Package CVS Request ======================= Package Name: okteta Short Description: Binary editor Owners: kkofler,than,rdieter,ltinkl Branches: InitialCC: Cvsextras Commits: no
cvs done.
This is meant for F9 and above only, presumably? In which case I am closing the bug entry -- package has hit Rawhide.
Right, for one older releases have KHexEdit and secondly Okteta isn't fully ready yet, hopefully it will get the missing features (like undo/redo) in time for F9.