Archive for category Gentoo
GPytage 0.3.0 RC1 Unleashed
Posted by Ken in Gentoo, Programming, Python on December 19, 2009
Well, after a lot of hacking GPytage 0.3.0 RC1 is finally ready to be released. This version underwent nearly a complete rewrite to make coding it much easier and of course improve the end users experience of editing Portage’s config files. Notable features of this release include:
- Supports recursive directory support now, where the old release was limited to one depth of a package.foo directory
- Improved creation, deletion, and renaming of files. You can now rightclick in the leftpanel on the desired file and get these options as well
- Copy and Paste support now implemented
- When editing an entry you can now hit tab to save the change and move to the next editable field.
- When adding a new file, reverting, deleting, or a similar operation is executed the folder you were currently in is now reselected after GPytage reloads its database
GPytage should be hitting the Portage tree in the next few hours. A simple
should net you package for testing. It will be keyworded ~arch, so stable users will need to add an entry to package.keywords to install it.
While this is a release candidate, there should not be any bugs floating around. If you find any bugs or want to suggest an improvement don’t hesitate to either post it here or at https://gna.org/projects/gpytage/
GPytage-0.3.0 RC1
Looking forward to hearing everyone’s feedback.
GPytage rewrite nearing completion
Posted by Ken in Gentoo, Linux, Programming, Python on December 5, 2009
So recently I’ve gotten back into the game on rewriting my application GPytage so it’s a bit easier to work with. For those of you who don’t know what GPytage is, it’s a GTK application for managing Portage’s config files traditionally located in
written with PyGTK. The application is coming along nicely with its new backend, but still has a bit of a way to go before a rc is released. I’d say the current svn trunk is about beta status at the moment, it’s safe to use but all the features just aren’t implemented yet. Basic editing works right now as does saving and creating new files. It also supports infinitely recursive folders and files which the older version did not.
A quick list of the top of my head that I’ve still got to implement:
- Deleting files
- Renaming files
- Copy, Paste, Cut, etc
- Possibly drag and drop support
- Figures out sane keybindings for adding and deleting a row. I was thinking ctrl+e for inserting a new row and ctrl+d for deleting a row but I really have no idea, recommendations are welcome
- Converting a configuration file into the directory layout like the older GPytage did
That’s all I can think of off the top of my head. The svn trunk should be good for testing right now, I promise not to horribly break it. It would be appreciated if people would checkout the current trunk and give it a whirl and comment about how you liked, disliked, hated, loved, or would change about GPytage.
For testing purposes after checking out the svn trunk just cd into the scripts directory and run
. Then you should see the application in all its glory. If you feel uneasy about letting GPytage have actual access to your portage files, simply create a /etc/testportage directory that is identical to the old one such as
. This way GPytage can’t cause any harm. If you use the /etc/testportage directory, you would launch GPytage with
.
Feel free to drop by and say hi in #gpytage on the Freenode irc network.
trunk r230
Java with Opera 10 on Gentoo AMD64
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:
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:
Set opera to use
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
X11 forwarding a chroot
I figured I’d blog this so I wouldn’t stop forgetting how to do this and possibly learn a “better” way to do this. I’m going to assume that vanilla x11 forwarding works outside the chroot as a starting point.
The process is relatively simple that I use. First I ssh into my server as a user using the -Y option like so:
Then I su to root:
Now comes the part that makes the forwarding work. We need to export the magic cookie that our current session is using so that the chroot can import it and use it. We do this like so:
This saves the magic cookie info into a file under /tmp so that we may access it later. Now its time to chroot in:
and I generally like to set my PS1 to remind me that it’s a chroot but is not necessary:
Now we need to import the magic cookie after chrooting in:
At this point x11 forwarding should now be working in the chroot. An easy way to test is to simply launch an xterm inside the chroot.
If the xterm appears everything is in working condition. At this point you should probably delete the
file for security.
GLEP 55 Madness
It’s the hottest new flamewar topic in Gentoo. But I still have to ask, why? The entire idea to me seems stupid. Why must we butcher filenames to achieve this? OK, let’s look at the GLEP’s proposed problem.
The current way of specifying the EAPI in ebuilds is flawed. In order to get the EAPI the package manager needs to source the ebuild, which itself needs the EAPI in the first place. Otherwise it imposes a serious limitation, namely every ebuild, using any of the future EAPIs, will have to be source’able by old package managers and hence there is no way to do any of the following: [...]
Oh noes! And the proposed “solution”:
The proposed solution is to use EAPI-suffixed file extensions for ebuilds. This allows package managers to trivially read the EAPI from the ebuild filename. It is also backwards compatible, because currently ebuilds are recognised by the .ebuild file extension and hence EAPI-suffixed ebuilds are simply ignored by the package managers.
Alright, I don’t see how the package manager developers cannot develop an easier solution. How about improving what we already are doing? All of our ebuilds with EAPI have the
string in the ebuild. Why cannot we formalize and set guidelines exactly where this line should be (such as the top of the ebuild) and the format of the string. If we did this, then figuring out the current ebuild EAPI would be insanely trivial.
With the string formalized, package managers wouldn’t even need to “source” the file to figure out what EAPI it is. They could simply use $(insert favorite method of extracting a string) to grab the EAPI line and then pass it to the package manager to figure out what to do with it. No butchering of the filenames and other nonsense. The EAPI string would have a sane format and would easily be extractable to be passed to the package manager. It would then be up to the package manager to do with the situation thereafter.
I don’t see how we can’t use this as a solution. I better revisit those three bullets under problems to make sure I try to make some sense.
Change the behaviour of inherit in any way (for example, to extend or change eclass functionality).
Well since the package manager doesn’t need to source the thing to find the sanely formatted EAPI string inherit isn’t going to randomly implode into a billion pieces. This is essentially the same as shoving the string in the filename, except doesn’t make the filenames ugly and still works.
Add new global scope functions in any sane way.
Same as above, if the EAPI doesn’t match just abort the mission.
Extend versioning rules in an EAPI – for example, addition of the scm suffix – GLEP54
Well, since we have a sane format for the EAPI string, this shouldn’t be a problem at all.
BUT WHAT ABOUT THE BACKWARDS COMPATIBILITY !!1?!1!?!
Umm, every new EAPI pretty much breaks backwards compatibility. Either the PM knows how to handle the new EAPI or it should tell the user to upgrade or something and die gracefully. I see no difference between a sane line in the filename or a sane line inside the file. One of these solutions requires a bigger change than the other.
I don’t want to even argue you people that go “omg what if we use XML or binary or some other type of crap instead of bash ebuids”. Well then, you just ran the backwards compatibility baby over with a train and its moot.
At the end of the day no solution is perfect and there will be code to be written. Nothing can truly predict what we will need to accommodate the future.
Smokeping installation fun
I’ve attempted to install smokeping many times before, sometimes successful and sometimes not. I decided today to give it a shot again and struggle through it. At first I thought I was going to have to go through an immense amount of trouble as I had remembered from the past, but I was wrong. It seems the new smokeping ebuild with the apache2 USE flag makes it extremely easy. After realizing this, it was as simple as editing
, starting the init script, and pointing my browser to
. (I already had -D PERL added to apache and edited the installed smokeping.conf module to allow anyone to access it)
I’ve never been able to install smokeping this easily before. I just want to give a thanks to the developers that worked on the smokeping ebuild to make it this easy.
Now if only I could get
to just
…
Small Portage Annoyance
It’s the usual routine of running
and then
. Sometimes I look over the list, sometimes I don’t. Usually it’s just to see if one package wants to upgrade itself — the kernel. Since portage does not offer any kind of “blacklist” for world, I must manually add each new kernel update to package.mask. I do not wish to update my kernel as often as it’s updated, but I want everything else up to date. I run unstable, so this routine happens fairly often.
I wish portage had another configuration file that sort of “blacklisted” packages from world or anything non explicit from upgrading packages listed in it like the kernel. World could still list the update for those who want a visual on when an update is available but don’t want to update just yet. I’m aware package.provided can somewhat offer this, but portage complains loudly about it. I guess I’m looking for some kind of package exclude option on a merge.
It’s entirely possible this is already implemented and I just don’t know, if so please tell.
Ignuit moved to portage
So for all of those waiting for ignuit to hit the portage tree, it has finally happened. After receiving some requests from users to add it to the tree, I decided to stop being lazy and actually move it to the tree. Ignuit should be hitting the sync mirrors shortly.
I await the massive surge of zomg you coded this ebuild completely wrong and/or bug reports 
Banshee and the Zen
As some of you may remember from an earlier post I was in pursuit of a new mp3 player. I’m happy to report that a few weeks ago I was gifted a shiny new Creative Zen 4GB and it has been awesome. It features an additional SD slot for when I fill up the 4GB’s of space it comes with.(which is already almost full…) It has pretty much all the basic features I wanted, decent battery life, and a fm radio. Nothing exotic required really. Came with a plastic case that has saved the screen from a million scratches already as well. Pity it can’t play ogg files. Syncing the Zen with Linux has been the fun part. After failure or just dissatisfaction of gnomad2 and rhythmbox I decided to use banshee. Yes, that evil mono based music player. I have to admit though that it is pretty snazzy and awesome. It’s last.fm plugin has been superb for me which was a huge bonus. Banshee syncs my entire music collection to the Zen in one click which is awesome. I was unable to do that with the other stuff I tried. (Yes I’m sure amarok would have worked, but I run GNOME and KDE stuff doesn’t really compile here… I busted something related to not finding the installed kdelibs). Overall I’m quite satisfied with how Banshee has performed and the layout of its interface. The only current problem I have so far with Banshee and my Creative Zen is that when I sync my music library over it does not sync the album art. This is somewhat disappointing, but definitely not any kind of a show stopper. I assume it could possibly be that it is not supported with banshee+zen, or it’s because I do not have banshee set up to copy/organize music to ~/Music. If anyone knows I would greatly appreciate it if someone dropped some hints.
Random Server Panic
So a few days back I was ssh’d into my server as usual for IRC and when I got around to looking at it I noticed I had been dropped back to my zsh shell on my laptop disconnected. At first I thought maybe I just lost connection due to a random network failure so I tried to reconnect. Timed out. So I pull up opera and try to load its cacti status page and it seemed apache was dead and not responding. Awesome. At this point I wasn’t sure what to make of the situation. I get a bunch of power failures so that could have been the cause, but usually my server reboots itself after the power is restored. Perhaps the network interfaces went down, or my psu blew out I thought. Unlikely, so I assume it had a kernel panic. I sent off an email about it and was told the server was still running, so no power or psu failure. I had the machine rebooted as there was nothing I could do and everything came back up as expected. Looking through all of the logs didn’t reveal anything to indicate the cause of the downtime. Temperatures were all within normal range according to cacti so it wasn’t an overheating problem. Logs didn’t show anything about the network interface being disabled or failures of any kind, so I believe it just outright had a panic. It is slightly irritating that nothing at all in the logs gives an indication of why it had a kernel panic. I assume if I had physical access the console would have given some information but unfortunately it was a remote machine. For now I’ve enabled an automatic reboot on kernel panics so I don’t have to get it manually rebooted if it ever happens again. Guess I’ll never know why it randomly went down in flames after 50 days of running perfectly fine.