Exherbo

I finally sat down and wrote support for drawing the Burning Ship Fractal into gmandel. It only took a couple of minutes, but I haven’t really had spare time lately. Some parts of the fractal are quite interesting and different from other fractals ... [More] derived from the Mandelbrot set. Here are some pictures using gmandel: — fpereda Tagged: burningship, chaos, fractal, gmandel [Less]

Just a quick note that I left all gentoo IRC channels for good as a few gentoo developers are always either putting words in my mouth or attacking me in silly ways when I try to participate in technical discussions. I have absolutely no inclination ... [More] of getting dragged down to that level so I've simply left all the channels now.If anybody needs my help I'm sure you know where to find me but please consider carefully if it has any relation to gentoo before contacting me and DON'T contact me if the answer is yes. Thanks for your consideration. [Less]

During his various talks Bryan has mentioned the use of unofficial topic repositories in Exherbo - repositories hosting packages related to a specific topic that are either mostly or completely maintained by non-developers (and by non-developers I ... [More] mean people who cannot push to the official Exherbo repositories). So far, we haven’t really seen any of those mainly because most people have just kept packages in their own repositories. It gets tedious to add a lot of personal repositories just to get the latest and greatest packages people maintain though and at the end of the day it’s easier to collaborate and coordinate efforts if we can keep the related packages together, so we’ve (and by we I really mean Ali Polatel) created a media-unofficial repository hosted at github. So far alip, replica and I have pushed our media-related packages there and the repository currently contains stuff like Audacity, ncmpcpp and envtag. Now, the point of a topic repository isn’t to give any and all push access - we want to exert a proper level of QA, even if it is an unofficial repo. But as with the official ones, pinging one of us with a decent git format-patch is all you need to contribute stuff. If you want to contribute a new media-related package, please consider whether it would be better off in -unofficial. Keeping the number of packages that we (and by we I mean Exherbo developers) have to maintain is essential if we want to continue keeping the number of developers (and by developers I mean non-non-developers) near-constant (and we want that). The name media-unofficial does not imply that the packages are of a lesser quality than those in media.git, it does not imply that Exherbo developes want nothing to do with them, it does not imply that the packages are of dubious legality. The packages in that repository are maintained by smart people (including current Exherbo developers and current and former Gentoo developers) and we expect the quality to be as good as any official Exherbo repository. I like the idea of topic repositories when it’s possible to draw a somewhat clear line between relevant and irrelevant packages. The whole notion of restricting who can directly touch a set of packages should help keep people from stepping on each others toes while still letting those who want to do really crazy stuff with their packages (and keep them private thankyouverymuch) do that just by copying the exheres’ to their own repositories. I hope we will see more of these as Exherbo grows - repositories maintained by groups of users and (optionally) a couple of Exherbo devs. They do all the work and we take all the credit! Oh, and regarding that last sentence… anyone who wants to start an unofficial scientific repository and add all those things I’ve been too lazy to package? Pretty please? [Less]

Irssi version 0.8.13 release candidate 1 has just been released. Please help the Irssi team by downloading and testing it. Check the NEWS file included in the tarball or here for a list of all the changes.

envtag-0.1 is released, you can grab it here. envtag is a simple audio tagger for use in shell scripts. For more information see the README.

Here is a brief summary of kloeri’s fosdem talk. This is the result of an attempt to understand audacity and audio editing better.

My retirement from Gentoo is complete now. Good luck to everybody. I hope some people understand the real needs of Gentoo and where it should go. Even if I’m not planning to come back to Gentoo (either as a user or as a developer), I certainly hope the best for it. Cheers. — ferdy Tagged: gentoo

Potential users often ask whether Exherbo is stable. To test this, I decided to reinstall everything on my Gentoo desktop and my Exherbo laptop. The results are as follows: For Exherbo: Summary of failures: * net-misc/neon-0.28.3:0::arbor: failure ... [More] * dev-perl/IO-Socket-SSL-1.17:0::arbor: failure * sys-apps/upstart-0.3.9:0::arbor: failure Total: 390 packages, 387 successes, 0 skipped, 3 failures, 0 unreached For Gentoo: Summary of failures: * sys-devel/flex-2.5.35:0::gentoo: failure * sys-apps/coreutils-6.10-r2:0::gentoo: failure * sys-libs/glibc-2.9_p20081201-r2:2.2::gentoo: failure * dev-util/dejagnu-1.4.4-r1:0::gentoo: failure * sys-devel/automake-1.9.6-r2:1.9::gentoo: failure * dev-python/numeric-24.2-r6:0::gentoo: failure * app-misc/g15daemon-1.9.5.3-r2:0::gentoo: failure * app-misc/g15mpd-1.0.0:0::gentoo: skipped (dependency '>=app-misc/g15daemon-1.9.0' unsatisfied) * dev-libs/boost-1.35.0-r2:0::gentoo: failure * dev-libs/xerces-c-3.0.1:0::gentoo: failure * dev-libs/xqilla-2.2.0:0::gentoo: skipped (dependency '>=dev-libs/xerces-c-3.0.1' unsatisfied) * dev-util/bzr-1.12:0::gentoo: failure * dev-util/mercurial-1.0.2:0::gentoo: failure * media-video/mplayer-20090226.28734:0::gentoo: failure * www-servers/lighttpd-1.4.20:0::gentoo: failure * x11-wm/compiz-0.7.8-r2:0::gentoo: failure Total: 833 packages, 817 successes, 2 skipped, 14 failures, 0 unreached From this highly objective and totally fair study, we can conclude that Exherbo ~arch is 99.2% stable, whereas Gentoo ’stable’ is merely 98.1% stable. This, alongside Exherbo’s worryingly disappearing lack of documentation, is an unfortunate trend that must be corrected before things start to get out of hand. I look forward to breaking everything at the earliest available opportunity. Posted in exherbo, gentoo Tagged: exherbo, gentoo [Less]

Donnie has taken time out of his busy schedule of managing Gentoo to comment on some possible design issues for EAPI 3. He believes that adding support for exheres-0 style DEFAULT_ parameters to ebuilds would result in a less intuitive packaging ... [More] system, which he considers bad. Unfortunately, both the term ‘intuitive’ and the conclusion are nonsense. Ebuilds are not intuitive, intuitiveness would not be a useful property for them to have, and allowing parametrisation of default_ functions would not alter any of this. The only truly intuitive interface is the nipple. – Jay Vollmer Let’s look at what intuitive means: in⋅tu⋅i⋅tive /ɪnˈtuɪtɪv, -ˈtyu-/ [in-too-i-tiv, -tyoo-] -adjective perceiving by intuition, as a person or the mind. perceived by, resulting from, or involving intuition: intuitive knowledge. having or possessing intuition: an intuitive person. capable of being perceived or known by intuition. Ok, let’s look at intuition: in⋅tu⋅i⋅tion /ˌɪntuˈɪʃən, -tyu-/ [in-too-ish-uhn, -tyoo-] –noun direct perception of truth, fact, etc., independent of any reasoning process; immediate apprehension. a fact, truth, etc., perceived in this way. a keen and quick insight. the quality or ability of having such direct perception or quick insight. So apparently Donnie wants people to be able to write ebuilds without requiring rational thought. Whilst that would go some way towards explaining the state of the tree, it’s evident that ebuilds are not currently intuitive and should not be made intuitive. What qualities, then, should ebuild design aspire to? Let’s start with these: Ebuilds should be as obvious as reasonably possible, given the complications of the underlying packaging system and the overall design requirements, to a person with an appropriate level of skill and access to the documentation. Ebuilds should work to reduce the amount of boilerplate and cut-and-paste duplication required. Ebuilds should take steps to catch and prevent common errors. Looking at the first point, one may think it is too weak a requirement — why not “ebuilds should be accessible to your average user”? But then, why should it be? If you think the average user should have to write ebuilds to be able to get their package manager to track a package they can build by hand — why? Why not simply improve the package manager to be able to track hand-built packages without ebuilds? If you think the average user should be able to modify ebuilds to add in patches — why? Why not simply improve the package manager to make it easy for the user to add in patches to existing packages? If you think it will help solve the developer shortage problem — why? There’s no shortage of badly written ebuilds sitting around in bugzilla; making it easier to create more badly written ebuilds won’t fix this. The problem Gentoo faces is how to get more high quality ebuilds, and doing that requires skilled developers who have read and understood the documentation. Introducing DEFAULT_ parameters has no major effect either way on the first point. The second and third points are where DEFAULT_ parameters kick in. The reason the default src_configure does something as opposed to nothing is that the something it does is enough for many ebuilds. If instead it were a no-op, a typical simple ebuild would be considerably longer. Except, these days a lot of ebuilds have a few simple configure options controlled by use flags, so the default src_configure in EAPI 2 (or src_compile in EAPIs 0 and 1) is no good. DEFAULT_ parameters bring this proportion way down. This brings us to why the default src_install is a no-op. For most packages, something along the lines of “if there’s a Makefile, make DESTDIR="${D}" install” is not enough. For a good proportion of packages, though, that plus an ebuild-supplied list of doc files would suffice. Donnie claims that specifying things in variables this way is a major change in how ebuilds work. But there are already plenty of examples of things done in this style: The S variable is a declarative parameter to the package manager’s “before we run a phase” functions. Lots of eclasses make use of a DOCS variable. Indeed, nearly all parameterisation of eclasses is done through variables. It could just as easily be done by callback or overridable functions, but developers haven’t opted to do so. A perfect example of that last point: Donnie’s own x-modular eclass has a variable named PATCHES, which ebuilds set in global scope. If x-modular were using EAPI 3 with a src_prepare and exheres-0 style declarative patches lists, the package manager would already be providing exactly what he’s gone out of his way to implement. So what gives, Donnie? Do you think your use of PATCHES was a design mistake that you will be correcting? And do you think all those other developers who have been doing the same kind of thing for years are fundamentally wrong? Posted in eapi 3 Tagged: eapi 2, eapi 3, exheres-0, gentoo, intuitive [Less]

I retired from gentoo. Just to make sure everyone learns about it.