Awesome WM requires a library (runtime only) that is not present in portage. Otherwise the modules beautiful and gears fail to load and they cannot be trivially removed from the default config. Reproducible: Always Steps to Reproduce: 1. Install awesome 2. Run awesome with default config without lgi installed 3. Actual Results: Awesome fails to start due to not finding lgi.lua Expected Results: Awesome running without problems. An attempt at an lgi ebuild: # Copyright 1999-2012 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/dev-lua/luaexpat/luaexpat-1.2.0-r1.ebuild,v 1.5 2012/09/30 12:03:55 djc Exp $ EAPI=4 inherit eutils DESCRIPTION="Lua bindings using gobject-introspection" HOMEPAGE="http://github.com/pavouk/lgi" SRC_URI="http://github.com/downloads/pavouk/lgi/${P}.tar.gz" LICENSE="MIT" SLOT="0" KEYWORDS="~amd64 ~x86" IUSE="" RDEPEND=">=dev-lang/lua-5.1 x11-libs/gtk+[introspection]" DEPEND="${RDEPEND} virtual/pkgconfig" src_install() { emake DESTDIR="${D}" install dodoc README.md dohtml -r docs/* }
As you may have noticed from the header the ebuild is copied from something else and modified.
Please don't paste ebuilds into comments, but attach them to the bug instead; this is to avoid bugs from becoming unreadable over time as well as to make it easier to download them. Anyhow, assigned to the maintainers and increased severity because multiple users experience this.
The maintainers should have read this page before releasing the update: https://awesome.naquadah.org/wiki/Awesome_3.4_to_3.5
that page was only updated to talk about LGI after the update was released in the tree and I contacted the awesome devs on IRC so the maintainers could not have read that part. They should how ever has tested it to make sure it at least started up.
Bah, it started here as I already had lgi on my system. I'll clean up my LGI ebuild and put it in the tree.
Could anyone pretty-bloody-please mask completely and utterly broken package at last? It has become a habit for me to test upgraded awesome before restarting full session, so no harm done here, but more and more people stumble upon it every day.
my lgi is in the tree now, also a bump of awesome for the luadocs.
(In reply to comment #7) > my lgi is in the tree now, also a bump of awesome for the luadocs. Not good at all. Old rc.lua, even after migrating as explained in comment #3, makes awesome crash because of errors with beautiful and naughty. Please *destroy this ebuild* before it will provoke a genocide of awesome users.
i think that is a little harsh. Awesome has made alot of changes so problems are expected. If it works with the default config(as it should cause it works with my config) then the ebuild is fine. Any other issues should be reported to the awesome devs. they are very responsive on the irc chanel. So load up with the default config and set up Xephyr to test your custom config.
I agree with Marc, 3.4 config was expected to be broken. Use kdiff3 (or similar three-way merging tool) to merge changes: % kdiff3 ${VANILLA_3.4}.lua ${YOUR_3.4} ${VANILLA_3.5}.lua -o rc_new.lua
The problem is not my custom config, because awesome fails at these lines: naughty.config.presets.normal.opacity = 0.8 (it reports naughty is nil) beautiful.init(awful.util.getdir("config") .. "/themes/my-theme/theme.lua") (it reports beautiful is nil) Obviously in the first lines of rc.lua there is: require("beautiful") require("naughty") As you can see, there is nothing esoteric in my conf. IMHO this ebuild should be masked and a thorough testing of at least the most basic libraries should be done before unmasking it again.
(In reply to comment #11) > The problem is not my custom config It is. > Obviously in the first lines of rc.lua there is: > require("beautiful") > require("naughty") http://git.naquadah.org/?p=awesome.git;a=blob;f=awesomerc.lua.in;h=440bf7656b614651699fa39139b41772e3617420;hb=HEAD#l11
I'll wait for the next update to try to migrate my conf again. But even if you are sure that the problem is in my config, I insist that this ebuild should provide a link to a *good* conf migration guide or, if there is no one at the moment, it should be definitely masked. Upgrade guides (when conf syntax changes) have always been a good practice in gentoo and I think that people cannot be left with a broken environment due to lack of documentation. Sorry form my harshness, but having been a gentoo user (and promoter) for at least the last 10 years I'ld like it to bee competitive with the other distros in terms of QA, as I know it CAN be.
> But even if you are sure that the problem is in my config Absolutely. Few hours ago I saw awesome 3.5 working on my box (with vanilla rc.lua, of course). Also see how I had fixed my rc.lua for vicious upgrade: https://bitbucket.org/skrattaren/awesome/changeset/f8260b984babaa5872ae322961d096e9 As for masking until migration guide is ready... I don't think it's neccessary for awesome, really. It's not system or massively user-friendly DEs like KDE or something, after all.
(In reply to comment #13) > Sorry form my harshness, but having been a gentoo user (and promoter) for at > least the last 10 years I'ld like it to bee competitive with the other > distros in terms of QA, as I know it CAN be. Awesome has been known to break user config files on version bumps, even minor ones. It is unfortunate, but using it means you (should) know that you'll have to migrate each time (or mask updates). Upstream is aware of it (they're causing it ;p), we can't do much about it :)
