Bug 452427 (awesome) - Review Request: awesome - Extremely fast, small, dynamic and awesome floating and tiling window manager
Summary: Review Request: awesome - Extremely fast, small, dynamic and awesome floating...
Keywords:
Status: CLOSED DUPLICATE of bug 824949
Alias: awesome
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Christian Krause
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 427530 (view as bug list)
Depends On: 458784 458785 465759 499517 libxdg-basedir
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-22 20:41 UTC by Michal Nowak
Modified: 2013-03-08 02:04 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-16 15:47:49 UTC
Type: ---
Embargoed:
chkr: fedora-review?


Attachments (Terms of Use)
awesome.spec-1.patch (3.50 KB, patch)
2009-09-18 10:01 UTC, Jens Petersen
no flags Details | Diff

Description Michal Nowak 2008-06-22 20:41:22 UTC
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.

Comment 1 Michal Nowak 2008-06-22 21:15:33 UTC
* 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

Comment 2 Jason Tibbitts 2008-06-22 21:29:01 UTC
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.


Comment 3 Michal Nowak 2008-06-22 21:52:38 UTC
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.

Comment 4 Mamoru TASAKA 2008-06-23 02:48:31 UTC
*** Bug 427530 has been marked as a duplicate of this bug. ***

Comment 5 Michal Nowak 2008-07-03 10:36:20 UTC
* 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

Comment 6 Patrice Dumas 2008-07-05 13:30:00 UTC
Please repost a link to the new srpm when you made a new version.

Comment 7 Michal Nowak 2008-07-06 08:23:11 UTC
http://mnowak.fedorapeople.org/awesome/awesome-2.3.2-1.fc9.src.rpm

(spec file's link is the same)

Sorry for inconvenience. 

Comment 8 Patrice Dumas 2008-07-13 22:51:34 UTC
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.


Comment 9 Hans Ulrich Niedermann 2008-07-14 00:39:33 UTC
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


Comment 10 Michal Nowak 2008-07-15 12:14:37 UTC
(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

Comment 12 Mamoru TASAKA 2008-07-16 17:52:11 UTC
FYI your latest srpm does not build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=720416

Comment 13 Michal Nowak 2008-07-16 18:43:26 UTC
(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

Comment 14 Hans Ulrich Niedermann 2008-07-16 19:13:30 UTC
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. :-)


Comment 15 Michal Nowak 2008-07-16 19:56:33 UTC
(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?


Comment 16 Michal Nowak 2008-07-16 20:12:44 UTC
* 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.

Comment 17 Hans Ulrich Niedermann 2008-07-16 22:22:44 UTC
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.


Comment 18 Michal Nowak 2008-07-17 08:04:14 UTC
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.

Comment 19 Michal Nowak 2008-07-17 08:24:28 UTC
* 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)


Comment 20 Hans Ulrich Niedermann 2008-07-17 10:00:27 UTC
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.


Comment 21 Patrice Dumas 2008-07-18 09:59:38 UTC
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


Comment 22 Hans Ulrich Niedermann 2008-07-18 11:32:54 UTC
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.


Comment 23 Michal Nowak 2008-07-22 12:43:39 UTC
Does anyone have ideas about what to fix/enhance regarding the package?
(Assuming the xmlto-related problem is another battlefield.)

Comment 24 Michal Nowak 2008-07-28 14:34:17 UTC
* 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

Comment 25 Michal Nowak 2008-08-04 13:59:04 UTC
awesome 3.0 is close [1] I'll redo the SPEC file

[1] http://awesome.naquadah.org/download/

Comment 26 Patrice Dumas 2008-08-08 15:02:19 UTC
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.

Comment 27 Michal Nowak 2008-08-12 09:58:55 UTC
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.

Comment 28 Michal Nowak 2008-08-12 10:11:20 UTC
(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.

Comment 29 Michal Nowak 2008-08-15 13:56:51 UTC
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)

Comment 30 Patrice Dumas 2008-08-18 15:07:56 UTC
I can't download the srpm (that being said I am still too busy
to review it ;-)

Comment 31 Michal Nowak 2008-08-18 18:32:23 UTC
:)

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

Comment 32 Michal Nowak 2008-08-24 15:07:07 UTC
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

Comment 34 Michal Nowak 2008-09-06 14:17:13 UTC
* 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

Comment 35 Michal Nowak 2008-09-19 10:50:17 UTC
* 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

Comment 36 Patrice Dumas 2008-10-03 19:04:08 UTC
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.

Comment 37 Michal Nowak 2008-10-06 09:26:55 UTC
(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.

Comment 39 Michal Nowak 2008-12-24 22:44:57 UTC
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

Comment 40 Michal Nowak 2009-01-13 12:29:17 UTC
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

Comment 41 Michel Lind 2009-02-09 13:33:50 UTC
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

Comment 42 Michal Nowak 2009-02-09 14:23:23 UTC
(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.

Comment 43 Michal Nowak 2009-02-20 22:54:43 UTC
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

Comment 44 lexual 2009-02-25 01:52:31 UTC
http://lists.cairographics.org/archives/cairo/2008-December/thread.html#16008

More details about cairo & xcb.

Comment 45 Michal Nowak 2009-03-02 20:13:36 UTC
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

Comment 46 Michal Nowak 2009-03-16 22:18:44 UTC
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

Comment 47 Michal Nowak 2009-04-07 15:06:12 UTC
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

Comment 48 Michal Nowak 2009-05-07 10:06:50 UTC
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.

Comment 49 Michal Nowak 2009-05-13 08:48:15 UTC
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

Comment 50 Michal Nowak 2009-05-19 08:30:48 UTC
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

Comment 51 Michal Nowak 2009-05-28 11:13:17 UTC
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

Comment 52 Bernie Innocenti 2009-05-28 16:26:46 UTC
Is anyone providing a cairo package prebuilt with the xcb backend?

Comment 53 Michal Nowak 2009-05-28 16:52:25 UTC
I don't think so. It's quite easy to DIY.

Comment 54 Alexey Torkhov 2009-06-02 10:53:33 UTC
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?

Comment 55 Bernie Innocenti 2009-06-02 15:16:58 UTC
(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.

Comment 56 Alexey Torkhov 2009-06-03 21:25:43 UTC
(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.

Comment 58 Michal Nowak 2009-07-14 10:34:37 UTC
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.

Comment 59 Christian Krause 2009-07-14 22:43:56 UTC
(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...

Comment 60 Ben Boeckel 2009-07-27 03:40:23 UTC
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.

Comment 61 Michal Nowak 2009-08-03 09:32:04 UTC
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.

Comment 63 Jens Petersen 2009-09-13 08:05:00 UTC
Hmm, isn't it better to have some awesome2 than nothing?

Comment 64 Michal Nowak 2009-09-14 07:07:15 UTC
Jens: See Comment #61. In brief: awesome v2 is near to dead code, which I personally don't care.

Comment 65 Jens Petersen 2009-09-15 02:13:27 UTC
(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?

Comment 66 Michel Lind 2009-09-15 03:27:33 UTC
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?

Comment 67 Jens Petersen 2009-09-16 06:17:49 UTC
$ 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.

Comment 68 Jens Petersen 2009-09-16 08:22:21 UTC
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)

Comment 69 Michal Nowak 2009-09-16 10:55:01 UTC
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 ?

Comment 70 Michal Nowak 2009-09-16 10:58:11 UTC
(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.

Comment 71 Thomas Moschny 2009-09-16 12:27:12 UTC
(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.

Comment 72 Michal Nowak 2009-09-16 12:53:25 UTC
Thanks Thomas, fixed here: http://mnowak.fedorapeople.org/awesome/awesome-3.3.4-2.fc12.src.rpm (Builds fine in Mock.)

Comment 73 Michal Nowak 2009-09-16 14:27:43 UTC
(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.)

Comment 74 Jens Petersen 2009-09-17 01:42:49 UTC
You're right mock is fine and awesome3 is more awesome! :-)

Comment 75 Jens Petersen 2009-09-18 10:01:26 UTC
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 :)

Comment 76 Michal Nowak 2009-09-18 10:45:53 UTC
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.

Comment 77 Thomas Moschny 2009-09-18 21:14:45 UTC
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.)

Comment 78 Michal Nowak 2009-10-06 10:09:23 UTC
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.

Comment 79 Jens Petersen 2009-10-08 02:24:29 UTC
(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.)

Comment 80 Michal Nowak 2009-10-12 08:17:05 UTC
Updated awesome-3.4 to RC3 with path; untested, though.

Comment 81 Michal Nowak 2009-10-22 12:45:41 UTC
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.

Comment 82 Felipe Contreras 2009-10-25 12:27:46 UTC
Is there any chance of getting this on F12?

Comment 83 Christian Krause 2009-10-25 14:43:33 UTC
(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.

Comment 84 Felipe Contreras 2009-10-25 16:55:11 UTC
(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 =/

Comment 85 Bernie Innocenti 2009-10-26 03:04:21 UTC
(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?

Comment 86 Behdad Esfahbod 2009-10-26 21:36:44 UTC
Or just change awesome to use cairo-xlib.  What's wrong with doing that?

Comment 87 Bernie Innocenti 2009-10-27 00:17:57 UTC
(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.

Comment 88 Michal Nowak 2009-11-22 10:33:02 UTC
3.4.1 in fp.o: http://mnowak.fedorapeople.org/awesome/awesome-3.4.1-1.fc12.src.rpm

Comment 89 Thomas Moschny 2009-11-22 11:14:31 UTC
(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.

Comment 90 Michal Nowak 2009-11-23 11:20:29 UTC
Thanks for letting me know - re-uploaded now.

Comment 91 Michal Nowak 2009-12-02 10:21:00 UTC
3.4.2 in fp.o:
http://mnowak.fedorapeople.org/awesome/awesome-3.4.2-1.fc12.src.rpm

Comment 92 Michal Nowak 2010-01-04 23:01:48 UTC
3.4.3 in fp.o:
http://mnowak.fedorapeople.org/awesome/awesome-3.4.3-1.fc12.src.rpm

Comment 93 Michal Nowak 2010-03-04 22:39:39 UTC
3.4.4 in fp.o.
http://mnowak.fedorapeople.org/awesome/awesome-3.4.4-1.fc12.src.rpm

Comment 94 Bill McGonigle 2010-03-05 20:12:40 UTC
(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.

Comment 95 Jim Meyering 2010-05-10 17:51:47 UTC
any change/progress?
I've just built it from source twice, for F13.
It'd be nice not to have to do that.

Comment 96 Spencer Tom Tafadzwa Chirume 2010-05-10 18:07:32 UTC
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?

Comment 97 Michal Nowak 2010-05-13 21:14:08 UTC
(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.

Comment 98 Michal Nowak 2010-05-17 10:29:54 UTC
3.4.5 in fp.o.
http://mnowak.fedorapeople.org/awesome/awesome-3.4.5-1.fc13.src.rpm

Comment 99 Thomas Moschny 2010-06-04 11:27:16 UTC
Updated packages in http://thm.fedorapeople.org/awesome/ for F11, F12 and F13.

Comment 101 d. johnson 2010-08-02 19:26:08 UTC
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?)

Comment 102 Christian Krause 2010-08-02 19:59:14 UTC
(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.

Comment 103 d. johnson 2010-08-02 20:12:52 UTC
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.

Comment 104 Thomas Moschny 2010-08-02 20:28:41 UTC
(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).

Comment 107 Peter Lemenkov 2010-10-26 18:19:22 UTC
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.

Comment 108 Ben Boeckel 2010-10-26 18:28:42 UTC
(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).

Comment 109 Thomas Moschny 2010-10-28 13:48:57 UTC
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.

Comment 110 Jim Meyering 2010-10-28 21:19:19 UTC
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

Comment 111 Michal Nowak 2011-02-18 10:56:37 UTC
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...

Comment 112 Jim Meyering 2011-02-18 11:08:30 UTC
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.

Comment 113 Thomas Moschny 2011-02-18 12:00:42 UTC
(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.

Comment 114 Jim Meyering 2011-02-18 12:47:05 UTC
Thanks.  I've used those and do appreciate them.
If you were to do the same for rawhide, I would be all set ;-)

Comment 115 Thomas Moschny 2011-03-04 10:26:37 UTC
(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! :)

Comment 116 Michal Nowak 2011-05-16 15:47:49 UTC
3.4.10 is out. ...and I realized I don't care about awesome anymore.

Comment 117 Jim Meyering 2011-05-22 18:15:04 UTC
(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.

Comment 118 Jim Meyering 2011-05-25 14:12:28 UTC
I see there are now RPMs for awesome-3.4.10.  Thank you, Thomas.

Comment 119 Jim Meyering 2011-09-20 18:42:23 UTC
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 ;-)

Comment 120 Thomas Moschny 2011-09-27 16:41:27 UTC
(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.

Comment 121 Jim Meyering 2011-09-27 17:34:44 UTC
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?

Comment 122 Thomas Moschny 2011-09-28 19:29:14 UTC
Seems xsri has been retired, so I removed awesome's dependency on it.

Comment 123 Jim Meyering 2011-09-28 19:41:22 UTC
Now it installs without a hitch.  Thanks!

Comment 124 Jim Meyering 2011-10-17 08:48:35 UTC
I've now switched to F16+awesome on my desktop too.
Works well.  Thanks again.

Comment 125 Lars Kellogg-Stedman 2011-11-17 14:34:25 UTC
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.

Comment 126 Thomas Moschny 2011-11-18 10:42:02 UTC
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.

Comment 127 Lars Kellogg-Stedman 2011-11-18 14:43:58 UTC
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.

Comment 128 Jim Meyering 2011-11-18 15:09:59 UTC
This is where it'd be nice to have "recommends".
I use roxterm, so have no use for xterm.

Comment 129 Renato Botelho 2011-12-05 11:30:15 UTC
Is there any plans to have 3.4.11 on fedora repo?

Comment 130 Thomas Moschny 2011-12-05 14:52:07 UTC
(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.

Comment 131 Jim Meyering 2012-03-26 05:45:27 UTC
(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

Comment 132 Thomas Moschny 2012-04-12 20:43:37 UTC
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?

Comment 133 Jim Meyering 2012-04-13 16:31:07 UTC
Hi Thomas,
I've just installed it on F17/x86_64 and (as usual) it works perfectly.
Thanks again!

Comment 134 Stanislav Ochotnicky 2012-05-23 13:36:13 UTC
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.

Comment 135 Thomas Moschny 2012-05-23 13:49:16 UTC
(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.

Comment 136 Michal Nowak 2012-05-23 14:00:34 UTC
Not interested in maintaining the package; go ahead and file new BZ.

Comment 137 Thomas Moschny 2012-05-24 16:55:33 UTC
See bug 824949.

Comment 138 Peter Lemenkov 2012-05-27 06:55:42 UTC

*** This bug has been marked as a duplicate of bug 824949 ***

Comment 139 Rino Rondan 2012-12-06 19:34:23 UTC
Hi, someone are working this package ??

Regards

Comment 140 Peter Lemenkov 2012-12-06 19:45:07 UTC
(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

Comment 141 Rino Rondan 2012-12-06 19:48:07 UTC
This package is not on F17, so I think that was approved for F18.

Regards

Comment 142 Ben Boeckel 2012-12-06 19:57:36 UTC
There are only Koji builds for F18. I believe there were some libxcb version issues with getting it on F17.

Comment 143 Stanislav Ochotnicky 2012-12-07 08:27:40 UTC
(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


Note You need to log in before you can comment on or make changes to this bug.