 Welcome to Gentoo Universe, an aggregation of weblog articles on all topics written by Gentoo developers. For a more refined aggregation of Gentoo-related topics only, you might be interested in Planet Gentoo.
October 03, 2009
I recently had a bit of downtime on my linode. If you are wondering what a 'linode' is, check out my review or the website. And a big thank you to the folks that used my referral code when they got setup with linode themselves, you guys rock!
So, about my recent 1/2 day downtime. It was self-inflicted because I wanted to move to a different datacenter. I moved my linode from Newark, NJ to Dallas, TX. It is quite a long story, but it boils down to a problem with my ISP (Comcast). I was only able to pull 100K/s from the Newark datacenter and 2-3M/s from the others. This was unacceptable. I tried to get it escalated past Comcast's frontline support but they kept asking me questions like "Do you use a router? If so, each computer only gets 1/2 the speed" & "Every computer is different. I'm glad that you can get 3M/s from another host, that is really good" Sigh.
At least Linode's customer server was helpful and allowed me to work around the ISP. The steps to move a linode are as follows:
- File a support request. (My initial request was answered in 11 minutes)
- Shutdown your linode
- Hit the 'migrate' button, after support sets up your migration
- Wait for the transfer. My total transfer time was ~43 minutes (~6G to transfer). This was pretty fast throughput, in my opinion
- Meanwhile, update your DNS for your new IP.
- Since you can queue up a boot job, I just let it go and checked in on it a couple hours later. Magic, it was online.
So, to finish the story off. Linode++, Comcast--. I wish I didn't need to do something like this, I wish my ISP was...I don't know...smart?
|
I've been busy collecting some really great stories from people using Gentoo in places that I really didn't expect.
Some of them want to remain anonymous, which I have no issue with. But there are some gems like this one:
==========
Hey, I'm the CTO of a small company in Sweden, and this is our short
'success story' :-)
blogg.se is a Swedish blogging platform which generate 130 000 new
entries, 150 000 comments and 2 500 new accounts on a daily basis. We
currently (September 25th, 2009) have a reach of 2,2M unique visitors
per week.
Gentoo has always been the preferred OS choice for us. We (the
developers) were all attracted by its 'sane' defaults and clean
approach to software deployment.
Here at blogg.se we use Gentoo for all our staging, testing and
production environments. We have about 30 running instances on 32-bit,
64-bit and KVM-virtualized hardware.
Gentoo (and its wide ecosystem of utils) has been very helpful in
helping us plan our environment. We use layman to distribute our own
software, Metro for building custom images and a wide range of apps
for maintaining our installs.
The collaborative efforts of Gentoo is inspiring and something you
want to be a part of. I'm already involved through the Sunrise-overlay
and hopefully qualifying as a Gentoo developer some time soon.
Johan Bergström
CTO blogg.se
===========
That's quite awesome on multiple levels, and I thank Johan for sharing this short glimpse at how people leverage Gentoo.
I hope to publish a few more stories soon, so stay tuned and feel free to mail me
your story!
|
**fixing bugs with both users and devs together.
Join us in #gentoo-bugs on Freenode, please!
|
ripping vhs (October 03, 2009, 15:17 UTC)
I don't think I've ever written about how to rip a VHS tape before, so I figured I'd write up a quick guide since it looks like that's part of what I'm gonna be doing this weekend. Yet another item I've long had on my todo list was to get a digital copy of some really old tapes put out by my church, since they were never released on DVD. Fortunately, it's really easy if you have a TV tuner card.
I'm using a Hauppauage PVR-500 card, which has composite inputs on the rear, and that's how I'm capturing the feed. That good old analog hole. Although, ideally, the Macrovision DRM shouldn't allow that, so don't ask me how it's working.
Anyway, it's simply a matter of switching your input to the component input, and then using ffmpeg to capture the stream.
To change the input, you'll need the IVTV utitiles. In my case, the command is:
$ v4l2-ctl -i 2
Then, with ffmpeg, you can capture the stream, just copying it and saving it in its native format. My PVR card does hardware encoding to MPEG2 video and audio, so I can just save it directly.
$ ffmpeg -i /dev/video0 -vcodec copy -acodec copy -t <hours:minutes> vhs.mpg
And thar ya go. Pretty simple.

Here's a screenshot from an old church video. As you can see, its slightly grainy, but that's because of the source, not because of the transfer. It would look just as good / bad on the VCR player itself, so the conversion actually works really well.
Edit: I thought I'd add a bit more technical details as far as the MPEG encoder goes.
The video is MPEG-2, and the bitrate is 8000 kb/s. The framerate is NTSC, of course. The picture is 720x480 in size (my snapshot above is scaled down for presentation).
The audio is encoded to MP2, and it keeps the stereo stream. The bitrate is 224 kb/s.
|
October 02, 2009
flame@yamato bzr % bzr branch http://bzr.savannah.nongnu.org/r/man-db
http://bzr.savannah.nongnu.org/r/man-db/ is permanently redirected to http+urllib://bzr.savannah.gnu.org/r/man-db/
bzr: ERROR: Not a branch: "http+urllib://bzr.savannah.gnu.org/r/man-db/.bzr/branch/".
The command is copy-pasted from Savannah …
And yes, this was trying to fix man-db with heirloom-doctools .
|
Does it come with includes or? (October 02, 2009, 15:40 UTC)
I’m not sure if I went to a large extent writing about this before, but I probably should try to write about it here again, because, once again, it helps removing some useless .la files from packages (and again, this is just something done right, not something I’m pulling out of thin air; if you think I’m pulling it out of thin air, you have no clue about libtool to begin with — and I’m not referring to leio’s complains, that’s another topic entirely).
Shared objects are, generally, a good thing because they allow different programs to share the same code in memory; this is why we consider shared libraries better than the static archives. Unfortunately, simply using, boilerplate, a shared object is a bad thing: you need to know what you’re doing.
For instance, if your software simply uses a single executable, propose no API for other software to use and you don’t use plugins then you really should not be using libraries at all, and should rather link everything together in the executable. This avoids both the execution overhead of PIC code, and the memory overhead of relocated data .

And again, here are some explanation:
- if you’re installing a plugin you usually just need the shared object, but if the software using it supports external built-ins (I can’t think of even a single example of that but it’s technically possible), then you might want to consider making the static archive version optional;
- you only install header files if your package provides a public API (it’s a library) or if it uses plugins (plugins need an interface to talk with the main program’s body);
- if you’re going to share code between different executables, like inkscape does for instance (it does it wrong, by the way), what you want is to install a shared object (there is an alternative technique, but that’s a different matter and I’ll discuss that in the near future hopefully);
- if you’re installing a single executable, you probably want to install no library at all; this might not be the case if you use plugins though, so you might have to think about it; while application can easily make use of plugins (zsh does that for instance, this takes away at least some error checking at linking time; this is, anyway, simply a matter of development practice, you can still use plugins with no library at all);
- if you’re installing a library (that is, anything with a public API in form of header files), then you’re obviously going to install a shared object copy of it; the static archive version might be actively discouraged (for plugin-based libraries such as PAM, xine, Gtk+, …), or might simply be made optional for the remaining libraries.
|
October 01, 2009
News from the front (October 01, 2009, 23:04 UTC)
For those that might have been wondering where was that guy speaking about imminent stabilization of gnome 2.26, well I was taking some time off (sort of). The Gnome 2.26 situation got a bit better in the last weeks as due to the production of a release media, a lot of dependencies we were waiting on are finally getting stabilized. You can still see progress on bug #263083, closer than ever !
Since I can't stand working on Gnome 2.26 anymore and since upstream has been kind enough to drop their new almost shiny 2.28, I started doing some QA on ebuilds in overlay before allowing them to move to the tree. Over 92 ebuilds, all of which are not necessarily interesting for gnome 2.28, I've currently reviewed 25 and that's with current 65% of completeness of the ebuild bumps, so there is still quite some work, and don't expect the overlay to be safe for use just yet.
One last word on 2.26, there will be a migration guide, it's still getting a few modifications before it all goes public with stabilization but I'm spreading the word in the hope that we won't see any new bugs concerning what has been documented.
|
There is one interesting thing that, I’m afraid, most devleopers happen to ignore, either spontaneously, or because they really don’t know about them. One of this is the fact that static libraries and plugins usually don’t mix well. Although I have to warn you, that’s not an absolute and they can easily designed to work fine.
The main problem though is to ponder whether it is useful to use static libraries and plugins together, and then it’s to find out if it’s safe to or not. Let’s start from the basis. What are static libraries used for? Mostly for two reasons: performances, and not having to depend on the dynamic version of the same library in the system. If performance of the library is a problem, it’s much more likely that the culprit is the plugins system rather than the dynamic nature of the library; I have said something about it in the past, although I didn’t go much in details and I haven’t had time to continue the discussion yet.
For what concerns dependencies, the plugins usually need a way to access the functions provided by the main library; this means there is an ABI dependency between the two; now the plugins might not link against the library directly, to support static libraries usage, but it also means that if the internal ABI changes in any way between versions, you’re screwed.
What does this mean? That in most cases when you have plugins, you don’t want to have static libraries around; this means that you also don’t need the .la files and so you have quite a bit of cleanup.
More to the point, if you’re building a plugin, you don’t want to build the static version at all, since the plugin will be opened with the dlopen() interface, from the dynamic version of the library (the module). Since not always upstream remember to disable the static archive building in their original build system, ebuild authors should take care of disabling them, either with --disable-static or by patching the build system (if you don’t want to stop all static lib building). And this is not my idea but a proper development procedure (and no, it does not mean any discussion: if it’s a plugin — and it’s not possible to make it a builtin — you shouldn’t install the archive file! Full stop!).
Now, you can see where this brings us again: more .la files that are often currently installed and are not useful at all. Like .la files for PAM modules (libpam does not load them through the .la so they are not useful — and this is definitely the word of the PAM maintainer! And for PAM-related packages, that word is The Word). Let’s try to continue this way, shall we? From the leaves.
|
Turned out that xorg-server 1.6 is pretty much ready for stabilization, as only a handful of bugs were reported over the testing period since last week, and they only concerned the stabilization list.
Without further ado, I've asked our faithful Arch Teams (pretty much all of 'em) to stabilize xorg-server 1.6 and friends. amd64 was the first one to the finish line with a stabilization done in under a day!
Gentoo is again back in business for X. Woo!
Now to all stable users, don't forget to read the upgrade guides we wrote :
Don't forget, please file bugs in bugzilla.
|
So I've been playing with mouse interaction (I stoled some code from Curses::UI, but treid to go the extra mile), and finally I am able to handle mouse interactions within Curses::Toolkit
Curses::Toolkit can now listen to and intercept any mouse button events. You can add a Curses::Toolkit::EventListener::Mouse::Click to any widget, so that it becomes mouse aware.
By default, I think I'll add some mouse interaction to the widgets. For instance Widget::Window already have mouse upport, as I show in the video. I'll add mouse support for Widget::Button, and probably other widgets as well, at least to handle the focus.
The issue is that I fail to catch the events of the mouse moving, I catch only the button events. That's why I can't draw the windows when moving them. Ncurses is supposed to let you catch the mouse positions when moving it, but I failed to get that. Maybe it came from my terminal as well. If you have any idea about that, I could use some help here !
Also, speaking of the terminal, I use Terminal.app usually, but I failed to configure it to catch mouse events (like mouse clicks). I thought it was possible but I had to use iTerm, which in turn I fail to configure to dicplay nice graphical-like borders and corner characters. If you have any clue on either how to configure Terminal.app to catch mouse events, or how to configure iTerm to properly render special characters, please let me know ! :)
|
Let me introduce a new widget in the Curses::Toolkit world : Widget::Entry.
Nothing much to say about it, have a look at this video. I tried to have the Entry widget to support basic shortcuts, and behave like one would like it to behave. I still to add some stuff to it, but it's in decent shape. Enjoy.
|
Hello again !
Let's see what's new on the Curses::Toolkit front. Please see the previous posts for the background story.
I have finally worked out a reasonable way to have themes that allow for some advanced customization. Having a theme that defines the colors, if some text should be displayed in bold or in reverse
mode is straight forward. However, having themes that can customize the shape of a widget, the way it's placed and drawn is more complicated.
It's hard to find the right balance between on a rigid widget toolkit with a very simple theme engine that allow barely any customization but is very easy to use, and a complicated theming system t
hat allows full control on the shape of the widgets but is hard to manage and use, leading to no one willing to expand it.
So I went for a simple pragmatic approach : the basic drawing primitives (drawing a string, a border, a corner, etc) can be themed regarding colors and line style. For the advanced customization, i
t's up to the widget classes to declare what can be customized in them. For instance, a Widget::Border declares that its border size can be customized. a Widget::Window inherits from Widget::Border, so if its border size is positive, the border ad the title which is displayed on it will be visible. The Widget::Window itself declares that its title can be placed in the center, right, left, etc.
So the widgets declares what can be customized in them, and their various methods (drawing methods, or coordinates computation) take in account these various parameters, and their parent's ones. Oh it's nothing revolutionary, and if I was implementing a graphical toolkit, it would be unmanageable, because too simple. But because we are in the ncurses world, the possibilities of customization are limited, and the level detail is lower (we are manipulating characters here, not pixels).
So I think this approach is not too bad. Besides it allows me to implement a widget at first without any theming characteristics, then add them later on when I'm polishing its rendering methods.
As soon as I'll have more widgets, I'll see if this way of doing it was a good decision :)
"Aaaaanyway" (as would t0m say), when I started this post I wanted to say that I changed the default theme and the rendering of some widgets, so here is how it looks now. Oh, yes, the yellow on bla
ck is horrible, but I'm not a designer. Or a lawyer, for what it takes.
You'll see I've improved the window widget, it can now have a title, that has a nice animation if its title is too long.
|
Visited BooK (October 01, 2009, 12:36 UTC)
Philippe Bruhat (BooK) was kind enough to host me ( and a friend of mine ) yesterday evening and this morning.
BooK is a nice guy, very involved in the Perl community : among other things, member of the YAPC Europe Foundation and YAPC::EU Venue Committee, president of the French Perl Mongers, member of various mongers groups.
He is also a very good cook, we tested his Tiramisu and home-made pizza.
Thank you BooK for the stuff you do for Perl, and for being a good friend !
( that was my "loosily Perl related post while coming back from holiday" ). Stay tuned for more soon :)
|
FPW 09 - talks videos (October 01, 2009, 12:34 UTC)
As you may know, last week the French Perl Workshop 2009 took place in Paris. It was a nice conference in french, where various subjects (mostly Perl related) were presented.
I gave 2 presentations :
|
Hello, it's time again for a small video on Curses::Toolkit.
The first part of the video shows some buttons that can have the focus, and I hit tab to switch focus. Window resizing is also supported.
The second part of the video shows a button that - when clicked using space bar - generates a new buttons, add it to the HBOX. These new buttons can themselves receive focus and be clicked to create a third type of buttons.
What's next ? I'll post about key events and key listeners, I'll try to add more widgets, and at some point publish Curses::Tookkit to CPAN.
In the mean time, enjoy.
|
It's this time of the year again !
The French Perl Workshop is starting tomorrow for 2 days in the wonderful city of Paris, France. It's organized by the French Perl Mongers.
A bunch of interesting talks, quite a lot of people are planned. I have to say that this year's edition looks very promising, due to a very efficient team that spent a lot of effort to organize it. Of course we'll see how well it was at the end of the two days, but I'm really excited about this edition.
I'll give 2 talks, on POE::Wheel and Curses::Toolkit. Nothing really major (compared to talks on Perl 5.10 or Perl 6...) but every little helps, I guess.
Hm, OK the real reason I'm writing this blog entry is that I'm still missing about 30 slides for my talk that is tomorrow, and it's already late, and I can't motivate my brain to actually do it. Is it the fatality that whatever effort you put in preparing things in advance, you always find yourself writing the slides of your talk the night before ? I guess that's Murphy's law...
Seriously, have you ever given a talk (for the first time) with the slides ready days or weeks ago ? If yes, let me know how you manage that :)
Anyway, if you are in Paris the next days, please head toward the Cité des Sciences and come see us !
|
1. Focus, the details
Please refer to the previous post for the context about Focus. Basically, Curses::Toolkit is a Perl software toolkit that let's you create nice ncurses based interfaces. It extensively uses widgets, that can have the focus.
As I said in the previous post, not every kind of widgets can have the focus : only a widget that can be interacted by the user should be focusable. For instance, a Label doesn't offer by default any interaction to the user. So a Label widget is not focusable. Likewise, a Border is just displaying a graphical border, and doesn't offer interaction to the user, so same, a Border shouldn't be focusable.
Now let's have a look at the Button widget : it should clearly be focusable, as by default a button is clickable, and do be able to "click" it using the keyboard, the user needs to position the focus on the button and trigger the enter key or the space key. So it's obvious that the Button widget should be focusable
Now let's think about the implementation : the Button widget class is just an nearly empty class that inherits from Border, provides a facility constructor that would add a label in the Border. So a Button widget is basically a Border Widget. But we want to add the focusability concept. That is the situation where you would use words like interfaces, mixins, traits and roles. I like the concept of Role, and I think it suits the purpose here, so I decided to implement the focusability with a Role.
2. Roles
A Role is basically some features (code, attributes), that are injected in the class, but unlike a mixin, it is possible to see from which roles a class has been built from, and change that. Moose offers a great implementation of Roles, as does Perl6. Alas, I haven't yet converted Curses::Toolkit to Moose, so I needed a pure Perl5 solution : multiple inheritance !
Right, multiple inheritance is wrong, it's bad, it's pure evil. That's what you've been told at least. I have to say it's true, multiple inheritance is very rarely a good thing, and it can generate a lot of issues (and make it inherently more difficult to fix them).
However in this case, I thought I could use it, provided I take care of limiting the use of multiple inheritance to implement Roles, and be careful not creating the infamous diamond-of-death structure.
3. Implementation
Here is how the Curses::Toolkit::Widget::Button class look like :
package Curses::Toolkit::Widget::Button;
use parent qw(Curses::Toolkit::Widget::Border Curses::Toolkit::Role::Focusable);
By inheriting from Border, we get all its attributes and methods. By inheriting from the Focusable role, we also signify that this widget can be focused. Let's look at the content of Curses::Toolkit::Role::Focusable :
package Curses::Toolkit::Role::Focusable;
[...]
sub new {
my ($class) = shift;
die "role class, has no constructor";
}
[...]
sub is_focusable {
my ($self) = @_;
return 1; # in real life it's less trivial
}
sub is_focused {
my ($self) = @_;
return $self->get_property(basic => 'focused');
}
sub set_focus {
my $self = shift;
my ($focus) = validate_pos( @_, { type => BOOLEAN } );
if ($self->is_focusable()) {
$self->set_property(basic => 'focused', $focus ? 1 : 0);
[...]
As you can see, we protect users from instantiating this class, and then we implement the various role attributes and methods. This implementation is easy to use and flexible : to know if a widget is focusable, just use :
$widget->isa('Curses::Toolkit::Role::Focusable');
Once you know it's focusable, you can use set_focus, is_focused, etc...
One could also imagine needing to remove the focusability at run time on an existing widget. filtering out Curses::Toolkit::Role::Focusable from its @ISA would do the trick, even if it's not very clean.
So, I know all this is not very modern, and it'll disappear when switching to Moose (and Perl 6 soon ?), but in the mean time, I just wanted to share this trick. Eh, it's not everyday you can argue positively about multiple inheritance !
PS : I am by no mean a good OO designer, and what I just exposed might be just plain wrong. I'd be more than happy to be enlightened :) If there is a better way to do this in old-school Perl5 way, drop me a note.
|
Today let's have a look at a widget I'd like to implement in Curses::Toolkit : a Button widget. That doesn't look very difficult, but in fact you'll see it requires that a lot of things are in place under the hood for the Button widget to be fully usable.
At a first glance a button is very basic : it has a border, a label, and you can click on it. Actually, it can have anything inside, not only a label. So a Button can be designed as a widget that inherits from Border, and that has an additional constructor ( new_with_label ), that would create and add a Curses::Toolkit::Widget::Label in the border. The button class is Curses::Toolkit::Widget::Button.
So far so good. However, a button is not a button if you can't click on it. That means a new concept needs to be added : the "click" event, or something similar. But to be able to click it, the user has to be able to focus the button. So here we go, a new concept : focusability !
When a widget has focus, it means that the user can interact with it. But not all widgets can be focused : a border as no interaction to propose to the user, so a border should not receive the focus. However, a button is something that can be interacted with, so it should be able to be focused. To implement that, I decided to use a Role. I'm not yet using Moose in Curses::Toolkit (I'll switch to Moose at some point), so I'll implement Roles using multiple inheritance, a Role being an abstract class. With some care, I shall avoid multiple inheritance caveats. This new Role is called Curses::Toolkit::Role::Focusable. I'll come to the details a bit later.
So when is a widget (that is, the class of the widget) focusable ? When it has the Curses::Toolkit::Role::Focusable role. AND when it's sensitive. Indeed, I'm sure you remember these "grayed-out" widget in modern graphical user interfaces ? It's the sensitivity of the widget that determines if it's normal or grayed-out. When in non-sensitive state, a widget cannot be focused. So again, a new concept : sensitivity. We'll say that upon creations, widgets are sensitive.
Sensitivity, focusability, that's nice, but the user needs to be able to click on the button, and change the focus. We'll start by implementing "clicking" with "pressing a key on the focused widget". We'll see how to support the mouse a bit later. Curses::Toolkit needs to be aware that the keyboard has been used, and have a mechanism to handle the keystrokes. That implies to have some sort of events to send the information related to the keyboard. And also to have some kind of event listeners that the user can set, to listen to an event and act accordingly.
That's indeed a lot of new concepts introduced. We'll see in the next posts how to implement them.
|
POE-Wheel-GnuPG (October 01, 2009, 12:28 UTC)
Today I'd like to present POE::Wheel::GnuPG (source code here ).
I guess you know what GnuPG is. Right, so when you want to encrypt/decrypt data or do other GPG actions in Perl, the best thing to do is to rely on a GnuPG module. I always use GnuPG::Interface because it is very reliable : it's just a wrapper around a fork/exec of the gnupg program installed on your system. Granted, the drawback is that you need gnupg installed and executable, and this is not suitable for all situations. But the benefit is that it's fast, and it's not subject to bugs of pure Perl (or other languages) reimplementation. And it gives you access to all features of GnuPG, like keys management, etc...
So far so good, using GnuPG::Interface is not completely trivial, but it's easy enough. Now, I was trying to solve the following issue : imagine you have a very big encrypted file to decrypt. It's not likely to fit in RAM, but for security (or other reasons), you don't want the decrypted content to be saved in a file. What you want is decrypt the file bits by bits, and process the decrypted file as soon as data are available.
To do that, we'll create a module that interacts with GnuPG::Interface and do non-blocking monitoring of file handles to check when crypted data is needed, and decrypted data is available. I soon realized that this module would be a perfect candidate for a POE::Wheel, as POE provides all necessary tools to monitor file handles and child processes.
Let's see how to use POE::Wheel::GnuPG to do a simple encryption :
# use POE with the wheel
use POE qw(Wheel::GnuPG);
POE::Session->create(
inline_states => {
_start => sub {
# initialize the wheel with the bare minimum
my $gnupg = POE::Wheel::GnuPG->new(
ready_to_input_data => 'ready_to_input_data',
something_on_stdout => 'something_on_stdout',
end_of_process => 'the_end',
);
# Save the gnupg object in the heap for later use
$_[HEAP]{gnupg} = $gnupg;
# The Wheel inherits of GnuPG::Interface so
# it's supports the same options.
# I indicate that I want an ascii encrypted
# content, crypted against my gpg key
$gnupg->options->hash_init(
armor => 1,
homedir => '/Users/dams/.gnupg' );
$gnupg->options->push_recipients('dams@gentoo.org');
$gnupg->options->meta_interactive( 0 );
# Let's start the encryption !
$gnupg->encrypt();
},
ready_to_input_data => sub {
# This is called when gnupg is ready to receive
# the data to encrypt
my $input_fh = $_[ARG0];
print $input_fh "This is the secret data!";
# This is important to signify gnupg that it should
# not wait any more data to encrypt
$_[HEAP]{gnupg}->finished_writing_input();
},
something_on_stdout => sub {
# And now we can read the crypted data
# from the filehandles
my $stdout_fh = $_[ARG0];
return if eof $stdout_fh;
my @output = <$stdout_fh>;
print "Received crypted data : @output\n";
},
the_end => sub {
# clean up
$_[HEAP]{gnupg}->destroy();
exit();
},
}
);
POE::Kernel->run();
exit;
For more detailed usage description, see the POD.
That program performs a simple encryption. In the POD, I provide an example to do asynchronous decryption : check example n°1 in the SYNOPSIS
I used this example to decrypt a big file, printing out the character '.' when sending an encrypted line to the wheel, and printing out 'O' when reading out a decrypted line. Here is the start of the output :
macpro:bin dams$ perl ./test.pl
..................................................
..................................................
..................................................
..................................................
..................................................
..................................................
..................................................
..................................................
..................................................
..................................................
..................................O.O.O.O.O.O.O.O.
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
[...]
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
[...]
And so on. You can see that the encrypted data is first read to fill up the buffer, then decrypted data is read out at the same time. At some point, there is too much decrypted data to print, that's why there are a lot of 'OOOO's. Then it all starts again :) I think it's a good demonstration of asynchronous GPG decryption !
|
September 30, 2009
On Monday 21 September we packed the majority of our belongings into the back of a Penske truck and made the 500 mile drive (in convoy - Louise, William, Dax and myself) from Pittsburgh, PA to Clifton Park, NY. Since then we have been unloading the truck, unpacking our things into our new home and doing all those things you have to do when you move house, and several things necessary when moving between states and jobs.
This is certainly the most rural house I have lived in since I was very young. We found a nice duplex on the outskirts of Clifton Park, it uses well water and I am the proud owner of the contents of two full propane tanks (no natural gas lines run out to the house). We also have a really nice wood fire in the living room, and I snagged the family room and am using it as a large home office! Thankfully they were able to hook up a cable Internet connection on Tuesday last week, and so I was not offline for too long.
Tomorrow is my first day with Kitware, I will be attending a training course being run by Kitware for the remainder of the week and so won't have my first day in the office until next Monday. I will be working in the scientific visualization group on projects such as ParaView, and have had lots of ideas for future Avogadro development over the last few weeks. I am very much looking forward to working in some new areas, but also to enhancing the previous research and development I have done in the area of visualization in chemistry. I am also looking forward to working on CMake.
|
Mono might not be perfect… (September 30, 2009, 21:26 UTC)
… but I still like it as a technology, that is after working with it for a few months already, and now having understood a few of its quirks.
First of all, it’s not true at all that simply using Mono leads to perfect compatibility between Windows, Linux and OSX. Not without having to write some extra code. While Microsoft did design some abstraction, like System.Environment.OSVersion.PlatformID that allows to find which OS we’re actually running on, there is an obvious design by default oriented to Windows. It’s not like that’s something surprising.
For instance, .NET has its own way to store configuration settings, but this is very Windows-centric, since, as far as I can see, the configuration file is to be store together with the executable (this, then, wouldn’t work with properly installed Linux applications, since then the executable will be in a path the user has no write access to).
Another problem is that while there are interfaces to identify some of the standard location for files (like documents, pictures, the home directory and stuff like that), and Mono obviously handle them gracefully under Unix following the XDG Base Directory Specification which is quite a nice touch, it does not have the perfect granularity yet; for instance it does not provide a transparent way to handle the path for cache files (not-too-temporary, but not even persistent).
For these things, and probably a few more issues I’m finding, I’m currently writing a library, that I called, with very little imagination, Portability, which provides some generic interfaces to this kind of stuff; my intent is, if it makes sense at the end, to release it under either LGPL-3 or BSD license, and have it as a standalone project.
There are also a few more issues, like the sgen tool that should automatically generate static serialisation code to save and restore classes on files; unfortunately for some reason it doesn’t seem to work at all here: it aborts on an IDictionary object, but the class I’m asking it to serialise does not have any Dictionary in it; sigh. But that doesn’t matter since at least the dynamic, slow, reflection-based serialisation works, mostly.
At the end, I find it much nicer to work with C# than with Java (which would have been the alternative for this project for instance).
|
netflix new stuff (September 30, 2009, 15:42 UTC)
I found this article on Wired about Netflix, and their plans for global domination, which is stuff I always love reading about. There's two things about the future of television and movies I would totally love to see: First, for cable to completely fall on its face, and everything to become on-demand. Second, for video rental stores to go out of business so that on-demand will be the most efficient way to get stuff. Fortunately, it seems that the markets are heading that way naturally.
However, while Netflix is certainly the best contender right now, I think it's worth pointing out that the content is still in its infant stages. Netflix can stream some movies, sure, but it's selection is not anything compared to say, iTunes, in regards to music availability. One thing Apple did quite well was it got *all* the major studios to sign on to sell their music. That means that you can expect to find everything mainstream right there without much difficulty. Compare that to Netflix, who has *zero* major studios signed on right now. Hopefully that will change, but everytime I see articles like the Wired one, that tout Netflix's library, I feel the need to clarify to people so they don't get suckered in.
For example, here's a quote from the article, "And the devices won't just be streaming remaindered basic-cable or art-house fare: Already, Netflix customers can call up just about any episode of SpongeBob SquarePants, The IT Crowd, or Lost whenever they like. They can watch recent releases like WALL-E and Pineapple Express. In other words, they can get unlimited access to the kinds of programming that previously required a cable subscription." (emphasis mine).
Just reading that, it *sounds* like Netflix is a drop-in replacement for cable access, which is not the case at all. Rather than trying to read between the lines and saying something like, "Oh, they have everything between Wall-E and Pineapple Express", it's far more accurate to say "Oh, I can watch Wall-E *or* Pineapple Express." The selection simply isn't there.
A few weeks ago, I bought my brother a Roku Netflix Player for his birthday (I'm such a nice guy, I know). He has two small kids, and one of the main reasons I got it was because Netflix *does* serve up a lot of children's programming -- quite a lot, actually -- and I figured he would find that useful. It's all available on demand, simple bookmarking, easy pause and resume, easy interface, etc. I talked to him about a week later and one of the first things he mentioned about it was that there weren't hardly any new movies on there.
Right now, their only real provider for new movies is Starz Play. If you have an account for Watch It Now, and want to find the new stuff, that's really the only place to look. Plus, it's really hard to find stuff as well. The website for browsing DVD releases on the Netflix site is amazing. It's intuitive, it's quick and easy to search and find stuff, it's great at recommendations and it gives you lots of info in lots of ways. Now, compare that to the Watch It Now navigation menus which are *completely* different. My take on it is that there is so little content there, that they forcibly dumb down the interface to obfuscate the fact that there's really nothing there. It's just taking the small amount they have, and spreading it around really thin so it looks like it's more than it is.
So, anyway, while I really hope that Netflix does the right thing, and business-wise, they are poised to take over the market -- Hollywood is holding them back. I wouldn't blame Netflix in the least. It's impossible to download *all* the new releases from any service anyway (from what I've seen). For instance, X-Men Origins: Wolverine came out on DVD the other week, and I wanted to check it out. I didn't really feel like going down to Blockbuster to get it, so I checked to see if any of my online pals were serving it up. The Playstation Store had it, but you had to buy the movie, in standard definition, for $14. No thanks. Amazon's Video on Demand didn't have it, and neither did Netflix. I realize that's a small sample to choose from, but there's really not many more services out there -- I think iTunes sells / rents new movies now, but I don't have a way to watch them on my TV anyway, so I didn't bother checking.
Once Hollywood gets on board, then things will really take off. I read in the news how Blockbuster isn't doing well, and they are the last legacy distribution market. I kind of can't wait for them to stumble, because if they are gone, the studios will have no other medium to even sell / rent new movies through, except through newer, leaner retailers like RedBox, Netflix, and on demand services. The future can't get here fast enough for me.
|
September 29, 2009
Global Financial Derivative trading company, OSTC Poland, uses Gentoo Linux in significant sectors of its IT infrastructure. We spoke with long time Gentoo user and head of OSTC Poland's IT department, Patryk Rządziński, to learn more about how and where Gentoo is used. We discovered, as you will read in the full interview, that Gentoo, and more generally open source software, serves well in the commercial world.
|
Another C++ piece hits the dust (September 29, 2009, 11:19 UTC)
You might remember my problem with C++ especially on servers; yes that’s a post of almost two years ago. Well today I was able to go one step further, and kill another piece of C++ from at least my main system (it’s going to take a little more for it to apply to the critical systems). And that piece is nothing less than groff.
Indeed, last night we were talking in #gentoo-it about FreeBSD’s base system and the fact that, for them similarly to us, their only piece of C++ code in base system is groff; an user pointed out that they were considering switching to something else, so a Google run later I come up with the heirloom project website.
The heirloom project contains some tools ported from the OpenSolaris code base, but working fine on Linux and other OSes; indeed, they work quite well in Gentoo, after creating an ebuild for them, removed groff from profiles, and fixed the dependencies of man and zsh.
A few notes though:
- the work is not complete yet so pleas don’t start already complaining if something doesn’t look right;
- man is not configured out of the box; I’m currently wondering what’s the best way to do this;
- after configuring (manually) man, you should be able to read most man pages without glitches;
- for some reason, we currently install man pages in different encodings (for instance man’s own man page in Italian is written in latin-1); heirloom-doctools use UTF-8 by default, which is a good thing, I guess; groff does seem to have a lot of problems with UTF-8 (and man as well, since the localised Italian output often have broken encoding!);
- groff (and man) both have special handling of Japanese for some reason, I don’t know whether the heirloom utilities are better or worse for Japanese, somebody should look into it.
|
September 28, 2009
jump on it (September 28, 2009, 20:13 UTC)
Hee, hee, hee, this was fun. On Saturday I got to take my little brother out, and I had a great idea this time around. There's this place in Lindon, Utah (about 20 minutes or so south of Salt Lake) called Jump On It, which is basically an empty warehouse full of all these trampolines joined together. It's awesome.
I've driven past the place plenty of times and thought, "eh, I should probably go there." Then I remember my friend Jason wrote about going there one time, and that made a trip even more necessary. I don't know how I got the idea to go this weekend, it just popped in my head, but I'm glad I did. I looked it up online, and it's only $8 an hour to go jump around and do whatever you want.
The concept is so incredibly simple, but it is so well done and so much fun. There are probably at least twenty trampolines just all next to each other, which make this huge, very fun square that you can just jump around in non-stop. And you can get going fast, really fast, with a lot of momentum. And you can flip around and hit the sides and just bail and not hurt yourself. It's awesome.
There are two areas for trampolines, too, there's a smaller one for kids four feet and under, where the tramps are a lot less springy, so you won't go nearly as high. The other ones are for any size / age group, and the springs there are really tight. I grew up with a trampoline, so I know all the tricks and how to get really, really high, and I managed to nearly touch the ceiling I was bouncing so high on those things. Holy crap, that was a feeling.
Here's a pic of the kid's one. I really, really wish I had taken my camera with me to get some decent shots. This one is from my cell phone, which is craptacular when it comes to taking action shots, so I had to tell my bro to stop for a second so I could take his pic. He does not look too thrilled to pause for me. I can't really blame him.

The other thing that really amazed me is how fast I got worn out. I didn't think it'd take that much energy, but man, after the first 10 minutes I was about ready to pass out, I was working my body so much. I had to constantly take a break so I wouldn't throw up / pass out. The hour sure went by fast, and I'd say I got more than my money's worth. I gotta get into better shape, and go back. It's a total blast, and this post hasn't done a great job in the least documenting how much fun it is.
|
I have still been, for the most part, extremely hesitant to purchase anything on Blu-Ray just yet. My modus operandi so far has been to rent a lot of them to see how the quality is compared to the DVD to see if a repurchase is justified. So far, this approach has been serving me rather well, and I've discovered very early on that it's nowhere the same across the board. Some movies look awesome, some look okay, and some look like they just dumped the DVD transfer onto the new medium without a thought (which is really noticable, too).
Switching from VHS to DVD was an obvious decision, an upgrade that would have been hard not to argue for. I imagine I'm getting old if I can even reminisce about such times. I remember right when DVDs first started coming out, and I would keep a watchful eye on how things were progressing (anyone remember DivX? What a nightmare). It's really interesting to see how much the tables have turned in some regards. Disney was a huge holdout on DVD, and eventually came along with feet dragging, but now, they make the best Blu-Ray editions, bar none. Universal sucks across the board -- their Blu-Rays have been less than impressive (I just watched the Bourne Trilogy the other week, and the first two were nothing to write home about). And then, there's Paramount ... who distributes Star Trek.
All the movies except Insurrection and Nemesis got released on Blu-Ray last week, and I have been really excited to check them out (edit: okay, actually I can't find the first one on it's own release ... I must have rented the one from the trilogy set, oh well. I know the other ones are out though). I've thought about buying them out-right, but I'm a bit cautious considering the studio's past foray into the market. What they tend to do is create a money grab by releasing the films a few times in different editions. First, they'll put one edition out, just to have something people can buy, and then later on clean it up, add more special features, and tout that one as a better upgrade. It can be a bit maddening, and expensive. So, I added the first few films to my Netflix queue, to see how well these new transfers held up, and I got to watch the first one this weekend: Star Trek: The Motion Picture.
All I can say is, wow, they did a nice job. The picture is gorgeous. For a movie that is so old, I was extremely skeptical that they would even be able to do anything with it at all. But on my HDTV, the picture was just ... more clear and vibrant. That's the best way I could describe it. Some films don't hold up to the test of time when being presented in a larger format, but this one looks like it just came out.
I wish I had a Blu-Ray drive so I could rip the disc and get some snapshots, but that'll have to wait. I keep thinking of a few scenes that showed off the detail so well that they would do a much better job explaining what I'm trying to get across.
I can't say much about the sound, since my setup is 3.1 (no rear speakers). Besides, my speakers are from an off-the-shelf surround sound setup, and not really good quality. I've got it in my sights to eventually replace it with something decent, but that's a major hop and a skip away. I'll just wait on that one. For what I heard, it did sound really good though. I really love how in this movie, it opens with the score for a few minutes and you just get to hear the long version of the Star Trek theme. Great stuff.
There was only a few spots where there were any video issues at all. Again, if I could take a screenshot, I would. It's not that they were bad, it's that it was more like "uh, how did you miss *that* big black blotch right on the front of the Enterprise." It happened twice, briefly, and that was it. Aside from that, the only parts where the film quality was lacking was a few scenes which were probably just notoriously hard to clean up, so they didn't -- the ones where the probe from V'ger is on the bridge of the Enterprise, and it's zapping it's way around. The shot was really fuzzy to start with, and you could notice a huge drop in quality and cleanup for the few seconds that the shot took place. Again, not a dealbreaker, and in fact you'll see the same thing on the DVDs.
Overall, I'd say this one was well worth the price. I started playing around with the special features, but didn't really get far because I was tired. It does have this cool on screen index you can access while the movie was playing, that I thought was really innovative. It'd give you descriptions of certain Star Trek topics related to the film. There was also an audio commentary track, though I didn't bother listening to it.
I'm definitely gonna get a copy of this one though, given the chance. I've got the other ones in my queue and I'll write up a review as I watch them in the next couple of days. Tell you what.
|
psp go (September 28, 2009, 15:48 UTC)
So, apparently the new PSP Go is going to hit shelves soon. I totally keep forgetting about it. While it looks pretty freaking cool, there are a couple of things that are keeping me away completely, and I'd have to think long and hard about getting one.
First of all, this sucker is freaking expensive. $250. Eek! That's only $50 less than a PS3, although that'd be a little harder to lug around in your pocket. I still have a PSP-2000 or whatever the number is, I know it's not the first generation one, and it works really well. Sure the UMD thing is slow and cumbersome and sucks power like uh ... something, but it works fine. And it's about $100 less retail.
This is my *real* beef though with the system -- it only has 16 GB onboard memory. That could arguably be a reasonable amount, except that this PSP is entirely digital. The only way to get games is to download them to the flash drive. On top of that they are marketing it as a great portable movie player. 16 gigs is not a lot of space to play with. If they had 40 in there then I might start thinking about it, but that still brings me to the next point.
It *still* only accepts Sony Memory Stick Pro Duo (man, what a mouthful) for the extended storage. Normally, I wouldn't care -- Sony has their own format, yay, whatever, good for them. But they are priced exhorbantly high. A 16 GB flash card, that would double the system's space, costs $72 right now on Amazon. Not only that, but that's the highest storage capacity available. So, you're going to cap out at 32 GB. That's a lot, I suppose, but if I wanted to tout around movies with me, I'd still want more space than that. I dunno. But at this point you're talking $320 to carry around max storage.
The last thing that has me worried is that all the games are digital. I'm a big believer in the second-hand market for used games, and the new PSP just guts that opportunity completely. You want the game? You buy it new, and you pay full retail price. Normally, I wouldn't have a problem with that, but what happens with digital games is that when there is only one source to get them, I've noticed that the price does not go down. Ever. At all. Games that are listed for sale at launch point that originally start at $40 or so, might eventually go down an extra $10 or so, but after time, it just stays there, and it's always going to be prohibitively expensive. That's a problem. What's worse, is that you would think that after five years or so the price would come down, but by then the owner / manufacturer / retailer has completely forgotten about it, so nothing ever gets changed. It's really going to screw up the economics, I think, when there's only one way to get a copy of the game (well, legally, of course).
So, while I'd love to get one, I think next time I have a spare $250, I'd probably be putting it towards getting something else. I think the PSP Go is a great idea, in concept, but too expensive and not enough storage. I could get past the all-digital downloads, eventually, I assume. I'd still like to see some way to get a second hand market in there though -- it would really drive things along.
Edit: Whoops, apparently it uses a different format -- Memory Stick Micro M2 (or whatever order that goes in). The pricing is just as bad, though. $80 for a 16 GB stick.
|
dan in real life (September 28, 2009, 15:27 UTC)
I watched "Dan In Real Life" again this weekend (on Blu-Ray, wow it looks nice), and it is quickly becoming one of my favorite movies.
What's interesting, that I have noted, is now that my DVD movie collection is pretty much rounded out -- save the consistent three or four I always forget about and are on my wishlist to get someday -- is that now I get to see which ones I watch regularly. What surprises me is that it's always the dramas. There's a few classics that I keep returning to, to watch over and over again, and the great thing is that I enjoy them the next time as much as I did the first one. It's awesome. This movie is quickly becoming one of those, too ... I think this is the third or fourth time I've seen it, and it's not even close to becoming old.
If there's one type of movie I can never watch again, it's suspense / action movies. Ones where they have you gripping / guessing what's going to happen in the end. I don't like the sense of anxiety it creates, and besides, once I figure out what happens (by watching the movie) the feeling can never be recreated, and watching it again is really just torture for me. So, there's a lot of movies -- really good ones, even -- that I refuse to buy only because I can't possibly sit through it again. Movies like The Lion King, Finding Nemo and Toy Story come to mind (that's odd, all animated Disney ones ... go figure).
Anyway, dramas are for me. And this is a great one. I managed to score a copy on Blu-Ray for only $10 on Amazon which I could not pass up. I don't remember the actual timeline, but I think this was one of they very first movies on Blu-Ray I saw ... well, I definitely remember that the colors were so gorgeous, and the transfer was so well done, that it convinced me to stop scoffing the format, and instead give it a chance. It was probably then that I realized that *recent* movies on Blu-Ray look gorgeous. And they do. Wow. Good times.
|
Since I have been still fighting with the damned .la files and I’m pretty sure that even though I have explained some use cases most of my colleagues haven’t really applied them, I decided to go with a different approach this time: graphical guides.
Since the post about the tree size has gotten so much feedback, probably because the graphs impacted on people, this might actually prove useful.

Note: I first tried to draw the chart with Inkscape, but the connector available on its code only draws straight lines, which are unusable for stuff like this; I found no way to anchor lines to an arbitrary point of objects either, so I gave up; dia is tremendously bad to work with; kivio 2 is not in Portage nor available as binary package for either Windows or OSX; OpenOffice to the rescue, worked almost flawlessly, unfortunately I didn’t want to waste time to define customised colours so you get the bad and boring ones in the image.
As you can see from this graph, my idea is that, at the end, every .la file is removed. Of course this is not immediate and depends on a series of factors; this graph shows at least the basic question you got to ask yourself when you have to deal with shared libraries. Please note that this does not apply the same to plugins and for that I’ll post another, different flow chart.
- Does the package install internal libraries only? A lot of packages provide convenience libraries to share code between different executable programs (see this post for more information about it); this can be detected easily: there are no include files installed by default, the library is not in the ld path (such as
/usr/lib/packagename). In this case, the .la files are not useful at all, and can be removed straight away.
- Does the package only install shared objects? The
.la files are only meaningful for static libraries that have no dependency information; if a package is not installing static libraries (.a files) it needs not the .la files.
- Do the libraries in the package need other libraries? If the libraries are standalone, and only depend on the C library (
libc.so), then there is no dependency information useful in the .la file, and can be dropped.
- Is
pkg-config the official way to link to the libraries? When using pkg-config, the dependency information is moved inside the .pc file, so the copy in the .la file is redundant, and thus unnecessary.
- Is the package new? When adding a new package into Portage, there is no reason to keep the
.la files around when the conditions shown above apply. For packages that are already in portage, the removal of .la files need to be considerate, or you’ll get the same kind of fire I got for trying to remove some (useless) .la files out of the blue. Not a situation that I like, but so is life.
|
EntropyKey packaging in Gentoo (September 28, 2009, 11:30 UTC)
As I have announced before I ordered two EntropyKey (one for Yamato so I can test it, and one for the router to put it into production). They arrived today, so I went on and packaged the ekeyd software (the daemon that takes care of feeding the entropy data to the kernel), which is now in portage as app-crypt/ekeyd.
There are though a few notes on both the package and the packaging procedure that I’d like to write about, for posterity.
Firstly, I really don’t see it as a really good move to make use of LUA in such a project; this is both because it looks like overkill to me, and because LUA itself isn’t really extremely standardised between distributions. In Gentoo, additionally, it’s using the wrong path for the compiled extensions, and is thus not really multilib-safe (although it’s debatable how useful multilib is getting, but that’s beside the point for now).
Another problem is, the software not only uses the base LUA code, but also needs the luasocket extension. And not even a vanilla luasocket, because it needs Unix socket support, and that is not built by default by the source package; I had to patch the sources to force building and installing it.
Beside these two problems, and the fact that the Makefile isn’t really extremely straightforward (and I needed to hack it a bit around to avoid -Werror and gzipping of man pages (Portage takes care of that), packaging wasn’t that much of a problem; the code seems clean and with the exception of some format warnings (reason why -Werror would have been a problem), no other problem was found (the package uses -fno-strict-aliasing though, which means that some optimisations will be discarded, too bad.
For what concerns the use of the package, the current ebuild in Portage is good enough for use, I’m using it myself, but it has some things that are still incomplete. For instance, it currently does not check for the Linux kernel options for CDC (and contextually I should probably keep a table of kernels to warn about — Linux 2.6.31 will not work for instance, out of the box, because of a bug in the CDC driver), and the userland USB daemon lacks an init script (which I would probably make much easier to use than the actual daemon: the daemon wants to know the USB bus position of the key, since I don’t like to rely on that I’d rather make use of lsusb or some other method to get the position from the ID pair and the serial of the key itself).
I am also pondering about moving the two daemons in /usr/libexec to avoid polluting root’s path with daemon commands (since they should only be started by the init script).
So as you might guess, there’s going to be a r1 version probably even today, depends on how much time I have free (I have lots of stuff to do, sigh).
|
(For readers on planet.g.o: This one is in German language only, but i do consider this important enough to be published on planet.g.o although.)
Wichtig: Ich schreibe hier als Privatperson, nicht als Vorstandsmitglied des Förderverein Gentoo e.V.!
Die am vergangenen Freitag stattgefundene Mitgliederversammlung hat sich mehrheitlich dafür ausgesprochen, den Förderverein Gentoo e.V. aufzulösen. Entgegen der Tagesordnung wurde mangels Kandidaten kein neuer Vorstand gewählt, so dass der bisherige Vorstand weiterhin geschäftsführend im Amt bleibt. Alle Mitglieder des Vereins werden in den kommenden Tagen angeschrieben und zu einer außerordentlichen Mitgliederversammlung eingeladen, die voraussichtlich am 07.11. in Bottrop stattfinden wird und in welcher über die Auflösung formal beschlossen werden kann.
Vorweg: Auf die Gentoo-Distribution an sich hat dies keinerlei Auswirkungen, Gentoo ist nicht tot und wird weiter bestehen – auch unabhängig von einem Förderverein im deutschsprachigen Raum.
Was ist der Förderverein Gentoo e.V.? Der Verein wurde im Herbst 2003 am Rande der Practical Linux in Gießen mit dem Ziel gegründet, die Verbreitung und Präsenz von Gentoo im deutschsprachigen Raum zu fördern und unterstützen.
Warum will sich der Verein auflösen? Es konnte aus dem – kleinen – Kreis der bei der Mitgliederversammlung anwesenden Mitglieder kein neuer Vorstand gefunden werden. Die Mehrheit der anwesenden Mitglieder sieht keine Perspektive den Verein weiter sinnvoll zu betreiben. Es ist seit Gründung des Vereins im Jahr 2003 nicht gelungen, eine kritische Maße zu erzeugen, die sich und den Verein gegenseitig pusht und weiterbringt, aktiv am Vereinsleben teilnimmt. Realistisch betrachtet war ich in der vergangenen Zeit ein Einzelkämpfer – zu wenig für einen Verein.
Welche Konsequenzen ergeben sich aus der Entscheidung? Die Präsenz von Gentoo auf Messen und Veranstaltungen wird darunter leiden. Auch wenn es um den Verein in der Vergangenheit ruhig war, konnte dieser dennoch über Mitgliedsbeiträge und Zuwendungen die Finanzierung von Flyern und Bannern, Vorfinanzierung von T-Shirts, etc. pp. sicherstellen. Ob sich Privatpersonen finden, die künftig nicht unerhebliche Beträge vorfinanzieren oder für Flyer etc. aufwenden wollen und können, wird sich zeigen müssen. Insgesamt gehe ich davon aus, dass sich die Präsenz auf Veranstaltungen zunächst nicht großartig verändern wird – langfristig mag ich keine Perspektiven abgeben. Was diese Entscheidung für mich persönlich bedeutet, wird sich auch noch zeigen müssen – meiner Motivation sind insbesondere diverse Begleitumstände der Mitgliederversammlung nicht sonderlich zuträglich. Auch fraglich ist zunächst, inwieweit es das Portal gentoo.de künftig noch geben wird, wenn kein Verein zur Finanzierung des Betrieb des Servers bereit steht. Und: Es gibt sicherlich weitere Implikationen einer Vereinsauflösung, die sich erst im Nachhinein zeigen werden.
Schade.
|
The size of the Gentoo tree (September 28, 2009, 01:54 UTC)
You might have noticed that I started working on cleaning up the tree (before I had a few problems with my system, but that’s for another day). Some people wondered whether that’s really going to make much difference, so I wanted to take a look at it myself. I was already quite sure that, while reducing the size of filesdir is important, especially to avoid more stuff to be added to the tree, getting rid of all the filesdir wouldn’t really make a terrible impact. Some extra time at hand, some find commands later, and Google Docs, lead to this:
As you can see, the big part of the tree is ate up by the support files, more than twice the size of all the ebuilds; files/ directories are just little more than ebuilds, and there is a huge amount of filesystem allocation overhead, even if my tree is in a filesystem with 1 KiB blocks. Another interesting note is that the licenses use up more space than the whole set of profiles, scripts and eclasses!
For the sake of finding something to work on, let’s break up the support files class into a different graph:
So much for those who complained that adding information about packages in metadata.xml is wasting space for users… the real space waster are change logs instead! But they are useful to keep around, for a while at least. I guess what we really need is better ChangeLog integration in repoman, so that a) it updates the ChangeLog on commit (stopping developers from committing without updating them!) and b) it can delete older and obsolete entries (like, keep the most recent 40 changes or so).
|
September 27, 2009
Gentoo Ten LiveDVD Testing (September 27, 2009, 17:03 UTC)
Attention Gentoo Community,
In honor of Gentoo's 10th birthday, we are producing a new livedvd! We need
YOU to test it on as many x86 and x86_64 machines as you can and post bugs.
Please report your bugs. Feel free
to entertain yourself and fellow Gentoo rock stars on our forum.
The livedvd-x86-x86_64 will work on x86 or x86_64. If your arch is x86 boot
with the default gentoo. If your arch is amd64 boot with gentoo64. The
livedvd-amd64 is for well, amd64 only.
UPDATE: Due to demand, we have moved the files onto the regular mirror infrastructure.
Please select your archiecture to be redirected to a mirror: x86amd64
So, give us a hand by testing like crazy AND posting bugs and we'll have the
greatest livedvd ever.
Thanks for your continued support,
The Gentoo-Ten Project
David Abbott contributed to the draft for this announcement.
|
September 26, 2009
Just sent this to the gentoo-dev@ mailinglist in the hope of getting some excellent propaganda material out of it:
[snip]
Hello everybody!
As Gentoo approaches its 10th birthday I've been wondering how and where it is used. We used to have some great stories from companies in the weekly newsletter, but that
one has become very dormant a while ago.
I'd like to collect your success stories, endorsements and case studies so we can present to the rest of the world how using Gentoo makes your life easier and is totally
awesome. If you don't want to have that information public I'll gladly anonymize it as long as I can be reasonably certain that you really exist. What is important is
that you, if you actively use it in a commercial environment, write me whatever you think is important. Or you motivate someone you know to write it. Do your contribution
to making things better :)
Everything from "I use it and it's great!" to a story starting on a rainy day in November 1885 is good. Don't be afraid, I'll work with you on making it into something
readable.
And if you have specific criticism I'll take that too - maybe we can find an easy way to improve things. That is in your best interest too, so go ahead. Invest a few
minutes of your time so we can save you more time!
[snip]
If you think you can contribute something just send me an email and I'll see what I can do.
|
Hardware, Windows, Pain (September 26, 2009, 08:06 UTC)
So after the previous post I had another computer to set up; yes seems like I spend all the Saturdays this way lately. This time it’s a Fujitsu-Siemens branded computer; unfortunately, it had quite a few issues:
- no PS/2 ports, and the BIOS does not seem to initialise USB HID keyboards soon enough; my recovery station used a Microsoft PS/2 keyboard, and my only USB keyboard is Apple’s… Apple’s keyboards are HID and with a hub in the middle, which that BIOS didn’t like; got a new USB keyboard to work around this;
- while the computer was shipped with a valid Windows XP license, the label was tore apart; result: I had to recover the product key from the running system;
- of course, I didn’t have the administrator password; one very quick ophcrack later, I have it (too bad sysrescuecd doesn’t ship with ophcrack by default);
- the system has a SiS-based motherboard (which incidentally comes with a Via Firewire chip, but that doesn’t really matter); SiS website, as I commented on the other post, have both two click-through license agreements and captcha to download the drivers;
- of course I had to make a backup; partimaged refuses to receive the image from the client, both the client and the server gets stuck on the same socket, the former receiving and the latter accepting;
- the SiS on-board Gigabit Ethernet card… fails with the Linux driver, that’s both with 2.6.27 and 2.6.31 (different versions of SysRescueCD); neither kernels enabled Gigabit transfer (and the cable is good); the first froze in 10 minutes, the latter in an hour and something;
- the firewire-net module does not work at all; after updating SysRescue CD 1.2.0 → 1.3.0, where the module is at least present, and setting up the two firewire0 interfaces… nothing happens, I cannot ping the two sides…
And I don’t even want to wonder what will happen when I’ll finally be able to install Windows on it. I guess if I start doing this kind of support as a job, I’ll have to fetch some extra hardware, like Linux-compatible USB network adapters, fast external drive bays (I have seen one model that allows you to just plug in a 3.5" or 2.5" drive without having to screw it on something), and a dedicated external hard drive for backups. Not that I’d like to do this as a job, but it generally adds up.
|
September 25, 2009
So I got a new video card, since the old one was quite fuzzy (compiz went haywire repeatedly, or froze, or emacs decided to ovrewrite the window instead of clearing it before scrolling, the Tyan logo at boot up had the wrong colours, …). Since finding r500 cards on the market is near-impossible, I got an HD4350; I got one that would support 1920×1440 resolution, which seems to be available on some pretty high-end 24" monitors, which hopefully one day I’ll get (the 20" feels small lately).
Now, since this also has an r700-series CPU, I had to fiddle quite a bit to get it to work, and the results are, sincerely, not extremely nice.
First stop: trying the experimental radeon driver with all the extra support enabled. Using GIT versions of the driver, mesa, libdrm and the kernel itself (long story anyway), I get to the point it actually starts up after creating the modeline manually (because otherwise the monitor gets out of range… on a DVI connection). It seems to work, KMS enabled and all the stuff.. it worked fine, for a few hours, then it kernel panicked (and the panic wasn’t sent to the serial console, just the vga console!).
Second stop: non-KMS drivers, still with all the GIT software… it works, sort-of. When compiz is enabled (and I use compiz to be more productive: desktop wall and obscured non-focus windows are definitely useful), menus and textboxes corrupts… to the point of being unusable.
At the end, I had to install ati-drivers, and I’m now running the proprietary version of the drivers; on the upside, it works quite decently for now. I’ll stick this way until radeon can deal with this decently, which means when KMS won’t freeze my system. Maybe 2.6.23?
|
Google Android troubles (September 25, 2009, 16:21 UTC)
Oh boy, it seems like I'm using pirated software on my HTC Magic. I actually never realised that market, Youtube and other Android applications were closed source. So much for all they hype about Android being open source.
When I bought my Android phone a few months back I had my reservations about using Google services, but OTOH I needed a proper PIM solution and since everybody talked about open source Android I bought an Android phone almost as soon as they were available here in .dk.
My initial impression was that it needed more work, however the market application saved the day. Also most PIM tools worked ok, though some had quirks. Furthermore I missed a proper email client and bluetooth tethering. So I ended up rooting the phone and installing Cyanogenmod, which I was more happy with. Though I'm still not highly impressed with Android. However it seems like Google just tried shut down Cyanogenmod:-( I just hope that they will work something out or I might soon be off to find another PIM solution that integrate mobile and laptop properly.
|
What amateur radio is not… (September 25, 2009, 15:17 UTC)
Well, I really didn’t think I’d be writing a post like this.
This is following on from, and indirectly in reply to, an operator who decided to call in on the Australia-Wide Night-Owl and Insomnia net which is held every Friday night at 3595kHz.
Now, this net is pretty laid back… all are welcome. There are however, some things that just are not done on radio. Just as much as they are not done here on the internet. One of them, is to air dirty laundry on air.
Without going into detail… we had an operator call in from Victoria (a VK3V.. call, standard licensee) who then proceeded to make allegations about the off-air activities of another operator (VK2.., advanced licensee), in particular, the allegations involved claims of abusive phone calls and threats. The VK2 station responded pointing out some other misdemeanors allegedly purpotrated by the VK3 station, before (thankfully) moving on with the net. Thank heavens both had the decency to leave it there rather than tie up net time arguing.
Now, undoubtedly, the vast majority (me included) are not privy to all the information. They may be completely false, or there may be some truth to them. That isn’t for me to decide and does not concirn me. What I object to, is the usage of the amateur bands, as the platform for this kind of debate. It does not help any of the participants, or bystanders at all… and perhaps what both sides should realise here, is that by airing this material on-air, they are opening themselves up for a potential defamation case.
It is no different to me for instance, making similar allegations on this site… I could be sued for defamation. This is one of the reasons why I did not reveal the callsigns, or even the names of the guilty culprits. In the past, I recorded the net and provided it as a podcast (and had I done this, the recording would have been up for the world to hear)… but sadly the computer that I used for this is not operational at the moment. In any case, those who were listening, know to whom I refer.
I would ask that all people, who make use of radiocommunications services, whether it be amateur, citizen’s band, marine, airband or any other service out there… please bear this in mind. Your personal squabbles have no place on the air, as I for one (and likely countless others) am not interested in hearing them.
|
Codeswarm revisited (September 25, 2009, 12:11 UTC)
Some people have asked me under what license I published my CodeSwarm video.
Usually I don't care, but to make it clear:
This video
is now officially licensed under the Creative Commons Attribution-Share Alike license.
To make things more interesting I've published the CVS log and
preprocessed XML used to render the animation.
As they are just created by automated scripts I see no creative input worth a copyright, so they are released as-is.
The config file etc. are trivial to create, so just play around and see what happens. It's mostly self-explaining :)
That's all for now.
|
September 24, 2009
And yes, I am still here
Military service is really cool so far . Lets hope it will stay this way. Photos can be found here.
Anyway, recently I was assigned to a new project. I am supposed to setup an e-learning platform on a windows XP system.
Because I am really short of time I needed a quick and reliable solution.
So the first step was to download wampserver in order to have a fully operating hosting service on the current machine.
The most crusial issue was to choose the correct e-learning platform. Having done my research for three days, I ended up using moodle . It is really cool, with an extremely handy administrating panel, many many misc options about courses, categories, users etc. Pluse there is a huge users’ community all over the Inet.
I strongly suggested it if you need to setup up a similar platform in the future.
If you think that there is a better solution for my problem, please feel free to write it down
See you again soon!!
|
Gentoo Codeswarm (September 24, 2009, 01:09 UTC)
When I saw people do codeswarms of amarok and banshee and other small projects
I thought "Hey, I can do that too!"
Now, after some work, and lots of CPU-cycles used, I have some results to show.
And they are quite ... nice? awesome? For you to decide.
It all begins with pulling the data from cvs. Since I was in a hurry I did a
naughty thing - do a checkout from anoncvs.gentoo.org, run cvs log > logfile
That is naughty because it causes a huge load on the server. Polite persons
will create a local copy of the repository and run their own cvs server.
After ca. 50 minutes I had a logfile of 456926138 bytes, or roughly 450MB.
This gets transformed into a list of events for codeswarm. The transformation
itself is quite fast, but takes lots of RAM. In this case just over a gigabyte.
So there I was with a 220MB XML dump to feed into the renderer ...
The first attempt died nicely because the default of using 1GB RAM cripples the
render speed. Well, actually, my first first attempt died a horrible death
because some [censored] in the Java world don't check what dynamic objects they
load. And this means I had to run it all in a 32bit chroot. Grate phun. Grrr :D
Processing that amount of data looked quite reasonable for the first hour or
so. Then it slowed down quite a bit, then even more. Increasing the memory
helped a lot - I just let the JVM have 3.5G (it's a crippled 32bit process
after all) and it effectively used ~2.5G. I think this shows the limitations of
the current approach quite well.
Still it was too slow and too dense. The amount of files overwhelmed the screen
so that it was looking very ... crowded
And that's a bit bland. I did notice that you can colour things, so obviously I
split by categories. The colours are mostly random, but seem to work well. And
in testing things I realized that the drawing time is negligible compared to
the physics / preprocessing, so obviously I increased the resolution
a
bit. Hey, we live in the modern times of Full HD ... why compromise with
legacy formats!
real 2876m48.775s
user 2897m44.342s
sys 10m28.831s
That's what "time" had to say about my little experiment. Almost 2 days of
CPU-time at 2.6Ghz ... and that's with a naughty tweak. I reduced the amount of
items because I realized that it was going to take Too Long (tm). So instead of
representing each file ... why not represent each directory as one "thing"?
filename = filename.replace('files/','')
filename = filename.replace('/var/cvsroot/gentoo-x86/','')
filename = filename.replace('Attic','')
filename = "/".join(filename.split('/')[:-1])
That's all the mods I needed - strip the repo location at the front, fold
files/ and Attic/ away and cut off the filename. Ends up with
"category/package" instead, which for the purposes of Gentoo is a much more
useful identifier. And the rendering time went down from one frame every 30
minutes worst case to about one frame every 3 minutes worst case. Y'know, the
"unmodified" version is still processing after over 118 hours CPU time ... not
that nice :)
One positive effect is that it reduces the input from over 200MB to just around
100MB.
Now after 48h CPU I have 13367 single PNGs with a total size of pretty exactly
5GB. Feeding those into mencoder generates 557.8 seconds of video with an
average bitrate of 1737.2kB. The encoding takes 22 minutes walltime or 40
minutes CPU-time - in other words mencoder uses two threads properly. Good to
know!
So just to warn you, the result of my little experiment is a high-bitrate 1080p
video. It is about 116MB in size ...
Get it here
(US mirror)
Enjoy!
|
September 23, 2009
Here we go again. This time, we're going for the double sweepstakes as we're trying to stabilize both libxcb 1.4 and xorg-server 1.6!
For once, the server upgrade shouldn't be too hard and the server upgrade guide is remarkably slim. There's been no change in input, nor HAL, nor just about anything else for most users.
Only Intel users might have a few surprises with DRI2 and UXA. But at this point, they should be good surprises 
However, the libxcb upgrade is going to cause more troubles for some users. If you are/were using x11-libs/libX11 with USE="xcb", then you might have to rebuild lots of packages. This is why we've taken such a long time to unmask and stabilize libxcb 1.4. But now, we've worked hard to write a proper libxcb upgrade guide, which users are definitely going to want to read.
I would say the libxcb guide is more important than the xorg-server upgrade guide.
Anyhow, right now, I calling out for help among our stable users. If you've always wanted to contribute to Gentoo but didn't know how, here's your chance.
- Grab the stabilization list from bug #282290
- Append it to your
/etc/portage/package.keywords
- run :
emerge -DuNa world like always to update
Again, don't forget to read both upgrade guides before running the update, just so you don't start panicking when portage is unable to continue the upgrade.
As always, you're more than welcome to CC yourself in the stabilization tracker, but please DO NOT COMMENT IN THE TRACKER if you have issues, you'll just annoy everyone there. Just file a new bug and we'll look at it.
Don't forget that most X maintainers lurk in #gentoo-desktop on FreeNode if you have any questions.
That's all for today
|
new pear setup (September 23, 2009, 02:59 UTC)
I've just commited PEAR 1.8.1 to the tree (and will do 1.9.0 shortly to get us up to speed), but I wanted to let users know about a change in the way packages are installed. Actually, it only affects the base packages. Up until now, the PEAR-PEAR package in portage included all the necessary deps in one ebuild. With this new version, I've split each package up into its own ebuild.
There's a couple of reasons for this, but the most important is that it will give us flexibility to deal with changes from upstream. For example, with 1.8.1 and above, PEAR changed it's base XML dependency to XML_Util. That one was already in the tree, and so the new pear base system relies on that. If the other base ones change between versions, we can focus on that.
Another nice little change is that the base system ebuild now is just dev-php/pear. So, "emerge pear" and you're done.
The new versions are all currently marked as unstable across the arches. I would appreciate any and all feedback on the change. I'm still a bit skeptical that this is the best approach, and a bit nervous at any fallout that may occur, so please file bug reports and let me know if you have any issues. Thanks, all.
|
September 22, 2009
I'm posting this one hoping that someone can help me out, because it's one of the few remaining reasons I don't use Firefox as my main browser. I still use Seamonkey as my default, but the Javascript parsing is soo much slower than everything else, it'd be nice to switch.
Firefox has this find as you type feature, where if you hit / and then type in some words, it'll search and highlight it on the page. Great. Lots of browsers have that. Spanky. But, the problem with firefox begins with this little toolbar at the bottom of the browser that pops up as you are typing the text. It has a little dialog box titled Quick Find which fills in with whatever you were searching for. The main issue is that that toolbar will close itself automatically, and when it does, it steals focus from X back to Firefox.
That's particularly annoying for me because, in many instances, what will happen is I will search for something in Firefox using quick find, get what I'm looking for, and then switch to another program or window before the default timer has expired. If I start typing in that other window, when Firefox's bar closes, X focuses back on Firefox and part of my text goes in there instead. Kind of frustrating.
I've tinkered around with the about:config page and haven't found anything, and every now and then I check Google to see if I can find anyone else who has discovered a workaround, but I haven't found anything, so now I'm just trying to see if anyone else knows a solution.
I'd be happy with either disabling the toolbar completely or not having it go away, or whatever. The only part that bothers me is it stealing focus again.
For what it's worth, I'm on XFCE 4.4. No idea if it's an issue with other WMs.
|
September 21, 2009
Visualizing Gentoo profiles (September 21, 2009, 10:31 UTC)
To add a new USE flag, that's globally enabled for all Linux profiles, what's the minimum set of profiles that need to change? Deprecated profiles must be handled as well, for users that need to migrate still.
I ran into this today, while working on the USE=modules changes for linux-mod.eclass.
As an attempt to solve this, I munged up some GraphViz work to show profile inheritance, pictures as the end. Both sets have the trailing profiles "/desktop", "/developer", "/server" turned off for the 2008.0 and 10.0 releases, to cut down on the noise.
Graphs and script for download.
My answers as to which profiles:
- default-linux
- default/linux
- base
- embedded
Odd observations
- Several Prefix profiles (linux/{amd64,ia64,x86} link to 2008.0 profiles explicitly instead of the generic architecture)
- default/linux does not bring in base. Some profiles at a glance neglect this and might not have base brought in at all.
- "embedded" is all alone in the tree.
Thumbnail of one graph
Question for any skilled GraphViz users:
If all nodes in a given subgroup/cluster have an edge going to a single destination node, is there any way to get graphviz to replace them with a single fat edge from cluster to destination node?
|
So I recently was messing around with Opera 64bit on Gentoo and trying to get Java to work. The process was actually a lot easier than I expected. First I made sure I had the latest sun-jdk installed, which was dev-java/sun-jdk-1.6.0.16 in this case. Now to make it work with Opera I did the following:
cd /opt/sun-jdk-1.6.0.16/jre/lib/amd64/
Opera doesn’t seem to work by default like this, probably because it ignores the plugin and uses java directly. Because of this, you need to symlink the libjvm.so so Opera can find it:
ln -s server/libjvm.so .
Set opera to use /opt/sun-jdk-1.6.0.16/jre/lib/amd64/ as the java path and restart opera. All should be working now, you can check by following this test page: http://www.opera.com/media/applets/clock/
If anyone knows a more proper way of doing this, be sure to let me know
|
September 19, 2009
How not to write an app (September 19, 2009, 22:02 UTC)
So it seems that
Ciaran is upset again. Which seems to be quite normal. But he has some good advice, and I thought I'd share some with you too.
Let's start with an easy one. Descriptive error messages. This is good:
$ bash -x foobar.sh
bash: foobar.sh: No such file or directory
This is not:
... In program paludis -ip portage:
... When performing install action from command line:
... When adding install target 'portage':
... When parsing user package dep spec 'portage':
... When parsing generic package dep spec 'portage':
... When disambiguating package name 'portage':
... When finding all versions in some arbitrary order from packages matching */portage with filter all matches filtered through supports action install:
... When loading entries for virtuals repository:
... When finding all versions sorted from packages matching sys-kernel/gentoo-sources with filter all matches filtered through supports action install:
... When generating metadata for ID 'sys-kernel/gentoo-sources-2.6.28-r5::gentoo':
... When running an ebuild command on 'sys-kernel/gentoo-sources-2.6.28-r5::gentoo':
... When running ebuild command to generate metadata for 'sys-kernel/gentoo-sources-2.6.28-r5::gentoo':
... When running command 'sandbox /usr/libexec/paludis/ebuild.bash '/usr/portage/sys-kernel/gentoo-sources/gentoo-sources-2.6.28-r5.ebuild' metadata':
... In ebuild pipe command handler for 'LOG0qaglobal scope tr':
... global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] (same context) global scope tr
paludis@1253390790: [QA e.child.message] In thread ID '19463':
That's about 1/35th of the whole output ... which is just drowning out any reasonable information.
Complete output is just under 750 lines, so good luck finding any error. But I guess there's a reason for that.
Now something really neat:
... In program paludis -ip portage:
... When performing install action from command line:
... When adding install target 'portage':
... When parsing user package dep spec 'portage':
... When parsing generic package dep spec 'portage':
... When disambiguating package name 'portage':
... Package name 'portage' is ambiguous, assuming you meant 'sys-apps/portage' (candidates were 'sys-apps/portage', 'virtual/portage')
Let me say this as clearly as possible. Never assume. If you try to guess what I might have meant to say you may do something
I explicitly do not want to happen or even something which breaks things. If your app is unable to unambiguously parse my input quit.
Failure to do so will reduce in lots of tears and you falling on sharp objects. Multiple times.
And of course ...
Fetch error:
* In program paludis -ip portage:
* When performing install action from command line:
* When executing install task:
* When performing pretend actions:
* When fetching 'dev-db/sqlite-3.6.18:3::gentoo':
* Fetch error: Fetch of 'dev-db/sqlite-3.6.18:3::gentoo' failed
I don't think that means what you think it does. A pretend action that doesn't only pretend, but claims to fetch things?
That better be a small oopsie in the explanation that doesn't, in any way, describe what actually happens.
Now, Ciaran. You can try to ridicule me through your blog. You can relabel comments as my name if you don't like them (it's your
blog after all - even though that's exquisitely rude) and then deny you did it (we call that lying).
But if you have to do so do it directly. Don't try to be funny (you saw what that did in the Funtoo-uses-Internet-Explorer Situation).
Don't label any criticism as FUD (see "Ten Ways PMS Raped your Baby").
And if you fork PMS then do so. You have your own hosting already.
Now all you need is your own mailinglist and please leave those that work on the official version alone. And don't command us around, we're not your slaves.
Think you can do that? That would be awesome. Thanks!
|
Reality vs. PMS (September 19, 2009, 21:23 UTC)
If you ever get bored enough (which, on an epic scale from fighting with the
Spartans at the Thermopylae to reading the telephone book should be just around
counting the grains of rice in a 50kg-bag) and start reading PMS, you might get a few of
those "Wait a minute ..." thoughts that happen when things aren't quite right.
One of those is around page 26, where PMS defines that bash 3.0 or higher is to
be used. Which actually means "it has to be bash 3.0 compatible, but may be any
higher version". Or to be even more precise: Ebuilds are not allowed to use any
features not in bash 3.0, but the execution environment may be any higher version
if it is compatible.
How could we have a straightforward text that doesn't need
interpretation! The lack of flamewars! The lack of circular reasoning!
Now if you look around on your installed machines you may notice that:
- The oldest available ebuild is app-shells/bash-3.1_p17
- Portage depends on >=app-shells/bash-3.2
- Current stable on amd64 and x86 is bash4
Which means that you can't even use bash 3.0 anymore. And if you had an install
that old you'd run into many upgrade issues - portage blocking bash, bash
blocking portage, portage being unable to read EAPI1 ebuilds. A big mess with
no clean upgrade path ... apart from injecting binpkgs and pretending that mess
never happened.
From bash Changelog:
*bash-3.0-r12 (05 Jul 2005)
*bash-3.1 (10 Dec 2005)
*bash-3.2 (12 Oct 2006)
*bash-4.0 (21 Feb 2009)
So anyone not having bash 3.2 hasn't updated since May 2007. Seriously. That's
when bash-3.2_p17 went stable. (October was just when the ebuild was added, the
Changelogs are a bit tricky to parse)
So for all intensive purposes (and of course all intents and purposes) we can
assume bash 3.2 installed anyway. Plus there's no older ebuild anyway, apart
from the 3.1_p17 that is a leftover from a horrible upgrade path.
Even worse, for at least a year there has been a "contamination" of the tree in
the form of bash 3.2 features like the "+=" assignment. Which means that some
ebuilds won't work with 3.0 anyway. Extra bonus? Many eclasses use it, which
means, in short, that you need 3.2 or higher. And it has been tolerated (maybe
even encouraged) for such a long time that there's no way to undo that change
now.
The obvious thing to do (fix PMS) has been ignored for quite some time. So I
thought I'd send an email to the gentoo-pms mailinglist to get it sorted out.
Guess what?
The amazing one-character patch was denied.
That's the best way to make PMS irrelevant - refuse to let it document reality.
|
September 18, 2009
Searched high and low to find this silly little info. Finally found it here.
# define a pattern for the host url finding
# %% => % sign
# %0 => domain name + tld
# %1 => tld
# %2 => domain name without tld
# %3 => subdomain 1 name
# %4 => subdomain 2 name
# Set default vhost server location here
evhost.path-pattern = "/www/%0/htdocs"
# If we don't have a %3, default to htdocs
$HTTP["host"] =~ "^[^.]+\.[^.]+$" {
evhost.path-pattern = "/www/%2.%1/htdocs/"
}
# If we don't have a %4, find the subdomain
$HTTP["host"] =~ "^[^.]+\.[^.]+\.[^.]+$" {
evhost.path-pattern = "/www/%2.%1/subdomains/%3/"
}
# If we have a %4, find the subdomain2.subdomain1. If we have have %4+, use %4
# anyway. If you have 4+, write a explicit rule for doc-root.
$HTTP["host"] =~ "^.+\.[^.]+\.[^.]+\.[^.]+$" {
evhost.path-pattern = "/www/%2.%1/subdomains/%4.%3/"
}
Now my only wishlist is to do something similar for var.logdir, but %[1-4] is only set up with evhost. So, do you do anything smarter than this for your server?
|
|