Dear Exherbons,<br><br>Firstly, fantastic job. I feel the dark cloud of the Gentoo Council lifting already.<br><br>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.<br>













<br>{!} Paludis fails spectacularly after attempting to sync against SuperHeron&#39;s &quot;exherbo-misc&quot; repository. So spectacularly, in fact, it thereafter fails with the following error (regardless of which commands or options I pass it):<br>









Unhandled exception:<br> * In program paludis -s x-superheron-misc:<br> * When making environment from specification &#39;&#39;:<br> * When loading paludis configuration:<br> * Repository &#39;SuperHeron-misc&#39; depends upon &#39;mono&#39;, which is not configured (paludis::ConfigurationError)<br>









Solved by deleting the &quot;/etc/paludis/repositories/superheron-misc.conf&quot; I&#39;d manually added earlier. Simple, but I&#39;d like to know why it failed this catastrophically. (Enabling and disabling the &quot;mono&quot; option is of no help, incidentally.)<br>







{*} 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&#39;d like to see paludis options to this effect. Ideally, I&#39;d like paludis to automatically add stock configuration files to &quot;/etc/paludis/repositories/&quot; for unavailable repositories on trying to install exheres from those repositories, sync those repositories, and re-attempt the exheres installation. Doable?<br>











{*} Stable exheres. There aren&#39;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&#39;ll gladly submit patches, bug reports, et al. against the offending
exheres for my architecture (&quot;amd64&quot;), if desired. Alternately, a
simpler solution suggests itself: I&#39;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&#39;d like paludis to
globally unmask &quot;*/* amd64&quot; and only unmask &quot;=${PVR} ~amd64&quot; as fallback
when the former fails for installing ${PVR}. Doable? (Already done?)<br>{*} Exherbo Wiki. Is this in the cards?<br>{*} Circular dependencies when building &quot;firefox.&quot; Yes, there were more than one. One loses count. Each involved the &quot;gtk+&quot; exheres in incestuous entanglement with &quot;gtk+&quot;-dependent exheres like &quot;cairo,&quot; &quot;pango,&quot; and &quot;gnome.&quot; One example:<br>













root&gt; paludis -i firefox<br>Building target list... <br>Building dependency list: ... 72 steps<br>Dependency error:<br>  * In program paludis -i firefox:<br>  * When performing install action from command line:<br>  * When executing install task:<br>

  * When building dependency list:<br>  * When adding PackageDepSpec &#39;net-www/firefox&#39;:<br>  * When adding package &#39;net-www/firefox-3.6:0::mozilla&#39;:<br>  * When adding build dependencies as pre dependencies:<br>

  * When adding PackageDepSpec &#39;dev-libs/xulrunner[~1.9.2]&#39;:<br>  * When adding package &#39;dev-libs/xulrunner-1.9.2:0::mozilla&#39;:<br>  * When adding build dependencies as pre dependencies:<br>  * When adding PackageDepSpec &#39;x11-libs/libnotify[&gt;=0.4]&#39;:<br>

  * When adding package &#39;x11-libs/libnotify-0.4.5-r1:0::gnome&#39;:<br>  * When adding build dependencies as pre dependencies:<br>  * When adding PackageDepSpec &#39;x11-libs/gtk+:2[&gt;=2.6]&#39;:<br>  * When adding package &#39;x11-libs/gtk+-2.18.5:2::gnome&#39;:<br>

  * When adding build dependencies as pre dependencies:<br>  * When adding PackageDepSpec &#39;x11-libs/cairo[&gt;=1.6][X]&#39;:<br>  * When adding package &#39;x11-libs/cairo-1.8.8-r1:0::x11&#39;:<br>  * When adding build dependencies as pre dependencies:<br>

  * When adding PackageDepSpec &#39;x11-libs/pixman[&gt;=0.12.0]&#39;:<br>  * When adding package &#39;x11-libs/pixman-0.16.4:1::x11&#39;:<br>  * When adding build dependencies as pre dependencies:<br>  * When adding PackageDepSpec &#39;x11-libs/gtk+:2&#39;:<br>

  * Circular dependency: Atom &#39;x11-libs/gtk+:2&#39; matched by merge list entry &#39;x11-libs/gtk+-2.18.5:2::gnome&#39;, which does not yet have its dependencies installed (paludis::CircularDependencyError)<br>Solved by temporarily building &quot;gtk+&quot; with the &quot;cups,&quot; &quot;gtk,&quot; and &quot;gnome&quot; options globally disabled. This was a hell of a dependency hell to resolve. (I wonder where the true culprit lies...)<br>











{*} Circular dependency when building &quot;python&quot; with &quot;tk&quot; locally enabled. Output follows:<br>

root&gt; paludis -i python<br>Building target list... <br>Building dependency list: ... 39 steps, 13 metadata (12 x11, 1 arbor) <br>


Dependency error:<br>  * In program paludis -i paludis:<br>  * When performing install action from command line:<br>  * When executing install task:<br>  * When building dependency list:<br>  * When adding PackageDepSpec &#39;sys-apps/paludis&#39;:<br>
















  * When adding package &#39;sys-apps/paludis-scm:0::arbor&#39;:<br>  * When adding build dependencies as pre dependencies:<br>  * When adding PackageDepSpec &#39;dev-lang/python:=&#39;:<br>  * When adding package &#39;dev-lang/python-2.6.4:2.6::arbor&#39;:<br>
















  * When adding build dependencies as pre dependencies:<br>  * When adding PackageDepSpec &#39;dev-lang/tk[&gt;=8.0]&#39;:<br>  * When adding package &#39;dev-lang/tk-8.5.7:0::arbor&#39;:<br>  * When adding build dependencies as pre dependencies:<br>
















  * When adding PackageDepSpec &#39;x11-libs/libX11&#39;:<br>  * When adding package &#39;x11-libs/libX11-1.3.2:0::x11&#39;:<br>  * When adding build dependencies as pre dependencies:<br>  * When adding PackageDepSpec &#39;x11-libs/libxcb[&gt;=1.1.92]&#39;:<br>
















  * When adding package &#39;x11-libs/libxcb-1.5:0::x11&#39;:<br>  * When adding build dependencies as pre dependencies:<br>  * When adding PackageDepSpec &#39;x11-proto/xcb-proto[&gt;=1.6]&#39;:<br>  * When adding package &#39;x11-proto/xcb-proto-1.6:0::x11&#39;:<br>
















  * When adding build dependencies as pre dependencies:<br>  * When adding PackageDepSpec &#39;dev-lang/python:=[&gt;=2.5]&#39;:<br>  * Circular dependency: Atom &#39;dev-lang/python:=[&gt;=2.5]&#39; matched by merge list entry &#39;dev-lang/python-2.6.4:2.6::arbor&#39;, which does not yet have its dependencies installed (paludis::CircularDependencyError)<br>
















Solved by temporarily building &quot;python&quot; without the &quot;tk&quot; option. Not ideal, but I&#39;ll live.<br>{*} Circular dependency when building &quot;kdelibs.&quot; I&#39;m afraid I&#39;ve lost the output, however. The culprit was &quot;libwww-perl&quot; with the &quot;ssl&quot; option enabled. Solved by building &quot;libwww-perl&quot; (...with the &quot;ssl&quot; option still enabled, oddly!) independently, then building &quot;kdelibs.&quot;<br>







{*} Repository mask when building &quot;gimp&quot; with the &quot;webkit&quot; option enabled. Output follows:<br>root&gt; paludis -i gimp<br>Building target list... <br>Building 
dependency list: ... 113 steps<br>


Query error:<br>  * 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:<br>

  * When performing install action from command line:<br>  * When executing install task:<br>  * When building dependency list:<br>  * When adding PackageDepSpec &#39;media-gfx/gimp&#39;:<br>  * When adding package &#39;media-gfx/gimp-2.6.8:0::rbrown&#39;:<br>

  * When adding build dependencies as pre dependencies:<br>  * When adding PackageDepSpec &#39;net-libs/webkit-gtk:1[&gt;=1.1.0]&#39;:<br>  * When adding package &#39;net-libs/webkit-gtk-1.1.22:1::gnome&#39;:<br>  * When adding build dependencies as pre dependencies:<br>

  * When adding PackageDepSpec &#39;gnome-desktop/libsoup:2.4[&gt;=2.29.90]&#39;:<br>  * All versions of &#39;gnome-desktop/libsoup:2.4[&gt;=2.29.90]&#39; are masked. Candidates are:<br>    * gnome-desktop/libsoup-2.29.90:2.4::gnome: Masked by repository (/var/db/paludis/repositories/gnome/metadata/repository_mask.conf: Saleem Abdulrasool &lt;<a href="mailto:compnerd@exherbo.org" target="_blank">compnerd@exherbo.org</a>&gt; GNOME 2.29 Mask)<br>

Solved by temporarily building &quot;gimp&quot; with the &quot;webkit&quot; option globally disabled. I understand what a repository mask is and why, generally, one might use it: e.g., SCM-targeted exheres. I don&#39;t understand why a repository mask was used here, though I&#39;m sure there is a satisfactory answer. In this case, &quot;paludis -q libsoup&quot; suggests SuperHeron&#39;s &quot;exherbo-misc&quot; repository offers an unmasked exheres corresponding to a newer (presumably, stabler) version. Of course, I can&#39;t sync against this repository for aforementioned reasons. Disabling &quot;webkit&quot; was a workable solution for now.<br>











{*} Failing tests when building &quot;python&quot; (...and other exheres) with &quot;build_options: recommended_tests&quot;. Should I be concerned? e.g.,<br>




test_hashlib<br>test_heapq<br>test_hmac<br>test_hotshot<br>test_htmllib<br>test_htmlparser<br>test_httplib<br>test_httpservers<br>sydbox@1266766125: Access Violation!<br>sydbox@1266766125: Child Process ID: 28893<br>sydbox@1266766125: Child CWD: /var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4<br>
















sydbox@1266766125: Last Exec: execve(&quot;./python&quot;, [&quot;./python&quot;, &quot;-E&quot;, &quot;-tt&quot;, &quot;./Lib/test/regrtest.py&quot;, &quot;-l&quot;, &quot;-w&quot;])<br>sydbox@1266766125: Reason: bind{family=AF_INET addr=0.0.0.0 port=0}<br>
















Exception in thread Thread-147:<br>Traceback (most recent call last):<br>  File &quot;/var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4/Lib/threading.py&quot;, line 525, in __bootstrap_inner<br>    self.run()<br>
















  File &quot;/var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4/Lib/test/test_httpservers.py&quot;, line 38, in run<br>    self.server = HTTPServer((&#39;&#39;, 0), self.request_handler)<br>  File &quot;/var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4/Lib/SocketServer.py&quot;, line 400, in __init__<br>
















    self.server_bind()<br>  File &quot;/var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4/Lib/BaseHTTPServer.py&quot;, line 108, in server_bind<br>    SocketServer.TCPServer.server_bind(self)<br>  File &quot;/var/tmp/paludis/build/dev-lang-python-2.6.4/work/Python-2.6.4/Lib/SocketServer.py&quot;, line 411, in server_bind<br>
















    self.socket.bind(self.server_address)<br>  File &quot;&lt;string&gt;&quot;, line 1, in bind<br>error: [Errno 99] Cannot assign requested address<br>I suspect this is &quot;sydbox&quot;-related, but haven&#39;t looked into it.<br>

{*} &quot;xorg-server&quot; not a hard dependency of X.org-dependent exheres. Not a single exheres pulled in &quot;xorg-server&quot;. Simply solved, of course: &quot;paludis -i xorg-server&quot;. Everything works now. (Am I missing something?)<br>








{*} No &quot;lzma-utils&quot; or &quot;lzop&quot; exheres, thus preventing usage of those kernel compression schemes. (I&#39;d prefer the kernel provide support for &quot;xv&quot;. It doesn&#39;t, of course.)<br>{*} No &quot;ifplugd&quot; exheres, although one did reside under &quot;dev/rbrown.git&quot;.
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?]<br>
{*} No &quot;nano&quot; installed by default. Now, I encapsulate myself in &quot;vim&quot; as much as the next geek. And I still find Exherbo&#39;s disclusion of &quot;nano&quot; a wee... inhospitable. I doubt including &quot;nano&quot; would inflate the staging archive much. This suggests religious reasons. Tell me I&#39;m wrong. :}<br>















{!} No &quot;baselayout-2&quot; or &quot;openrc&quot; exheres. Disappointing, but acceptable. I note, however, the latest version of &quot;udev::arbor&quot; issues this warning four (...or five) times on startup:<br>The udev init-script is written for baselayout-2!<br>













Please do not use it with baselayout-1!.<br>Either this warning is ignorable (and thus omittable from &quot;/etc/init.d/udev&quot; output) or not (and &quot;udev::arbor&quot; should thus be hard-dependent on a new &quot;baselayout-2::arbor&quot; exheres). Probably more work than I want to contemplate in the latter case. [Update: in trolling the &quot;Exherbo-dev&quot; mailing list, I see you intend on rolling out a new initsystem from scratch: Genesis. Not too unique of a name, but I&#39;ll live. How about a non-English transliteration of &quot;Genesis&quot; to improve uniqueness? In Japanese, for example, &quot;Ikeru&quot; crudely approximates this meaning. It&#39;s also unique. Is there a roadmap for &quot;Genesis&quot; development?]<br>














{*} No &quot;/usr/portage/profile/use.desc&quot; or &quot;/usr/portage/profile/use.local.desc&quot; equivalents that I could find. I prefer grepping files to grepping &quot;--show-use-descriptions&quot; output when maintaining &quot;/etc/paludis/options.conf&quot;. 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 &quot;/var/db/paludis/repositories/dev-rbrown/metadata/use.local.desc&quot; and consists of only one entry.) [Update: O.K.; I&#39;ve RTFM. Option descriptions now embedded within repositories and exheres themselves. That&#39;s good. Repositories and exheres strewn about the &quot;/var/db/paludis/repositories/&quot; subsystem, thus inhibiting grepping. That&#39;s bad. Would it be reasonable to optionally auto-generate these files as a paludis post-sync hook?]<br>




{*} &quot;Master repositories are not inherited from masters.&quot; Why not? How are inheritance conflicts with multiple masters handled? (Just curious, mostly.)<br>{*} MYOPTIONS syntax. It looks increasingly like a markup-based scripting language: e.g., &quot;<code>[[ number-selected = exactly-one ]]</code>&quot;. Reinventing the wheel, mayhap? This looks to be a programmatic problem. I can&#39;t help but feel a programmatic solution might be more appropriate. Tangentially: why the &quot;MY&quot; prefix on &quot;MYOPTIONS&quot;?<br>




{*} &quot;distfiles.&quot; &quot;DISTDIR&quot; is renamed &quot;FETCHEDDIR.&quot; Then, shouldn&#39;t &quot;distfiles&quot; be renamed &quot;fetchedfiles&quot;? (A bit long. Drop the past tense, perhaps? Perhaps as &quot;A&quot; is renamed &quot;ARCHIVES,&quot; &quot;DISTDIR&quot; should more properly be &quot;ARCHIVEDIR.&quot;)<br>



{*} Distfile mirroring. We could bundle distfiles within git repositories (...specifically, in the &quot;${FILES}&quot; path for the exheres corresponding to those distfiles). We could extend this to load balancing of distfile mirrors, as well: e.g., via &quot;git push --mirror&quot; or &quot;git-mirror&quot; to GitHub-, Gitorious-, and Exherbo-hosted mirror repositories.<br>




{*} &quot;cave.&quot; I&#39;m not fond of the name... It&#39;s non-descriptive; it&#39;s non-expressive; it&#39;s non-unique. Paludis. Pacman. Apt-get. Great names. &quot;cave&quot;? I&#39;d like to know the design impetus behind this one.<br>




{*} &quot;bash.&quot; &quot;zsh&quot; is moderately more powerful than &quot;bash.&quot; Arguably, too powerful. Any chance of a &quot;zsh&quot; port for the exheres-0 EAPI?<br>






{!} &quot;dhcpcd.&quot; The 5.x.x branch of &quot;dhcpcd&quot; is unstable and significantly breaks backward compatibility with the 4.x.x branch. For example: passing the &quot;-N&quot; option to dhcpcd 4.x.x prevents dhcpcd from overwriting &quot;/etc/ntp.conf&quot;; passing the same option to dhcpcd 5.x.x produces the (humorously misspelled) fatal error:<br>











dhcpcd: unknown otpion &#39;eth0&#39;<br>Yes. Fatal error. And it doesn&#39;t even reference the offending option. Thanks, Roy Marple. On my 64-bit AMD machine, dhcpcd 5.x.x also tends to enter &quot;unkillable&quot; process states where not even &quot;kill -9&quot; is sufficient to kill a zombified dhcpcd process. I don&#39;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.<br>










{!} &quot;xinetd.&quot; &quot;<a href="http://xinetd.org" target="_blank">http://xinetd.org</a>&quot; 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:<br>










<a href="ftp://mirror.ovh.net/gentoo-distfiles/distfiles/xinetd-2.3.14.tar.gz" target="_blank">ftp://mirror.ovh.net/gentoo-distfiles/distfiles/xinetd-2.3.14.tar.gz</a><i></i><br>Can this be added as a fallback, in the event of &quot;<a href="http://xinetd.org" target="_blank">http://xinetd.org</a>&quot; falling down again?<br>










{!} &quot;mysql.&quot; &quot;mysql-5.1.42.tar.gz&quot; is frustratingly unavailable from all listed hosts. I found it odd this exheres didn&#39;t default to downloading from &quot;<a href="http://downloads.mysql.com/archive" target="_blank">http://downloads.mysql.com/archive</a>&quot;, where MySQL is always reliably downloadable. The exheres should be (probably) patched to defer to:<br>










<a href="http://downloads.mysql.com/archives/mysql-5.1/mysql-5.1.42.tar.gz" target="_blank">http://downloads.mysql.com/archives/mysql-5.1/mysql-5.1.42.tar.gz</a><br>
{*} &quot;inquisitio.&quot; Still orders of magnitude slower than Gentoo&#39;s &quot;eix.&quot; Ideas why?<br>

{*} Non-free firmware. My discrete Radeon HD4330 video card requires non-free firmware, freely available at: <a href="http://people.freedesktop.org/%7Eagd5f/radeon_ucode/" target="_blank">http://people.freedesktop.org/~agd5f/radeon_ucode/</a>. I&#39;d like to see non-free firmware optionally available via some repository (if not conflicting with Exherbo policy) or otherwise discussed in Exherbo documentation.<br>












{*} 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 &quot;X -configure&quot;. Fortunately, this is fixable as follows: *warning: tedious installation instructions*<br>


{**} Upgrade to the latest mainline kernel (<a href="http://kernel.org" target="_blank">http://kernel.org</a>).<br>{**} Download &quot;R600_rlc.bin&quot; and &quot;R700_rlc.bin&quot; from <a href="http://people.freedesktop.org/%7Eagd5f/radeon_ucode/" target="_blank">http://people.freedesktop.org/~agd5f/radeon_ucode/</a> to &quot;/usr/src/linux/firmware/radeon&quot;.<br>


{**} Enable these kernel options:<br><pre>Device Drivers  ---&gt;<br>        Generic Driver Options  ---&gt;<br>                &lt; &gt; Select only drivers that don&#39;t need compile-time externel firmware<br>                &lt;*&gt; Userspace firmware loading support<br>


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


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


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


</pre>{**} Disable all other kernel options under &quot;Support for frame buffer devices.&quot; (This is important. The &quot;ATI Radeon&quot; DRM driver provides its own frame buffer driver entitled &quot;radeondrmfb&quot;.)<br>


{**} Recompile your kernel as usual and install to &quot;/boot/&quot;. (Note: you&#39;ll definitely want to keep a working backup of the prior kernel.)<br>
{**} Remove all strings resembling &quot;video=...&quot; from &quot;/boot/grub/grub.conf&quot; (Grub2) and &quot;/boot/grub/menu.lst&quot; (Grub1).<br>{**} Perform the customary goat sacrifice.<br>{**} Reboot. Assuming this worked...<br>


{**} Unmask the SCM versions of &quot;libdrm&quot;, &quot;mesa&quot;, and &quot;xf86-video-ati&quot;. Specifically, add the following lines to &quot;/etc/paludis/package_unmask.conf&quot;:<br>=x11-dri/libdrm-scm<br>=x11-dri/mesa-scm<br>


=x11-drivers/xf86-video-ati-scm<br>{**} Reinstall these exheres. Specifically, run:<br>sudo paludis -i libdrm mesa xf86-video-ati<br>{**} That&#39;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.)<br>


<br>Frustrating installation overall. Chinese torture techniques ala &quot;death by a thousand cuts&quot; 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.<br>

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










<br>I&#39;m happy to contribute on any or all of my concerns, supposing I have sufficient time. Have an excellent week, tomodachi, and take care.<br><br>Humbly yours,<br>Cecil Curry<br>