Spec URL: http://mnowak.fedorapeople.org/awesome/awesome.spec SRPM URL: http://mnowak.fedorapeople.org/awesome/awesome-2.3.1-1.fc9.src.rpm Description: Windows can be managed in several layouts: tiled, maximized, dwindle, spiral, floating. Each layout can be applied on-the-fly, optimizing the environment for the application in use and the task performed. Managing windows in tiled mode assures that no space will be wasted on the screen. No gaps, no overlap. Other layouts can be used for different purpose. Floating layout which will let organize windows like any other window manager is present. This is my first package and I need sponsor.
* rpmlint: clean [root@dhcp-lab-192 SPECS]# rpmlint ../SRPMS/awesome-2.3.1-1.fc9.src.rpm awesome.spec 1 packages and 1 specfiles checked; 0 errors, 0 warnings. * tested i386 build * mock succeeded [root@dhcp-lab-192 SPECS]# mock rebuild -r fedora-9-i386 ../SRPMS/awesome-2.3.1-1.fc9.src.rpm [root@dhcp-lab-192 SPECS]# mock rebuild -r fedora-9-i386 ../SRPMS/awesome-2.3.1-1.fc9.src.rpm INFO: Start(../SRPMS/awesome-2.3.1-1.fc9.src.rpm) Config(fedora-9-i386) ... State Changed: build INFO: Done(../SRPMS/awesome-2.3.1-1.fc9.src.rpm) Config(fedora-9-i386) 9 minutes 12 seconds INFO: Results and/or logs in: /var/lib/mock//fedora-9-i386/result
Actually rpmlint isn't clean: awesome.x86_64: E: explicit-lib-dependency libX11 awesome.x86_64: E: explicit-lib-dependency libXext awesome.x86_64: E: explicit-lib-dependency libXinerama awesome.x86_64: E: explicit-lib-dependency libXrandr Why do you need explicit dependencies on those? rpm already finds dependencies on: libX11.so.6()(64bit) libXext.so.6()(64bit) libXinerama.so.1()(64bit) libXrandr.so.2()(64bit) and several others which you did not include explicitly.
Yup, true. Removed the autodetected deps. Only libconfuse >= 2.6 is left. [root@dhcp-lab-192 SPECS]# rpmlint ../SRPMS/awesome-2.3.1-1.fc9.src.rpm awesome.spec ../RPMS/i386/awesome-2.3.1-1.fc9.i386.rpm ../RPMS/i386/awesome-debuginfo-2.3.1-1.fc9.i386.rpm 3 packages and 1 specfiles checked; 0 errors, 0 warnings.
*** Bug 427530 has been marked as a duplicate of this bug. ***
* Thu Jul 3 2008 Michal Nowak <mnowak> 2.3.2-1 - version bump - add libconfuse-devel as a build dep. - removed fedora as a vendor from .desktop file
Please repost a link to the new srpm when you made a new version.
http://mnowak.fedorapeople.org/awesome/awesome-2.3.2-1.fc9.src.rpm (spec file's link is the same) Sorry for inconvenience.
libconfuse-devel is listed twice in BuildRequires. It should certainly be versionned in the BuildRequires too. For the desktop file, I think that you should better call the file %{name}.desktop and install it with a cp. The guidelines are for .desktop files for use in menus. Also it seems to me that type=application and Icon=awesome32 are wrong for a xsession .desktop file. Also GenericName doesn't make much sense. I would suggest using removing the doc installed as part of make install and use %doc instead. /usr/share/awesome/ and /usr/share/awesome/icons are unowned.
libconfuse has been updated to 2.6 on my request back when I wanted to package awesome in bug 427530 and bug 427529 respectively, so that version requirement is definitely needed. For reference purposes, this might be useful (or not): http://ndim.fedorapeople.org/packages/awesome/2.1-1.fc8/awesome.spec
(In reply to comment #8) > libconfuse-devel is listed twice in BuildRequires. It should > certainly be versionned in the BuildRequires too. Sure. Fixed. Both. > For the desktop file, I think that you should better call the > file %{name}.desktop and install it with a cp. The guidelines > are for .desktop files for use in menus. Fixed. > Also it seems to me > that type=application and Icon=awesome32 are wrong for a > xsession .desktop file. Also GenericName doesn't make much sense. Fixed. > > I would suggest using removing the doc installed as part of make > install and use %doc instead. enhanced %configure part + added %doc <...> > /usr/share/awesome/ and /usr/share/awesome/icons are unowned. I hope I fixed it with %dir now. Please, let me know whether still unfixed. (In reply to comment #9) > For reference purposes, this might be useful (or not): I took a look and found it useful, thanks. -- * http://mnowak.fedorapeople.org/awesome/awesome.spec * http://mnowak.fedorapeople.org/awesome/awesome-2.3.2-3.fc9.src.rpm
Just a one line change: * http://mnowak.fedorapeople.org/awesome/awesome.spec * http://mnowak.fedorapeople.org/awesome/awesome-2.3.2-4.fc9.src.rpm
FYI your latest srpm does not build: http://koji.fedoraproject.org/koji/taskinfo?taskID=720416
(In reply to comment #12) > FYI your latest srpm does not build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=720416 Indeed. Thanks for noting that Mamoru-san. See %%description * http://mnowak.fedorapeople.org/awesome/awesome.spec * http://mnowak.fedorapeople.org/awesome/awesome-2.3.2-5.fc9.src.rpm
I'd guess the "Requires: libconfuse >= 2.6" is autodetected and should thus be removed, and having the "libconfuse >= 2.6" in BuildReq is sufficient. At least it was with my package. :-)
(In reply to comment #14) > I'd guess the "Requires: libconfuse >= 2.6" is autodetected and should thus be > removed, No, is not. Requires: ... libconfuse.so.0 ... And because on F8 there's stil v2.5 I found it useful ATM. > and having the "libconfuse >= 2.6" in BuildReq is sufficient. At least > it was with my package. :-) you mean -devel, right?
* http://mnowak.fedorapeople.org/awesome/awesome.spec * http://mnowak.fedorapeople.org/awesome/awesome-2.3.2-6.fc9.src.rpm One more update -- libXinerama-devel was missing. Now it builds inside mock.
Meh. Of course I meant "BuildRequires: libconfuse-devel >= 2.6". I'd add a comment on the reason for the "Requires: libconfuse >= 2.6", as that is not at all obvious.
1. Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=720778 2. [root@dhcp-lab-192 SPECS]# rpmquery libconfuse libconfuse-devel libconfuse-2.5-3.fc9.i386 libconfuse-devel-2.5-3.fc9.i386 checking for confuse... no configure: error: awesome requires libconfuse >= 2.6. error: Bad exit status from /var/tmp/rpm-tmp.45799 (%build) When you have libconfuse-devel-2.6 but libconfuse-2.5 then it builds but it's not supported combination. I did not try to run awesome with old libconfuse. 3. From my look to F8 repos I found out that there's still libconfuse-2.5 so I insist ATM on "... >= 2.6" because when you can't build awesome on F8 there's no reason to ship it there. Or am I missing something? I appreciate your comments, please, let me know what you think.
* http://mnowak.fedorapeople.org/awesome/awesome.spec * http://mnowak.fedorapeople.org/awesome/awesome-2.3.2-7.fc9.src.rpm * Thu Jul 17 2008 Michal Nowak <mnowak> 2.3.2-7 - after some discussion I removed explicit dependency on libconfuse >= 2.6; the thing is that awesome runs fine with libconfuse-2.5 but does not build with < 2.6. Some build-time hack might be possible but I am obviously not going to be involved in this auto*magic. (thx Hans Ulrich Niedermann)
The normal way things go is that the package is built in a rawhide chroot, an F-9 chroot, and an F-8 chroot. In each chroot, the BuildRequires: libconfuse >= 2.6" is properly tested. Only if successful, there will be a binary package for the respective release. And only if there is a binary package for the respective release, will someone usually install the software. But if someone happens to take an F-9 binary and installs it on an F-8 system, the autodetected soname for libconfuse should provide the proper dependencies - iff the libconfuse people know how API/ABI compatibility and sonames are supposed to work. I have not checked whether this is the case. Last time I built awesome (around awesome 2.1 times), awesome did not compile with libconfuse-devel 2.5, because some headers or macro definitions were missing in the 2.5 headers. That was why I added the 2.6 check to awesome's configure.ac (I was worked closely with awesome upstream at the time). It is possible that awesome's libconfuse requirements have changed since and it now works with libconfuse 2.5 again, but I have not researched that yet. In the given state, I'd just say that awesome requires libconfuse-devel >= 2.6 to build, and as long as F-8 does not provide libconfuse-devel >= 2.6, there will be no awesome for F-8.
I have a build error on devel, when I have no network: $ /usr/bin/xmlto man awesomerc.5.xml xmlto: input does not validate (status 3) error : connection refused /home/dumas/RPM-fc/BUILD/awesome-2.3.2/awesomerc.5.xml:2: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" D DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" ^ error : connection refused warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" validity error : Could not load the external subset "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" Document /home/dumas/RPM-fc/BUILD/awesome-2.3.2/awesomerc.5.xml does not validate
That is a bug in xmlto and probably IIRC in some Docbook/XML/DTD/Catalog registration package. IIRC there was something on fedora-devel about this issue within the last few weeks.
Does anyone have ideas about what to fix/enhance regarding the package? (Assuming the xmlto-related problem is another battlefield.)
* Thu Jul 28 2008 Michal Nowak <mnowak> 2.3.3-1 - version bump fixes two bugs - give floating dialogs of maximized windows focus - awesomerc: fix xterm -e in case of others terms * http://mnowak.fedorapeople.org/awesome/awesome.spec * http://mnowak.fedorapeople.org/awesome/awesome-2.3.3-1.fc9.src.rpm
awesome 3.0 is close [1] I'll redo the SPEC file [1] http://awesome.naquadah.org/download/
The xmlto issue seems to be fixed. I'll try to review the latest now that I can build it. I have no internet during the week end so hopefully on monday.
Bump to version 3. This is completely new version which triggers two new dependencies not in Fedora libev bug 458785 and xcb-util bug 458784. * Thu Aug 11 2008 Michal Nowak <mnowak> 3.0-0.2.rc2 - bump to RC2 * Thu Aug 04 2008 Michal Nowak <mnowak> 3.0-0.1.rc1 - bump to awesome v3-the new generation * http://mnowak.fedorapeople.org/awesome/awesome.spec * http://mnowak.fedorapeople.org/awesome/awesome-3.0-0.2.rc2.fc9.src.rpm Patch0 is in upstream git repo. For xsession file is filled bug upstream.
(In reply to comment #27) > Patch0 is in upstream git repo. For xsession file is filled bug upstream. Implemented. http://git.naquadah.org/?p=awesome.git;a=commit;h=d2f38d4051b90fd5b2deab3ddbc57e58ab574efd Will do some tuning on it.
Bump to RC3 * http://mnowak.fedorapeople.org/awesome/awesome.spec * http://mnowak.fedorapeople.org/awesome/awesome-3.0-0.3.rc3.fc9.src.rpm * Thu Aug 15 2008 Michal Nowak <mnowak> 3.0-0.3.rc3 - bump to RC3 - xsession desktop file is now provided by upstream - dumped patches awesome-3.0-rc1-fedora-doc-path.patch awesome-3.0-rc2-fedora-xsession-path.patch both are now in upstream - cmake is now need >2.6 (present in rawhide)
I can't download the srpm (that being said I am still too busy to review it ;-)
:) That's because of that ongoing Fedora infrastructure problems. Anyway, I have updated package with fixed build deps and other enhancements. * http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/awesome/awesome.spec * http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/awesome/awesome-3.0-0.5.rc3.fc9.src.rpm * Mon Aug 18 2008 Michal Nowak <mnowak> 3.0-0.5.rc3 - buildepend on readline-devel, glib2-devel, gtk2-devel, luadoc - install via "install -p" - %%{_datadir}/%%{name}/themes/default is not a config file no more, having config file in /usr is kinda weird - added sub-package awesome-doc to handle API doc files * Sat Aug 16 2008 Michal Nowak <mnowak> 3.0-0.4.rc3 - awesome-3.0-rc3-enhance-wallpaper-cmd.patch: enhance setting of wallpaper - new dep: xsri - %%{_datadir}/%{name}/themes/default is now handled configfile
Bump to RC4: ------------ dhcp-lab-192 newman # rpmlint /usr/src/redhat/SPECS/awesome.spec /usr/src/redhat/SRPMS/awesome-3.0-0.6.rc4.fc9.src.rpm /usr/src/redhat/RPMS/i386/awesome-3.0-0.6.rc4.fc9.i386.rpm /usr/src/redhat/RPMS/i386/awesome-debuginfo-3.0-0.6.rc4.fc9.i386.rpm /usr/src/redhat/RPMS/i386/awesome-doc-3.0-0.6.rc4.fc9.i386.rpm 4 packages and 1 specfiles checked; 0 errors, 0 warnings. Builds OK in mock with xcb-util, libev and enhanced cairo. * Sun Aug 24 2008 Michal Nowak <mnowak> 3.0-0.6.rc4 - bump to RC4 - rejecting awesome-3.0-rc3-enhance-wallpaper-cmd.patch -- solved upstream via awsetbg script - using imlib2 instead of GTK+ pixbuf http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/awesome/awesome.spec http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/awesome/awesome-3.0-0.6.rc4.fc9.src.rpm
* Fri Aug 29 2008 Michal Nowak <mnowak> 3.0-0.7.rc5 - bump to RC5 http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/awesome/awesome.spec http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/awesome/awesome-3.0-0.7.rc5.fc9.src.rpm
* Sat Sep 06 2008 Michal Nowak <mnowak> 3.0-0.8.rc6 - bump to RC6 - /usr/share/awesome/themes/default is now, again, config file http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/awesome/awesome.spec http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/awesome/awesome-3.0-0.8.rc6.fc9.src.rpm dhcp-lab-192 SPECS # rpmlint -i awesome.spec /usr/src/redhat/SRPMS/awesome-3.0-0.8.rc6.fc9.src.rpm /usr/src/redhat/RPMS/i386/awesome-3.0-0.8.rc6.fc9.i386.rpm /usr/src/redhat/RPMS/i386/awesome-doc-3.0-0.8.rc6.fc9.i386.rpm /usr/src/redhat/RPMS/i386/awesome-debuginfo-3.0-0.8.rc6.fc9.i386.rpm awesome.i386: E: file-in-usr-marked-as-conffile /usr/share/awesome/themes/default A file in /usr is marked as being a configuration file. Store your conf files in /etc/ instead. 4 packages and 1 specfiles checked; 1 errors, 0 warnings. See upstream bug: http://awesome.naquadah.org/bugs/index.php?do=details&task_id=302
* Fri Sep 19 2008 Michal Nowak <mnowak> 3.0-1 - bump to 3.0 assam SPECS # rpmlint awesome.spec /usr/src/redhat/SRPMS/awesome-3.0-1.fc9.src.rpm /usr/src/redhat/RPMS/i386/awesome-3.0-1.fc9.i386.rpm /usr/src/redhat/RPMS/i386/awesome-doc-3.0-1.fc9.i386.rpm /usr/src/redhat/RPMS/i386/awesome-debuginfo-3.0-1.fc9.i386.rpm awesome.i386: E: file-in-usr-marked-as-conffile /usr/share/awesome/themes/default 4 packages and 1 specfiles checked; 1 errors, 0 warnings. http://mnowak.fedorapeople.org/awesome/awesome.spec http://mnowak.fedorapeople.org/awesome/awesome-3.0-1.fc9.src.rpm
I can't find libev-devel ?? In rawhide. How comes lua files are not in %_datadir? They are not platform independent? It is a bit strange to have an API for a window manager. Is it because lua is an interpreted language, so that the API has to come with runtime? I think that it is wrong to have: %config(noreplace) %{_datadir}/%{name}/themes/default this file should be under the control of upstream/packager. Isn't it possible to override what is there with something in %_sysconfdir? Build stops with -- package 'cairo-xcb' not found I don't have libev-devel, it may be the reason.
(In reply to comment #36) > I can't find libev-devel ?? In rawhide. > See bug 458785 for srpm package. > How comes lua files are not in %_datadir? They are not platform > independent? > The are platform independent. Only rc.lua is not in %_datadir, but this is config file for awesome. > It is a bit strange to have an API for a window manager. Is it > because lua is an interpreted language, so that the API has to > come with runtime? > I probably don't understand... Awesome is using the lua files for it's own manipulation with windows and stuff. They are necessary to be bundled with runtime. Let me know if you have other comments. > I think that it is wrong to have: > %config(noreplace) %{_datadir}/%{name}/themes/default > this file should be under the control of upstream/packager. > Isn't it possible to override what is there with something in > %_sysconfdir? > It took me a long time to decide whether to shield that file or not. It's not possible to move it to /etc, I opened a bug in upstream but was closed wontfix (sorry cant find it in the crappy flyspray http://awesome.naquadah.org/bugs/). It's possible to have it in user ~/.config/awesome. I can change it from config file to ordinary one, if you wish, no problem. > Build stops with > -- package 'cairo-xcb' not found > I don't have libev-devel, it may be the reason. No. the problem is cairo's missing XCB support (just Xlib). It necessary to recompile it with (--enable-xcb). See bug 465759.
http://mnowak.fedorapeople.org/awesome/awesome.spec http://mnowak.fedorapeople.org/awesome/awesome-3.1-1.fc10.src.rpm Just an update for 3.1.
http://mnowak.fedorapeople.org/awesome/awesome.spec http://mnowak.fedorapeople.org/awesome/awesome-3.1-2.fc10.src.rpm * Wed Dec 24 2008 Michal Nowak <mnowak> 3.1-2 - minor SPEC-file changes
http://mnowak.fedorapeople.org/awesome/awesome.spec http://mnowak.fedorapeople.org/awesome/awesome-3.1.1-1.fc10.src.rpm * Tue Jan 13 2009 Michal Nowak <mnowak> 3.1.1-1 - 3.1.1
Does not build on Rawhide x86_64: -- checking for modules 'libev;glib-2.0;cairo;pango;pangocairo;x11-xcb;xcb-randr;xcb-xinerama;xcb-event>=0.3.0;xcb-aux>=0.3.0;xcb-atom>=0.3.0;xcb-keysyms>=0.3.0;xcb-icccm>=0.3.0;cairo-xcb;xproto>=7.0.11;imlib2' -- package 'cairo-xcb' not found
(In reply to comment #41) > Does not build on Rawhide x86_64: Does not build on any Fedora. See bug 465759. You have to enable XCB backend in Cairo yourself to build at all.
http://mnowak.fedorapeople.org/awesome/awesome.spec http://mnowak.fedorapeople.org/awesome/awesome-3.2-0.1.rc3.fc10.src.rpm -- * Fri Feb 20 2009 Michal Nowak <mnowak> 3.2-0.1.rc3 - 3.2-rc3 - more docs files
http://lists.cairographics.org/archives/cairo/2008-December/thread.html#16008 More details about cairo & xcb.
http://mnowak.fedorapeople.org/awesome/awesome.spec http://mnowak.fedorapeople.org/awesome/awesome-3.2-0.2.rc4.fc10.src.rpm -- * Mon Mar 2 2009 Michal Nowak <mnowak> 3.2-0.2.rc4 - 3.2-rc4
http://mnowak.fedorapeople.org/awesome/awesome.spec http://mnowak.fedorapeople.org/awesome/awesome-3.2.fc10.src.rpm -- * Mon Mar 16 2009 Michal Nowak <mnowak> - 2.0.x-0.4.r6671 - snashot 6671
http://mnowak.fedorapeople.org/awesome/awesome.spec http://mnowak.fedorapeople.org/awesome/awesome-3.2.1-1.fc11.src.rpm -- * Tue Apr 7 2009 Michal Nowak <mnowak> 3.2.1-1 - 3.2.1 - rebased patch: awesome-3.2-libev-pkg-config.patch - define XDG_CONFIG_DIR as %%{_sysconfdir}/xdg
http://mnowak.fedorapeople.org/awesome/awesome.spec http://mnowak.fedorapeople.org/awesome/awesome-3.3-0.1.rc1.fc11.src.rpm -- * Thu May 7 2009 Michal Nowak <mnowak> 3.3-0.1.rc1 - 3.3-rc1 Needs libxdg-basedir, see bug libxdg-basedir.
http://mnowak.fedorapeople.org/awesome/awesome-3.3-0.2.rc2.fc11.src.rpm -- * Thu May 13 2009 Michal Nowak <mnowak> 3.3-0.2.rc2 - 3.3-rc2
http://mnowak.fedorapeople.org/awesome/awesome-3.3-0.3.rc3.fc11.src.rpm -- * Tue May 19 2009 Michal Nowak <mnowak> 3.3-0.3.rc3 - 3.3-rc3
http://mnowak.fedorapeople.org/awesome/awesome-3.3-0.4.rc4.fc11.src.rpm -- * Thu May 28 2009 Michal Nowak <mnowak> 3.3-0.4.rc4 - 3.3-rc4
Is anyone providing a cairo package prebuilt with the xcb backend?
I don't think so. It's quite easy to DIY.
As cairo maintainer denying to include XKB support into main cairo package, what if cairo-experimental package will be made to include those such extensions like XKB? It can work in two ways: 1. Rename library to libcairo-experimental.so, and link awesome against it. But here is high risk that both cairo libraries will be loaded. 2. Put libcairo.so to an alternative path like /usr/lib/cairo-expermental and add it to ld.so search path so it loaded instead of main cairo. (freetype-freeworld in RPM Fusion work this way.) This way it will override system cairo. I’m inclined to try second way. What do you think about it?
(In reply to comment #54) > As cairo maintainer denying to include XKB support into main cairo package, > what if cairo-experimental package will be made to include those such > extensions like XKB? It can work in two ways: XCB (the X Client Binding), not XKB (the X KeyBoard extension). > 1. Rename library to libcairo-experimental.so, and link awesome against it. But > here is high risk that both cairo libraries will be loaded. > > 2. Put libcairo.so to an alternative path like /usr/lib/cairo-expermental and > add it to ld.so search path so it loaded instead of main cairo. > (freetype-freeworld in RPM Fusion work this way.) This way it will override > system cairo. > > I’m inclined to try second way. What do you think about it? Sounds like a very crude kludge, but it would most probably work. Are you sure your time wouldn't be better spent reviewing cairo's XCB backend and determining what needs to be done in order to bring it on par with the libX11 backend? You could write a summary to both the XCB and Cairo lists, asking if one of the developers wants to help you out.
(In reply to comment #55) > (In reply to comment #54) > > As cairo maintainer denying to include XKB support into main cairo package, > > what if cairo-experimental package will be made to include those such > > extensions like XKB? It can work in two ways: > > XCB (the X Client Binding), not XKB (the X KeyBoard extension). Oh, sure, thanks. > > 1. Rename library to libcairo-experimental.so, and link awesome against it. But > > here is high risk that both cairo libraries will be loaded. > > > > 2. Put libcairo.so to an alternative path like /usr/lib/cairo-expermental and > > add it to ld.so search path so it loaded instead of main cairo. > > (freetype-freeworld in RPM Fusion work this way.) This way it will override > > system cairo. > > > > I’m inclined to try second way. What do you think about it? > > Sounds like a very crude kludge, but it would most probably work. > > Are you sure your time wouldn't be better spent reviewing cairo's XCB backend > and determining what needs to be done in order to bring it on par with the > libX11 backend? > > You could write a summary to both the XCB and Cairo lists, asking if one of the > developers wants to help you out. Searching cairo list, I found: http://lists.cairographics.org/archives/cairo/2008-December/016008.html Merging XCB and Xlib backends may be the proper way in long term. But if that requires time of GSoC project... I don’t think I have that now, considering that I’m doing other GSoC project now. Packaging work looks to be less hard.
http://mnowak.fedorapeople.org/awesome/awesome-3.3-1.fc11.src.rpm
Christian: I am glad you expressed intention to review this but just wanna let you know that this is still being blocked by bug 465759 and not going to be fixed any time soon.
(In reply to comment #58) > Christian: I am glad you expressed intention to review this but just wanna let > you know that this is still being blocked by bug 465759 and not going to be > fixed any time soon. Oh. You are right. I only scanned over the dependency list and it looked like that they were all fixed. ;-) I didn't expected a wontfix here... Ok, so I guess the review will have to wait some more time...
Just poking in here when I remembered that awesome looked interesting to try, but is it possible to package version 2.x until Cairo supports XCB? That would enable you to get sponsored and the package reviewed so that when XCB is enabled, awesome3 can come sooner. I can jump on as comaintainer then to help with the jump if you'd like.
Ben: Correct awesome-2 does not need XCB aware cairo. 2.3 was released 14 months ago, but having small fixes till now, and is called deprecated in favor of v3. Problem with your approach is that awesome v2 is really old, upstream support might end anytime, and thus is far from Fedora's close-to-upstream. Note that cairo-xcb is far from being soon-supported upstream (still experimental), that means we would have awesome-2 for months, if not even years. That's waste of time, from my POV.
http://mnowak.fedorapeople.org/awesome/awesome-3.3.3-1.fc12.src.rpm
Hmm, isn't it better to have some awesome2 than nothing?
Jens: See Comment #61. In brief: awesome v2 is near to dead code, which I personally don't care.
(In reply to comment #64) > awesome v2 is near to dead code I know, but what about bug 465759? Feels like this is never going to happen? Is it possible to make a separate package for cairo-xcb?
Since it's unmaintained by cairo folks, and the awesome developers insist on using it, perhaps we should ask them to see if they would take on the task of supporting cairo-xcb? After all, the current problems are stopping *their* window manager from shipping to a lot of users, and I consider Behdad's reasoning quite sound on this matter (the Ubuntu developers seem a bit more cavalier in this regard). Michal, anyone on the developers' side that you could suggest this to?
$ rpmbuild --rebuild http://mnowak.fedorapeople.org/awesome/awesome-3.3.3-1.fc12.src.rpm : -- lua -> /usr/bin/lua -- luadoc -> /usr/bin/luadoc -- convert not found. CMake Error at awesomeConfig.cmake:41 (message): convert is required to build awesome Call Stack (most recent call first): awesomeConfig.cmake:62 (a_find_program) CMakeLists.txt:15 (include) -- Configuring incomplete, errors occurred! I think you need "BuildRequires: ImageMagick" btw.
Ok with a xcb patched cairo I then get to: -- Configuring awesome-version-internal.h -- Configuring awesome.doxygen -- Configuring incomplete, errors occurred! (same with 3.3.4)
Thanks added missing BuildRequires. 3.3.4 build fine for me at my ordinary system, but fails in mock this way: ... DEBUG: -- checking for modules 'glib-2.0;libev;cairo;x11;pango>=1.19.3;pangocairo>=1.19.3;xcb-randr;xcb-xtest;xcb-xinerama;xcb-event>=0.3.6;xcb-aux>=0.3.0;xcb-atom>=0.3.0;xcb-keysyms>=0.3.4;xcb-icccm>=0.3.3;xcb-image>=0.3.0;xcb-property>=0.3.0;cairo-xcb;libstartup-notification-1.0>=0.10;xproto>=7.0.15;imlib2;libxdg-basedir>=1.0.0' DEBUG: -- package 'libxdg-basedir>=1.0.0' not found ... And I am pretty sure libxdg-basedir-1.0.2 is installed, I can see it in mock DEBUG output... Can anyone see the same in fedora-rawhide-i386 mock with http://mnowak.fedorapeople.org/awesome/awesome-3.3.4-1.fc12.src.rpm ?
(In reply to comment #65) > (In reply to comment #64) > > awesome v2 is near to dead code > > I know, but what about bug 465759? Well, Behdad feels it's upstream job to move with cairo-xcb, perhaps they don't see any benefits in that particular backend? > Feels like this is never going to happen? When cairo-xcb is non-experimental and fully supported. Never say never :). > > Is it possible to make a separate package for cairo-xcb? We've discussed this topic in this bug several times. I'd prefer not to.
(In reply to comment #69) > Thanks added missing BuildRequires. 3.3.4 build fine for me at my ordinary > system, but fails in mock this way: > DEBUG: -- package 'libxdg-basedir>=1.0.0' not found The BR is wrong, it should be on libxdg-basedir-devel, not libxdg-basedir.
Thanks Thomas, fixed here: http://mnowak.fedorapeople.org/awesome/awesome-3.3.4-2.fc12.src.rpm (Builds fine in Mock.)
(In reply to comment #68) > Ok with a xcb patched cairo I then get to: > > -- Configuring awesome-version-internal.h > -- Configuring awesome.doxygen > -- Configuring incomplete, errors occurred! > > (same with 3.3.4) No idea what it means, can you please try it in mock? (fedora-rawhide-i386 seems to work for me.)
You're right mock is fine and awesome3 is more awesome! :-)
Created attachment 361621 [details] awesome.spec-1.patch Some small cleanup: - integrate rctag macro - simplify removal of .in files and filelist which should make 3.4 testing easier :)
Thanks Jens, patch accepted and appreciated -- it includes what I always wanted to :). http://mnowak.fedorapeople.org/awesome/awesome-3.3.4-3.fc12.src.rpm Expect 3.4 RC pkg, when I a have chance to try it and feel it's usable.
If someone is interested, I've built F11 packages and put them in a repo here: http://thm.fedorapeople.org/awesome/fedora-11. (Use at your own risk.)
awesome-3.4 + upstream patch here: http://mnowak.fedorapeople.org/awesome/awesome-3.4-0.2.rc2.fc12.src.rpm Works quite nice; adapt your rc.lua.
(I just mention in passing that people who like awesome might want to take a look at bluetile too: which is also pretty cool and works in fedora today... See pkg review bug 522821 or something like this should work: # yum install cabal-install ghc-X11-devel ghc-gtk-devel ghc-glade-devel # cabal update # cabal install bluetile # ~/.cabal/bin/bluetile to give it a spin.)
Updated awesome-3.4 to RC3 with path; untested, though.
3.4 in fp.o: http://mnowak.fedorapeople.org/awesome/awesome-3.4-1.fc12.src.rpm It's quite the same as 3.4-rc3, just version changed. No need to update, I guess.
Is there any chance of getting this on F12?
(In reply to comment #82) > Is there any chance of getting this on F12? I'm afraid the chance is quite small since unfortunately awesome relies on xcb support in cairo which isn't there yet. There were lots of discussions about it in this bug report, e.g. comment #58 and comment #70.
(In reply to comment #83) > (In reply to comment #82) > > Is there any chance of getting this on F12? > > I'm afraid the chance is quite small since unfortunately awesome relies on xcb > support in cairo which isn't there yet. There were lots of discussions about it > in this bug report, e.g. comment #58 and comment #70. That's a shame. Who's fault is that? It looks like awesome is supported on all the major distributions (and several minor ones), so the finger seems to be pointing to Fedora =/
(In reply to comment #84) > That's a shame. Who's fault is that? > > It looks like awesome is supported on all the major distributions (and several > minor ones), so the finger seems to be pointing to Fedora =/ Indeed. On the other hand, the Fedora maintainer for Cairo seems to have a sound argument: Cairo's XCB backend has been unmaintained for years and therefore carries a number of bugs that were fixed in the X11 backend. Couldn't anyone involved with Awesome step forward and have a good look at what needs to be done to bring the XCB backend in Cairo on par with the X11 backend?
Or just change awesome to use cairo-xlib. What's wrong with doing that?
(In reply to comment #86) > Or just change awesome to use cairo-xlib. What's wrong with doing that? Is it even an option? I thought all of Awesome was written to use directly XCB rather than X11. Side note: I used to think that XCB was a rather pointless project when it was still in the works. Now that XCB became the libX11 backend, migrating applications and toolkits to XCB sounds like a nice way to simplify the X stack a little and slightly reduce its associated overhead. So I'm glad to see early adopters like Aswesome paving the road for the others to follow.
3.4.1 in fp.o: http://mnowak.fedorapeople.org/awesome/awesome-3.4.1-1.fc12.src.rpm
(In reply to comment #88) > 3.4.1 in fp.o: > http://mnowak.fedorapeople.org/awesome/awesome-3.4.1-1.fc12.src.rpm Looks broken: It has a size of only 16k.
Thanks for letting me know - re-uploaded now.
3.4.2 in fp.o: http://mnowak.fedorapeople.org/awesome/awesome-3.4.2-1.fc12.src.rpm
3.4.3 in fp.o: http://mnowak.fedorapeople.org/awesome/awesome-3.4.3-1.fc12.src.rpm
3.4.4 in fp.o. http://mnowak.fedorapeople.org/awesome/awesome-3.4.4-1.fc12.src.rpm
(In reply to comment #85) > Couldn't anyone involved with Awesome step forward and have a good look at what > needs to be done to bring the XCB backend in Cairo on par with the X11 backend? Good news from upstream is that they're moving to use the XCB backend by default and are building cairo-xlib-xcb as a compatibility layer, so we should see -xcb as default before long (see bug 465759 comment #11) I wonder if anybody here has already started building cairo for Fedora this way? There's probably a mass rebuild required though for cairo-xlib-xcb.
any change/progress? I've just built it from source twice, for F13. It'd be nice not to have to do that.
I agree it would be great to have a lean window manager in the form of awesome since not everyone runs on the same hardware, use of lesser machines making another desktop environment can make a world of difference to some especially in F13 or onwards. Any hopes of getting awesome in F13?
(In reply to comment #95) Jim: We are still missing official support in cairo for XCB, It's not in F-13, it could be in F-14, there's some effor in this regard. Spencer Tom Tafadzwa Chirume: Here applies the same for Jim. You are free to rebuild cairo with XCB backend (see it's spec file), install it and rebuild awesome srpm you can find here. When XCB backend is supported one in cairo awesome will be in Fedora Collection soon.
3.4.5 in fp.o. http://mnowak.fedorapeople.org/awesome/awesome-3.4.5-1.fc13.src.rpm
Updated packages in http://thm.fedorapeople.org/awesome/ for F11, F12 and F13.
http://mnowak.fedorapeople.org/awesome/awesome-3.4.6-1.fc13.src.rpm
A long time ago, Cairo needed an additional compile flag. Is that no longer required in f13? (Is there another bz with the RFE for cairo?)
(In reply to comment #101) > A long time ago, Cairo needed an additional compile flag. Is that no longer > required in f13? That's IMHO still needed. > (Is there another bz with the RFE for cairo?) Yes, bug #465759 blocks this one.
Do you want to setup cairo/awesome as a repo ("new_repo") on fedorapeople ? Seems like it would be quick to download the current srpm for both, build and upload again. This might make it easier for folks to test. Also, your readme should probably mention both of the bz id's if anyone has questions about them.
(In reply to comment #103) > Do you want to setup cairo/awesome as a repo ("new_repo") on fedorapeople ? See http://repos.fedorapeople.org/repos/thm/awesome (3.4.6 not yet there, but will be soon).
http://mnowak.fedorapeople.org/awesome/awesome-3.4.7-1.fc13.src.rpm
http://mnowak.fedorapeople.org/awesome/awesome-3.4.8-1.fc13.src.rpm
Failed to build F-12: http://koji.fedoraproject.org/koji/taskinfo?taskID=2554875 F-15: http://koji.fedoraproject.org/koji/taskinfo?taskID=2554869 Please, test your packages in Koji before submitting them.
(In reply to comment #107) > Failed to build > > F-12: http://koji.fedoraproject.org/koji/taskinfo?taskID=2554875 > F-15: http://koji.fedoraproject.org/koji/taskinfo?taskID=2554869 > > Please, test your packages in Koji before submitting them. They failed due to Fedora's cairo not having xcb enabled. Known issue (Bug #465759).
Doesn't build on F-12 nevertheless, because of a cmake incompatibility: -- Configuring awesome.doxygen CMake Error at CMakeLists.txt:284 (file): file does not recognize sub-command COPY [...] -- Configuring incomplete, errors occurred! Seems it needs a small patch to use install(FILES...) instead of file(COPY...) for cmake 2.6.x.
Building on F14 from sources, the first step is to rebuild cairo with --enable-xcb, but that fails: RPM build errors: Installed (but unpackaged) file(s) found: /usr/include/cairo/cairo-xcb.h /usr/lib64/pkgconfig/cairo-xcb-shm.pc /usr/lib64/pkgconfig/cairo-xcb.pc To get past that, I had to add these lines to the %files section of cairo.spec: %{_includedir}/cairo/cairo-xcb.h %{_libdir}/pkgconfig/cairo-xcb-shm.pc %{_libdir}/pkgconfig/cairo-xcb.pc Otherwise, these instructions worked fine: http://awesome.naquadah.org/wiki/Awesome-3-fedora
Anyone's aware what's the status on XCB in Cairo front? Also, anyone's aware what happens in their Git (http://git.naquadah.org/?p=awesome.git;a=summary)? It seems to me that the new major release takes ages...
Not aware, but definitely annoyed to still have to build my own RPMs, and especially to have to rebuild any time cairo changes. I thought the XCB/Cairo transition was to have been resolved for Fedora 14.
(In reply to comment #112) > Not aware, but definitely annoyed to still have to build my own RPMs, > and especially to have to rebuild any time cairo changes. As always, RPMS for current stable releases are in http://repos.fedorapeople.org/repos/thm/awesome/ I just stopped announcing that anytime there's a new version.
Thanks. I've used those and do appreciate them. If you were to do the same for rawhide, I would be all set ;-)
(In reply to comment #114) > Thanks. I've used those and do appreciate them. > If you were to do the same for rawhide, I would be all set ;-) Added packages for F15 and rawhide. Have fun! :)
3.4.10 is out. ...and I realized I don't care about awesome anymore.
(In reply to comment #115) > (In reply to comment #114) > > Thanks. I've used those and do appreciate them. > > If you were to do the same for rawhide, I would be all set ;-) > > Added packages for F15 and rawhide. Have fun! :) Thank you, Thomas (belatedly). Sorry to learn that Michal no longer cares.
I see there are now RPMs for awesome-3.4.10. Thank you, Thomas.
Thomas, any chance of a refresh? I see that there's a new cairo out. If you had an i686 repository, I'd use it ;-)
(In reply to comment #119) > Thomas, any chance of a refresh? > I see that there's a new cairo out. > If you had an i686 repository, I'd use it ;-) You mean f16? I recently updated my repository, please give it a try.
Yes, exactly. Thank you. However, when I try to update, I get this: --> Finished Dependency Resolution Error: Package: awesome-3.4.10-2.fc16.i686 (fedora-awesome) Requires: xsri You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest ... There's probably a way to tell yum to ignore that requirement (which is just fine, afaict), but I don't know it. Or maybe there's another source for the now-missing-in-F16 package?
Seems xsri has been retired, so I removed awesome's dependency on it.
Now it installs without a hitch. Thanks!
I've now switched to F16+awesome on my desktop too. Works well. Thanks again.
Thomas, I don't know if this is the appropriate place to report this problem, but the default configuration for "awesome" as installed by this package appears to use "xterm" for the "open terminal" command. Unfortunately, "xterm" is not included by default under common F16 (and possibly earlier) desktop configurations. I would suggest either: - Adding xterm as a requirement to the awesome rpm, or - Have the default configuration call "exo-open --launch TerminalEmulator", which will use the preferred terminal emulator as configured by the desktop environment.
Thanks for the feedback! (In reply to comment #125) > I would suggest either: > > - Adding xterm as a requirement to the awesome rpm, or This would be easy. > - Have the default configuration call "exo-open --launch TerminalEmulator", > which will use the preferred terminal emulator as configured by the desktop > environment. exo-open is xfce-specific. There is unfortunately no desktop-agnostic way of opening a terminal emulator, xdg-terminal is not there (yet). So, I am a bit unsure whether exo-open is the right choice. Changing the package would be easy of course.
I hadn't realized that about exo-open (I thought it was one of those generic things like xdg-open). So it's probably best just to add xterm as a dependency.
This is where it'd be nice to have "recommends". I use roxterm, so have no use for xterm.
Is there any plans to have 3.4.11 on fedora repo?
(In reply to comment #129) > Is there any plans to have 3.4.11 on fedora repo? Plans - yes, timeframe - no. Need to sort out how to have xcb-utils 3.8 and three libs that have been splitted off xcb-utils packaged for F16 so they don't conflict with official packages.
(In reply to comment #130) > (In reply to comment #129) > > Is there any plans to have 3.4.11 on fedora repo? > > Plans - yes, timeframe - no. > > Need to sort out how to have xcb-utils 3.8 and three libs that have been > splitted off xcb-utils packaged for F16 so they don't conflict with official > packages. Hi Thomas, do you have anything that works with F17? My desktop now runs F17, and I found that the -rawhide rpms did not work there. Building from source rpms didn't work either, due to protected multilib problems with cairo, so I ended up building from sources, and the result works, but RPMs would be better... Thanks, Jim
Hi Jim, (In reply to comment #131) > Hi Thomas, do you have anything that works with F17? The repo has been updated, can you give it a try?
Hi Thomas, I've just installed it on F17/x86_64 and (as usual) it works perfectly. Thanks again!
Good news everyone. Commit facaf3d652de92a7a40ae635a0be9975d280dcae in cairo fedora package would suggest we have xcb support (finally). That would mean awesome can become standard part of Fedora now! I've actually built current srpm for F17 in rawhide mock without additional repos. So...who is going to resurrect this review? Probably will need a new review bug. I'd be willing to comaintain and/or review.
(In reply to comment #134) > Good news everyone. Commit facaf3d652de92a7a40ae635a0be9975d280dcae in cairo > fedora package would suggest we have xcb support (finally). That would mean > awesome can become standard part of Fedora now! I've actually built current > srpm for F17 in rawhide mock without additional repos. > > So...who is going to resurrect this review? Probably will need a new review > bug. I'd be willing to comaintain and/or review. That's really good news. Unless Michal wants to step in, I can open a new review ticket.
Not interested in maintaining the package; go ahead and file new BZ.
See bug 824949.
*** This bug has been marked as a duplicate of bug 824949 ***
Hi, someone are working this package ?? Regards
(In reply to comment #139) > Hi, someone are working this package ?? > > Regards Look at this: (In reply to comment #138) > > *** This bug has been marked as a duplicate of bug 824949 *** Also try $ sudo yum install awesome
This package is not on F17, so I think that was approved for F18. Regards
There are only Koji builds for F18. I believe there were some libxcb version issues with getting it on F17.
(In reply to comment #142) > There are only Koji builds for F18. I believe there were some libxcb version > issues with getting it on F17. Correct. The package exists only for F18+ due to non-existing support for xcb in cairo. For F17 you can try unofficial Fedora repository: http://awesome.naquadah.org/wiki/Awesome-3-fedora#Unofficial_FedoraPeople_Repository A word of warning though: besides awesome this will install unsupported version of cairo. If you file bugreports for that, you will be ignored most likely. However it worked fairly well for me while I was on F17