Spec URL: http://ajax.fedorapeople.org/partiwm/partiwm.spec SRPM URL: http://ajax.fedorapeople.org/partiwm/partiwm-0.0.6-1.20101109.fc13.src.rpm Description: The partiwm package provides: - a python library, wimpiggy, for writing compositing window managers - a partitioning window manager using wimpiggy - a "screen for X" implementation using wimpiggy
I'll take this (was working on it myself).
Package Review ============== Key: - = N/A x = Check ! = Problem ? = Not evaluated === REQUIRED ITEMS === [x] Package is named according to the Package Naming Guidelines. [1] [x] Spec file name must match the base package %{name}, in the format %{name}.spec. [x] Spec file is legible and written in American English. [x] Spec file lacks Packager, Vendor, PreReq tags. [x] Spec uses macros instead of hard-coded directory names. [x] Package consistently uses macros. [x] Macros in Summary, %description expandable at SRPM build time. [x] PreReq is not used. [x] Requires correct, justified where necessary. [x] All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [2] [x] Package run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) and the beginning of %install. [-] Package use %makeinstall only when ``make install DESTDIR=...'' doesn't work. [x] Package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). [-] The spec file handles locales properly. [x] Changelog in prescribed format. [!] Rpmlint output is silent. % lintmock fedora-14-x86_64-bb partiwm.src: W: spelling-error %description -l en_US Parti -> Patti, Marti, Parch partiwm.src:54: W: rpm-buildroot-usage %build rm -rf $RPM_BUILD_ROOT build install partiwm.src: W: no-buildroot-tag partiwm.src:16: W: mixed-use-of-spaces-and-tabs (spaces: line 16, tab: line 4) partiwm.src: W: invalid-url Source0: partiwm-20101109.tar.bz2 partiwm.x86_64: W: spelling-error %description -l en_US Parti -> Patti, Marti, Parch partiwm.x86_64: W: incoherent-version-in-changelog 0.0.6-0.1.20101109 ['0.0.6-1.20101109.fc14', '0.0.6-1.20101109'] partiwm.x86_64: E: no-binary partiwm.x86_64: W: no-manual-page-for-binary parti-repl partiwm.x86_64: W: no-manual-page-for-binary parti wimpiggy.x86_64: W: spelling-error Summary(en_US) compositing -> composting, com positing, com-positing wimpiggy.x86_64: W: spelling-error %description -l en_US compositing -> composting, com positing, com-positing wimpiggy.x86_64: W: private-shared-object-provides /usr/lib64/python2.7/site-packages/wimpiggy/lowlevel/bindings.so bindings.so()(64bit) wimpiggy.x86_64: E: non-standard-executable-perm /usr/lib64/python2.7/site-packages/wimpiggy/lowlevel/bindings.so 0775L xpra.x86_64: W: private-shared-object-provides /usr/lib64/python2.7/site-packages/xpra/wait_for_x_server.so wait_for_x_server.so()(64bit) xpra.x86_64: E: non-standard-executable-perm /usr/lib64/python2.7/site-packages/xpra/wait_for_x_server.so 0775L 5 packages and 0 specfiles checked; 3 errors, 13 warnings. The tab/spaces should be cleaned up. The Release: needs to be pre-release versioned (%changelog is correct). Not sure why the %build section is removing the (non-existent) build and install directories. [x] License field in the package spec file matches the actual license. Pedantry: GPLv2+. [x] If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. [x] License file installed when any subpackage combination is installed. [x] Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [3,4] [x] Sources contain only permissible code or content. [!] Sources used to build the package matches the upstream source, as provided in the spec URL. MD5SUM this package : MD5SUM upstream package : What revision was the snapshot of? Please use %{hgdate}hg%{hgrev} for the Release tag. [x] Compiler flags are appropriate. [x] %build honors applicable compiler flags or justifies otherwise. [-] ldconfig called in %post and %postun if required. [x] Package must own all directories that it creates. I usually put a trailing '/' after directories to explicitly mark them as directories for others' sake. [!] Package does not own files or directories owned by other packages. Should %{python_sitearch} be owned by partiwm? Other arch-ed python packages don't. [x] Package requires other packages for directories it uses. [x] Package does not contain duplicates in %files. [x] Permissions on files are set properly. [x] Each %files section contains %defattr. [x] No %config files under /usr. [x] %config files are marked noreplace or the reason is justified. [x] Package contains a properly installed %{name}.desktop using desktop-file-install file if it is a GUI application. [5] Waived as window managers don't really get started in this fashion. Does it get added to gdm/kdm's menus? [x] Package contains a valid .desktop file. [x] Package contains code, or permissable content. [-] Package contains a SysV-style init script if in need of one. [x] File names are valid UTF-8. [x] Large documentation files are in a -doc subpackage, if required. [x] Package uses nothing in %doc for runtime. [x] Package contains no bundled libraries. [-] Header files in -devel subpackage, if present. [-] Static libraries in -static subpackage, if present. [-] Package contains no static executables. [-] Package requires pkgconfig, if .pc files are present. [-] Development .so files in -devel subpackage, if present. [x] Fully versioned dependency in subpackages, if present. [x] Package does not contain any libtool archives (.la). [-] Useful -debuginfo package or justification otherwise. [-] Rpath absent or only used for internal libs. [x] Package does not genrate any conflict. [x] Package does not contains kernel modules. [x] Package is not relocatable. [x] Package successfully compiles and builds into binary rpms on at least one supported architecture. [x] Package is not known to require ExcludeArch. [x] Package installs properly. [x] Package obeys FHS, except libexecdir and /usr/target. [x] Package meets the Packaging Guidelines. [6] === SUGGESTED ITEMS === [-] Package functions as described. [x] Latest version is packaged. [x] Package does not include license text files separate from upstream. [-] If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [-] Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [!] SourceX is a working URL. Snapshot. See md5sum entry above to allow the specific revision to be recreated. [x] SourceX / PatchY prefixed with %{name}. [x] Final provides and requires are sane (rpm -q --provides and rpm -q --requires). [-] %check is present and all tests pass. [-] Usually, subpackages other than devel should require the base package using a fully versioned dependency. [x] Reviewer should test that the package builds in mock. [ ] Package should compile and build into binary rpms on all supported architectures. [x] Dist tag is present. [!] Spec use %global instead of %define. hgdate is using %define. [-] Scriptlets must be sane, if used. [-] The placement of pkgconfig(.pc) files are correct. [-] No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x] Packages should try to preserve timestamps of original installed files. [-] File based requires are sane. [!] Man pages included for all executables. Upstream should be contacted. [x] Uses parallel make. [x] Patches link to upstream bugs/comments/lists or are otherwise justified. I didn't need the card32 patch for my attempt, but I was using the 0.0.6 release tarball, not a snapshot. (Copied from above for convenience) === Issues === 1. The tab/spaces should be cleaned up 2. The Release: needs to be pre-release versioned (%changelog is correct) 3. Not sure why the %build section is removing the (non-existent) build and install directories 4. What revision was the snapshot of? Please use %{hgdate}hg%{hgrev} for the Release tag 5. Should %{python_sitearch} be owned by partiwm? Other arch-ed python packages don't 6. Waived as window managers don't really get started in this fashion. Does it get added to gdm/kdm's menus? 7. hgdate is using %define where %global should be used === Final Notes === 1. NEWS should be shipped 2. Pedantry: GPLv2+ 3. I usually put a trailing '/' after directories to explicitly mark them as directories for others' sake [1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines [2] https://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 [3] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines [4] https://fedoraproject.org/wiki/Licensing:Main [5] https://fedoraproject.org/wiki/Packaging:Guidelines#Desktop_files [6] https://fedoraproject.org/wiki/Packaging:Guidelines
*** Bug 514068 has been marked as a duplicate of this bug. ***
Ping?
Any action on this? Would love to see this package ship.
I've updated the spec file per https://bugzilla.redhat.com/show_bug.cgi?id=651591#c2 (I'm not an expert though) and rebuilt the packages: SPEC URL: http://www.martindengler.com/proj/partiwm/partiwm.spec SRPM URL: http://www.martindengler.com/proj/partiwm/partiwm-0.0.6-2.fc14.src.rpm RPMS: http://www.martindengler.com/proj/partiwm/ Not an expert on koji but the scratch builds succeeded, so that's good: http://koji.fedoraproject.org/koji/taskinfo?taskID=3030582 I haven't actually tested the RPMs yet...
I found some later versions on winswitch.org and built them using ajax's spec file with the aforementioned modifications, too: http://www.martindengler.com/proj/partiwm/ which has had the side effect of invalidating the SPEC file link from before. The SRPMS are still available of course.
Clearing NEEDINFO
Ping? @Martin: If no response by next week, want to open another review (marking this as a duplicate)?
Sure
Sorry, but it is xpra included there is also it separate project http://code.google.com/p/partiwm/wiki/xpra ? Or not?
(In reply to comment #11) > Sorry, but it is xpra included there is also it separate project > http://code.google.com/p/partiwm/wiki/xpra ? Or not? xpra is included, in the sense that when one builds rpms from "partiwm.spec", xpra rpms are built too: http://www.martindengler.com/proj/partiwm/
If it the same external project how it may be bundled? It is violate our guidelines.
parti + xpra + wimpiggy are one upstream project. The restriction on bundling does not apply.
Why? If i right understand http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries it does not mention it in exceptions. At least there may be use case of usage it without other stuff of that big package.
Since the project is responsible for all of the libraries and executables in the tarball, things are fine. With subpackages, users can use xpra without parti or wimpiggy (assuming the code allows it). The problem arises when a project includes code that it needs but is not the canonical source for that code (say...this project shipping python-jsonpickle). That is not allowed since the actual python-jsonpickle code could diverge and has security implications.
Is there any progress??
I guess this one should be closed and a new review (possibly also a new spec) started from scratch - the upstream is dead, and there is active fork at http://xpra.org/ I'd like to give the new xpra a try, especially as the fork claims "non-US keyboard layout support" which is a blocker for me with 0.0.6, but I do not feel like becoming maintainer of this ... is there anyone interested enough? - seems like I'm not the only one with such approach :-/
I glad to hear it! I also interesting in it and ready to packaging from new upstream. Adam, do you willing continue, or I may take xpra and close this as duplicate.
?
one more thing, I haven't noticed before - the new fork already provides packages for Fedora (and it works ;-)), so maybe it'd be best to convince them to maintain these oficially in Fedora repos, or at least offer to act as proxy for them if none of the developers wants to become Fedora packager
The new fork may provide packages for fedora, but they are really really badly done. AFAICT you have to be root to build them as they try to install stuff in /usr during the build process. creating build/scripts-2.7 copying and adjusting scripts/parti -> build/scripts-2.7 copying and adjusting scripts/parti-repl -> build/scripts-2.7 copying and adjusting scripts/xpra -> build/scripts-2.7 changing mode of build/scripts-2.7/parti from 644 to 755 changing mode of build/scripts-2.7/parti-repl from 644 to 755 changing mode of build/scripts-2.7/xpra from 644 to 755 running install_lib creating /usr/lib64/python2.7/site-packages/parti error: could not create '/usr/lib64/python2.7/site-packages/parti': Permission denied error: Bad exit status from /var/tmp/rpm-tmp.nokf0R (%build)
Created attachment 562352 [details] Updated spec file I updated spec file to work for latest xpra version. Haven't done rpm dev for 10 years so probably a little rough.
Created attachment 562366 [details] partiwm spec - added Xvfb requires I realized that xorg-x11-server-Xvfb is required at runtime. Tested this with sharing firefox across two machines. worked with no problems. This works with xpra / partiwm 0.0.7.36
(In reply to comment #23) > I updated spec file to work for latest xpra version. Haven't done rpm dev for > 10 years so probably a little rough. time to start again :-) would you be willing to maintain this package? - if yes, please file a new review request ... seems Martin also lost interest in this :-( two notes - * the new upstream calls the bundle "xpra", so you may want to rename the spec file to xpra instead of partiwm * each version/release increment needs a changelog entry
(In reply to comment #25) > seems Martin also lost interest in this :-( Sorry, got distracted :(
Created attachment 575816 [details] Updated SPEC file * Fri Apr 06 2012 Joel Young <jdy> 0.1.0.1-3 - update to released version 0.1.0.1 - added requires for xorg-x11-server-Xvfb - renamed package to xpra rather than partwm Any progress on continuing the review for this project?
Open up a new RR bug (the name and summary are wrong for this bug and it'd be better if whoever will be the maintainer is the one who opened the bug). I can review it (I'm sure I'll have something to trade).
Martin, will you be doing resubmitting this?
(In reply to comment #29) > Martin, will you be doing resubmitting this? considering there's no response ... please, would you open a new review request? I'm using xpra daily so I'd like to see it properly packaged in Fedora
*** This bug has been marked as a duplicate of bug 928609 ***