[Exherbo-dev] Exherbo Impressions ~ From Installation to Uptime

Sess leycec at gmail.com
Thu Mar 4 05:38:58 GMT 2010


Dear Exherbons,

Firstly, fantastic job. I feel the dark cloud of the Gentoo Council lifting
already.

Secondly, I have a cache of comments concerning my first migration from
Gentoo to Exherbo with new hardware -- the compact, illustrious Dell Zino HD
400. Here we go.

{!} Paludis fails spectacularly after attempting to sync against
SuperHeron's "exherbo-misc" repository. So spectacularly, in fact, it
thereafter fails with the following error (regardless of which commands or
options I pass it):
Unhandled exception:
 * In program paludis -s x-superheron-misc:
 * When making environment from specification '':
 * When loading paludis configuration:
 * Repository 'SuperHeron-misc' depends upon 'mono', which is not configured
(paludis::ConfigurationError)
Solved by deleting the "/etc/paludis/repositories/superheron-misc.conf" I'd
manually added earlier. Simple, but I'd like to know why it failed this
catastrophically. (Enabling and disabling the "mono" option is of no help,
incidentally.)
{*} Having to manually add, configure, and sync unavailable repositories
after unsuccessfully attempting to install exheres from those repositories.
Repository hell, frankly. These are machine-automateable tasks and I'd like
to see paludis options to this effect. Ideally, I'd like paludis to
automatically add stock configuration files to "/etc/paludis/repositories/"
for unavailable repositories on trying to install exheres from those
repositories, sync those repositories, and re-attempt the exheres
installation. Doable?
{*} Stable exheres. There aren't any. Most exheres are known unstable and
marked as such, or otherwise known stable (...for most architectures for
most distros) and still marked unstable. The latter concern me. I'll gladly
submit patches, bug reports, et al. against the offending exheres for my
architecture ("amd64"), if desired. Alternately, a simpler solution suggests
itself: I'd like paludis to selectively unmask unstable exheres for my
architecture if and only if there exist no equivalent stable exheres for
that architecture. That is, I'd like paludis to globally unmask "*/* amd64"
and only unmask "=${PVR} ~amd64" as fallback when the former fails for
installing ${PVR}. Doable? (Already done?)
{*} Exherbo Wiki. Is this in the cards?
{*} Circular dependencies when building "firefox." Yes, there were more than
one. One loses count. Each involved the "gtk+" exheres in incestuous
entanglement with "gtk+"-dependent exheres like "cairo," "pango," and
"gnome." One example:
root> paludis -i firefox
Building target list...
Building dependency list: ... 72 steps
Dependency error:
  * In program paludis -i firefox:
  * When performing install action from command line:
  * When executing install task:
  * When building dependency list:
  * When adding PackageDepSpec 'net-www/firefox':
  * When adding package 'net-www/firefox-3.6:0::mozilla':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'dev-libs/xulrunner[~1.9.2]':
  * When adding package 'dev-libs/xulrunner-1.9.2:0::mozilla':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'x11-libs/libnotify[>=0.4]':
  * When adding package 'x11-libs/libnotify-0.4.5-r1:0::gnome':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'x11-libs/gtk+:2[>=2.6]':
  * When adding package 'x11-libs/gtk+-2.18.5:2::gnome':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'x11-libs/cairo[>=1.6][X]':
  * When adding package 'x11-libs/cairo-1.8.8-r1:0::x11':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'x11-libs/pixman[>=0.12.0]':
  * When adding package 'x11-libs/pixman-0.16.4:1::x11':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'x11-libs/gtk+:2':
  * Circular dependency: Atom 'x11-libs/gtk+:2' matched by merge list entry
'x11-libs/gtk+-2.18.5:2::gnome', which does not yet have its dependencies
installed (paludis::CircularDependencyError)
Solved by temporarily building "gtk+" with the "cups," "gtk," and "gnome"
options globally disabled. This was a hell of a dependency hell to resolve.
(I wonder where the true culprit lies...)
{*} Circular dependency when building "python" with "tk" locally enabled.
Output follows:
root> paludis -i python
Building target list...
Building dependency list: ... 39 steps, 13 metadata (12 x11, 1 arbor)
Dependency error:
  * In program paludis -i paludis:
  * When performing install action from command line:
  * When executing install task:
  * When building dependency list:
  * When adding PackageDepSpec 'sys-apps/paludis':
  * When adding package 'sys-apps/paludis-scm:0::arbor':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'dev-lang/python:=':
  * When adding package 'dev-lang/python-2.6.4:2.6::arbor':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'dev-lang/tk[>=8.0]':
  * When adding package 'dev-lang/tk-8.5.7:0::arbor':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'x11-libs/libX11':
  * When adding package 'x11-libs/libX11-1.3.2:0::x11':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'x11-libs/libxcb[>=1.1.92]':
  * When adding package 'x11-libs/libxcb-1.5:0::x11':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'x11-proto/xcb-proto[>=1.6]':
  * When adding package 'x11-proto/xcb-proto-1.6:0::x11':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'dev-lang/python:=[>=2.5]':
  * Circular dependency: Atom 'dev-lang/python:=[>=2.5]' matched by merge
list entry 'dev-lang/python-2.6.4:2.6::arbor', which does not yet have its
dependencies installed (paludis::CircularDependencyError)
Solved by temporarily building "python" without the "tk" option. Not ideal,
but I'll live.
{*} Circular dependency when building "kdelibs." I'm afraid I've lost the
output, however. The culprit was "libwww-perl" with the "ssl" option
enabled. Solved by building "libwww-perl" (...with the "ssl" option still
enabled, oddly!) independently, then building "kdelibs."
{*} Repository mask when building "gimp" with the "webkit" option enabled.
Output follows:
root> paludis -i gimp
Building target list...
Building dependency list: ... 113 steps
Query error:
  * In program paludis (--continue-on-failure if-satisfied --dl-blocks
accumulate --dl-circular error --dl-downgrade warning --dl-new-slots always
--dl-reinstall never --dl-reinstall-scm never --dl-reinstall-targets auto
--dl-suggested install --dl-upgrade always --log-level warning --multitask
--show-reasons summary --show-use-descriptions all
--show-package-descriptions new --with-unused-dependencies) -i gimp:
  * When performing install action from command line:
  * When executing install task:
  * When building dependency list:
  * When adding PackageDepSpec 'media-gfx/gimp':
  * When adding package 'media-gfx/gimp-2.6.8:0::rbrown':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'net-libs/webkit-gtk:1[>=1.1.0]':
  * When adding package 'net-libs/webkit-gtk-1.1.22:1::gnome':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'gnome-desktop/libsoup:2.4[>=2.29.90]':
  * All versions of 'gnome-desktop/libsoup:2.4[>=2.29.90]' are masked.
Candidates are:
    * gnome-desktop/libsoup-2.29.90:2.4::gnome: Masked by repository
(/var/db/paludis/repositories/gnome/metadata/repository_mask.conf: Saleem
Abdulrasool <compnerd at exherbo.org> GNOME 2.29 Mask)
Solved by temporarily building "gimp" with the "webkit" option globally
disabled. I understand what a repository mask is and why, generally, one
might use it: e.g., SCM-targeted exheres. I don't understand why a
repository mask was used here, though I'm sure there is a satisfactory
answer. In this case, "paludis -q libsoup" suggests SuperHeron's
"exherbo-misc" repository offers an unmasked exheres corresponding to a
newer (presumably, stabler) version. Of course, I can't sync against this
repository for aforementioned reasons. Disabling "webkit" was a workable
solution for now.
{*} Failing tests when building "python" (...and other exheres) with
"build_options: recommended_tests". Should I be concerned? e.g.,
test_hashlib
test_heapq
test_hmac
test_hotshot
test_htmllib
test_htmlparser
test_httplib
test_httpservers
sydbox at 1266766125: Access Violation!
sydbox at 1266766125: Child Process ID: 28893
sydbox at 1266766125: Child CWD:
/var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4
sydbox at 1266766125: Last Exec: execve("./python", ["./python", "-E", "-tt",
"./Lib/test/regrtest.py", "-l", "-w"])
sydbox at 1266766125: Reason: bind{family=AF_INET addr=0.0.0.0 port=0}
Exception in thread Thread-147:
Traceback (most recent call last):
  File
"/var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4/Lib/threading.py",
line 525, in __bootstrap_inner
    self.run()
  File
"/var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4/Lib/test/test_httpservers.py",
line 38, in run
    self.server = HTTPServer(('', 0), self.request_handler)
  File
"/var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4/Lib/SocketServer.py",
line 400, in __init__
    self.server_bind()
  File
"/var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4/Lib/BaseHTTPServer.py",
line 108, in server_bind
    SocketServer.TCPServer.server_bind(self)
  File
"/var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4/Lib/SocketServer.py",
line 411, in server_bind
    self.socket.bind(self.server_address)
  File "<string>", line 1, in bind
error: [Errno 99] Cannot assign requested address
I suspect this is "sydbox"-related, but haven't looked into it.
{*} "xorg-server" not a hard dependency of X.org-dependent exheres. Not a
single exheres pulled in "xorg-server". Simply solved, of course: "paludis
-i xorg-server". Everything works now. (Am I missing something?)
{*} No "lzma-utils" or "lzop" exheres, thus preventing usage of those kernel
compression schemes. (I'd prefer the kernel provide support for "xv". It
doesn't, of course.)
{*} No "ifplugd" exheres, although one did reside under "dev/rbrown.git". I
resurrected it manually. Is there a compelling reason not to use
[ifplugd|netplug] anymore? [Update: I suspect Genesis, when ready, might do
something similar. Is this the case?]
{*} No "nano" installed by default. Now, I encapsulate myself in "vim" as
much as the next geek. And I still find Exherbo's disclusion of "nano" a
wee... inhospitable. I doubt including "nano" would inflate the staging
archive much. This suggests religious reasons. Tell me I'm wrong. :}
{!} No "baselayout-2" or "openrc" exheres. Disappointing, but acceptable. I
note, however, the latest version of "udev::arbor" issues this warning four
(...or five) times on startup:
The udev init-script is written for baselayout-2!
Please do not use it with baselayout-1!.
Either this warning is ignorable (and thus omittable from "/etc/init.d/udev"
output) or not (and "udev::arbor" should thus be hard-dependent on a new
"baselayout-2::arbor" exheres). Probably more work than I want to
contemplate in the latter case. [Update: in trolling the "Exherbo-dev"
mailing list, I see you intend on rolling out a new initsystem from scratch:
Genesis. Not too unique of a name, but I'll live. How about a non-English
transliteration of "Genesis" to improve uniqueness? In Japanese, for
example, "Ikeru" crudely approximates this meaning. It's also unique. Is
there a roadmap for "Genesis" development?]
{*} No "/usr/portage/profile/use.desc" or
"/usr/portage/profile/use.local.desc" equivalents that I could find. I
prefer grepping files to grepping "--show-use-descriptions" output when
maintaining "/etc/paludis/options.conf". At the moment, I synchronize these
files against Gentoo repositories. Can they be brought into arbor? (Have
they already been brought into arbor? Currently, the only .desc file on my
system lives at
"/var/db/paludis/repositories/dev-rbrown/metadata/use.local.desc" and
consists of only one entry.) [Update: O.K.; I've RTFM. Option descriptions
now embedded within repositories and exheres themselves. That's good.
Repositories and exheres strewn about the "/var/db/paludis/repositories/"
subsystem, thus inhibiting grepping. That's bad. Would it be reasonable to
optionally auto-generate these files as a paludis post-sync hook?]
{*} "Master repositories are not inherited from masters." Why not? How are
inheritance conflicts with multiple masters handled? (Just curious, mostly.)
{*} MYOPTIONS syntax. It looks increasingly like a markup-based scripting
language: e.g., "[[ number-selected = exactly-one ]]". Reinventing the
wheel, mayhap? This looks to be a programmatic problem. I can't help but
feel a programmatic solution might be more appropriate. Tangentially: why
the "MY" prefix on "MYOPTIONS"?
{*} "distfiles." "DISTDIR" is renamed "FETCHEDDIR." Then, shouldn't
"distfiles" be renamed "fetchedfiles"? (A bit long. Drop the past tense,
perhaps? Perhaps as "A" is renamed "ARCHIVES," "DISTDIR" should more
properly be "ARCHIVEDIR.")
{*} Distfile mirroring. We could bundle distfiles within git repositories
(...specifically, in the "${FILES}" path for the exheres corresponding to
those distfiles). We could extend this to load balancing of distfile
mirrors, as well: e.g., via "git push --mirror" or "git-mirror" to GitHub-,
Gitorious-, and Exherbo-hosted mirror repositories.
{*} "cave." I'm not fond of the name... It's non-descriptive; it's
non-expressive; it's non-unique. Paludis. Pacman. Apt-get. Great names.
"cave"? I'd like to know the design impetus behind this one.
{*} "bash." "zsh" is moderately more powerful than "bash." Arguably, too
powerful. Any chance of a "zsh" port for the exheres-0 EAPI?
{!} "dhcpcd." The 5.x.x branch of "dhcpcd" is unstable and significantly
breaks backward compatibility with the 4.x.x branch. For example: passing
the "-N" option to dhcpcd 4.x.x prevents dhcpcd from overwriting
"/etc/ntp.conf"; passing the same option to dhcpcd 5.x.x produces the
(humorously misspelled) fatal error:
dhcpcd: unknown otpion 'eth0'
Yes. Fatal error. And it doesn't even reference the offending option.
Thanks, Roy Marple. On my 64-bit AMD machine, dhcpcd 5.x.x also tends to
enter "unkillable" process states where not even "kill -9" is sufficient to
kill a zombified dhcpcd process. I don't know what the proper Exherbo
protocol is here, but marking the dhcpcd 4.x.x branch stable for all
architectures would probably be a healthy start. Emitting a notice
concerning backward incompatibility at installation time of the dhcpcd 5.x.x
branch should probably also be helpful.
{!} "xinetd." "http://xinetd.org" was down as of my installation, thus
inducing that exheres (...and all exheres dependent on that) to fail with
fetch errors. I retrieved a copy of the latest source from:
ftp://mirror.ovh.net/gentoo-distfiles/distfiles/xinetd-2.3.14.tar.gz**
Can this be added as a fallback, in the event of "http://xinetd.org" falling
down again?
{!} "mysql." "mysql-5.1.42.tar.gz" is frustratingly unavailable from all
listed hosts. I found it odd this exheres didn't default to downloading from
"http://downloads.mysql.com/archive", where MySQL is always reliably
downloadable. The exheres should be (probably) patched to defer to:
http://downloads.mysql.com/archives/mysql-5.1/mysql-5.1.42.tar.gz
{*} "inquisitio." Still orders of magnitude slower than Gentoo's "eix."
Ideas why?
{*} Non-free firmware. My discrete Radeon HD4330 video card requires
non-free firmware, freely available at:
http://people.freedesktop.org/~agd5f/radeon_ucode/<http://people.freedesktop.org/%7Eagd5f/radeon_ucode/>.
I'd like to see non-free firmware optionally available via some repository
(if not conflicting with Exherbo policy) or otherwise discussed in Exherbo
documentation.
{*} Radeon HD4330. This card is effectively an HD4350 in disguise.
Interested parties may be... interested to know that stock X.org fails with
screen and keyboard lockup when enabling kernel support for KMS (Kernel
Modesetting) and DRM (Direct Rendering Management) for this card. Yes,
lockup. It even failed with lockup on "X -configure". Fortunately, this is
fixable as follows: *warning: tedious installation instructions*
{**} Upgrade to the latest mainline kernel (http://kernel.org).
{**} Download "R600_rlc.bin" and "R700_rlc.bin" from
http://people.freedesktop.org/~agd5f/radeon_ucode/<http://people.freedesktop.org/%7Eagd5f/radeon_ucode/>to
"/usr/src/linux/firmware/radeon".
{**} Enable these kernel options:

Device Drivers  --->
	Generic Driver Options  --->
		< > Select only drivers that don't need compile-time externel firmware
		<*> Userspace firmware loading support


		[*] Include in-kernel firmware blobs in kernel binary
		(radeon/R600_rlc.bin radeon/R700_rlc.bin) External firmware blobs to
build into the kernel binary
		(firmware) Firmware blobs root directory
	Graphics support  --->


		<*> /dev/agpgart (AGP Support)
			<*> {Choose support appropriate for your chipset}
		<*> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)  --->
			<*> ATI Radeon
				<*> Enable modesetting on radeon by default


		<*> Lowlevel video output switch controls
		-*- Support for frame buffer devices  --->
			[*] Enable firmware EDID
			[*] Enable Video Mode Handling Helpers
			[*] Enable Tile Blitting Support


{**} Disable all other kernel options under "Support for frame buffer
devices." (This is important. The "ATI Radeon" DRM driver provides its own
frame buffer driver entitled "radeondrmfb".)
{**} Recompile your kernel as usual and install to "/boot/". (Note: you'll
definitely want to keep a working backup of the prior kernel.)
{**} Remove all strings resembling "video=..." from "/boot/grub/grub.conf"
(Grub2) and "/boot/grub/menu.lst" (Grub1).
{**} Perform the customary goat sacrifice.
{**} Reboot. Assuming this worked...
{**} Unmask the SCM versions of "libdrm", "mesa", and "xf86-video-ati".
Specifically, add the following lines to "/etc/paludis/package_unmask.conf":
=x11-dri/libdrm-scm
=x11-dri/mesa-scm
=x11-drivers/xf86-video-ati-scm
{**} Reinstall these exheres. Specifically, run:
sudo paludis -i libdrm mesa xf86-video-ati
{**} That's it! Congratulations, intrepid bleeding edge explorer, your ATI
Radeon HD should now run without lockup. (This needs be stuffed into a Wiki.
Just let me know when and where.)

Frustrating installation overall. Chinese torture techniques ala "death by a
thousand cuts" felt apropos at times. Some of this was the inevitable fault
of installing bleeding-edge hardware. Most of this, however, was not. I
learned a great deal, but also consumed a great deal of time, abstract
blood, and actual sweat.

That said, I can't imagine returning to Gentoo. There's an anarchic beauty
to the rough stumbling chaos of Exherbo: it's compelling and should in time
catapult Exherbo into the limelight. I hope it does.

I'm happy to contribute on any or all of my concerns, supposing I have
sufficient time. Have an excellent week, tomodachi, and take care.

Humbly yours,
Cecil Curry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20100304/bf0a43b1/attachment.htm>


More information about the Exherbo-dev mailing list