Archive for linux

repositories and package management

Or, what to do when you want to update?

I’ve been thinking about this in light of my previous entry plus the annoyinggood comments my friend made.

There are basically three options to update an application on a Linux distro:

  1. From that distro’s official repositories
  2. From “unofficial” repositories
  3. From source files

Really, all three have their pros and cons. The safest and most prudent approach is to work from official (and, really, popular or widely used as well) repositories. This is least likely to break things and as long as the package managers (apt, rpm, yast, Synaptic Package Manager, and so on and so forth) are used, uninstallation is clean as well. But, I am left dependent on when the folks managing the repositories decide to check in new packages.

This brings me to the second option (which is a slightly fuzzy distinction here, but I’ll make it anyway). There are repositories that individuals put together, often for particular projects, although others put together more general and very useful repositories (such as treviño’s). These repositories, while they make it easier to install more complex updates to applications, may still break other things in the distro as they are usually too narrowly focused on the app to make sure the distro as a whole is okay. This is the problem I had with updating gtkpod: while I used repositories to install it, it broke several applications because of the conflicts it created by updating shared libraries (which were not backward compatible as it turned out).

The third option, to download source and compile can sometimes avoid these problems (for example, by making a private copy of some of the libraries so as to leave the older ones in place for the distro and yet make the newer items available). But the largest con with these are that it’s often difficult to uninstall these things (unless you have a good idea of what you’re doing) and it’s very easy to forget what you’ve done later on. Come a distro upgrade and there may well be two versions of something hanging about. Or, it breaks the custom install and time is required to reconcile the two again. It’s also difficult to resolve things if the compile just doesn’t work, and it’s impossibel to tweak things (eg to have two separate libraries) unless you really are unix-conversant.

Different people take different approaches. One friend is willing to wait and just use official repositories. Another is willing to go for various different things as long as its repository based. I will sometimes compile things from source partly because I can, and partly because I do use things that aren’t actually available any other way. But now and then I get tripped up by zooming a bit too quickly to the third option. For starters, I could have saved myself a little trouble with Flash 9 by using treviño’s handy repository…

Even so, one thing I noticed with new versions (eg, going from Ubuntu’s Dapper Drake to Edgy Eft) is that the newer version sometimes removes or replaces previously installed packages, even those installed from the repository. I can’t remember offhand all of the ones that were so affected, but Network Manager (the best linux app for handling wireless) was one of them. Going from Warty to Dapper, it disappeared entirely, and I threw my hands up and wrote a script. Then going to Edgy, it didn’t like my script anymore, and looking about, I realized Network Manager was now integrated into the desktop. So there’s always that. Sometimes packages are simply removed. I then have to remember what I did have so I can restore it.

To fill in these holes, one of the things I do is I keep a file (I call mine “log” simply enough) in which I detail all the things I do to my Linux installation, and from where/how. Later on, that saves me time figuring out what I did and which programs I do have. It helped me reinstall Flash 9 as well; I’d recorded where I got the instructions and what happened when I followed them.

In any installation, I note the application, the version, the relevant webpages, whether I used apt-get, whether i added repositories (and if so which) and whether I compiled from source (in which case I frequently cut and paste the entire transcript from the terminal into the log. This file is so important I back it up on a jump drive so that I can always get at it.

del.icio.us:repositories and package management  digg:repositories and package management

Comments

that dratted flash 9 plugin for firefox…

Update:
I was asked “Why not apt?” As it turns out, the repositories still have Flash 7 listed in them. Nevertheless, this article may be a better/different way to install Flash 9, especially as it looks like it would include automatic updating, and it uses a more standard way of updating (which generally should be via apt; the tricky issue as always is when one wants something not in the repositories).

So earlier this month I installed Flash 9 for Linux on my Firefox from a HowtoForge article. Flash is one of those necessary evils*, I suppose, but it gets more difficult to ignore entirely so while I refuse to use it myself, I do install it so I can see what the heck is going on in some of the sites I visit. Not to mention that YouTube and VideoEgg both use Flash (the latter version 9 in particular).

To install it, I went to the Adobe download site. It automatically detects the incoming OS, so this step needs to be done from the Linux OS. This brings up a tar.gz file which I downloaded and saved. Using a terminal window, I unpacked it via

tar xvfz install_flash_player_9_linux.tar.gz

That gave me a new directory, which I cd’d to. I ran the installer:

sudo ./flashplayer-installer

After getting the root password, there’s some information and verbiage, until eventually it asks:

Please enter the installation path of the Mozilla, SeaMonkey, or Firefox browser...

At this point, I entered /usr/lib/firefox — more on that in a moment. After doing this, it chugged along for a few more seconds before informing me it was done. So now I fired up a Firefox window and all looked well. This was back in the first week of February.

Then about a week ago, I started noticing little oddities. Some of the places I was visiting started using something called VideoEgg, which simply would not run — it just spun in place forever as if it was downloading. I got very hit and miss behaviors, so I checked my plugins on Firefox via about:plugins. Lo and behold, it said I had version 7! Scratching my head, I went through the same process as above, checked again, and it showed 9. This kind of thing made me grumpy, especially when I spotted the same problem next time I started up Firefox. This time I kept searching on “Shockwave” in the about:plugins page and voila! I found I had both versions installed; and the behavior depended on which came up first.

I knew, from that plugin page, the relevant file name is libflashplayer.so. So I used a terminal window and looked for it using

locate libflashplayer.so

and what I found was a copy in /usr/lib/firefox/plugins as well as in ~/.mozilla/plugins. So I renamed the one in .mozilla (as having the older date) to another name, shut Firefox down, and started it up again. This time only one version of Flash (yay!) and at version 9 (yay!). It turns out that Firefox pretty much looks at four places: the global Mozilla and Firefox directories, and the local (home account) Mozilla and Firefox directories. It will find plugins in all of them (and probably a few more for all I know) so using any of these directories in the initial flashplayer-installer script will “work” but if it isn’t the same directory that the previous flash installation resides in, that double plugin situation will occur.

So, what I would recommend before installing Flash 9 is to first see where any older flash plugins are residing (via the locate command above) and either use that as the directory to give to the original flashplayer-installer script, or clean up afterwards, as I did.

And have I got a test site for Flash.. :-O


*Look at the date on that Flash article!. There are numerous other reasons to hate it as well, but the mockery it makes of accessibility issues, particularly for the visually impaired, is the number one for me.

del.icio.us:that dratted flash 9 plugin for firefox...  digg:that dratted flash 9 plugin for firefox...

Comments

excursions with kopete

What a trip…I decided to see if I could get a webcam running properly under Ubuntu. The answer was eventually yes, but it was a little bit of work.

First of all I did a little homework and found that Logitech webcams were the most likely to be recognized by Linux. The company, bless ‘em, works with the linux community to provide the rest of us with the correct drivers. There’s a very nice list of supported webcams here, it’s worth checking this out first. Some webcams will work “out of the box”, but most will probably need to have either spca5xx (linux kernel versions prior to 2.6.11) or gspcav1 (versions after, which includes Ubuntu’s Edgy Eft).

Now, as far as IM’s go, there are pretty much two choices: amsn (for MSN, which I didn’t even bother with, because I don’t even have an msn account) and kopete which supports both MSN and Yahoo (among others), with webcam support on MSN/Yahoo protocols. I have a Yahoo account (as does my friend with whom I tested) so that’s what I used.

I ordered the Logitech (QuickCam Chat) and in the meantime tested out receiving the images from my friend (who ran hers on the regular Yahoo application from her Windows XP setup). The initial trial run was disappointing as all I ever got from her webcam was the first still in the stream and nothing further. Upon some investigation, which included the helpful folks at the kopete-devel mailing list, who informed me that my version, 0.12.3, needed to be updated to 0.12.4.

At this point, I got a little bit confused, because I could find no deb (or other) package for kopete 0.12.4, and when I said that, the response was “There is no separate tarball.” After puzzling over that for a while, I realized what they meant was that it was all rolled in with KDE itself. That is to say, if I upgraded from KDE 3.5.5 (which is what’s in the Ubuntu Edgy Eft 6.10 distribution) to KDE 3.5.6, kopete 0.12.4 would come bundled with that. Oy. After noodling around that one for a while, I found these partial instructions for Kubuntu (other dists can look here). Once I incorporated the Riddell key, used the synaptic package manager to add one of the listed repositories (not forgetting to reload) and then, the important part, running the following command on the terminal:

sudo apt-get upgrade kubuntu-desktop

With that, I now had KDE 3.5.6 and by extension the upgraded kopete on my system. Woot! And when I fired up the connection with my friend, after a little fiddling on both our parts, her stream came through loud and clear. Double woot!!

So now the second part, getting it to recognize MY webcam (which had arrived yesterday :-D ). This went more quickly but was a bit wonkier. First of all, I had to install and use the gspcav1 wrapper. I followed both these sets of instructions more or less (I skipped some of the setup because my system is already set up to compile things): here and here. I have no idea why there are instructions for installing spca5xx on Edgy as the linux kernel on Edgy (check with uname -r on the command line) precludes the use of spca5xx. Use the first set of instructions if you’re installing the older spca5xx stuff for linux kernels prior to 2.6.11; the second set if you’re installing gspcav1. But note that either way you’ll modprob something called spca5xx so don’t let that surprise you.

And this time, my webcam was up and running and ran just fine on kopete to my friend’s screen. So it was all quite good. The only issue left is whether or not the webcam can be set somehow to be less choppy. It’s really got a horrendous refresh rate, and it must be possible to clear that up a bit? If any of you have suggestions, please feel free to let me know.

Hope this helped someone out. My understanding is that webcameras and the like remain a weak spot in Linux, and it’s certainly true nothing worked out of the box (I do understand some webcams do not need the spca5xx/gspcav1 wrapper, and do work when plugged in, so it might be worth finding those; I was a cheapskate and got the cheapest camera that seemed to work alright.) However, it wasn’t too bad getting it to work; the worst part was finding all the information.

I also made use of a nice quick little tool just to verify that the webcam worked (for some reason my friend isn’t at her computer 24/7 with HER webcam for testing purposes…) called camorama which I found available in the synaptic package manager as well. It was a handy utility to verify that the webcam was indeed working.

del.icio.us:excursions with kopete  digg:excursions with kopete

Comments

short and sweet (sort of): using an ipod with linux

Overview

With Ubuntu 6.06, the Gnome desktop, a video iPod plus a few programs, it’s pretty easy to install music on the iPod. The main things to keep in mind are these:

  1. Most free linux distros do not contain support for MP3 since it is a proprietary format. As a result, much of this will need to be installed first. Ubuntu users can use the tools EasyUbuntu, or Automatix (Mepis users too). For other distros, googling up instructions for installing various codecs, gstreamer libraries and such should provide the necessary instructions. More commercial installations probably already have the necessary items installed. There’s extensive documentation about this here. which is Ubuntu specific and very detailed.
  2. iPods can have two different filesystems: HFS+ is the Mac version, FAT32 the Window version. Generally, if an iPod is initialized with one operating system, the corresponding filesystem has already been set. My iPod has only ever connected with my Ubuntu setup, and that chose the FAT32 system. While Linux can handle either, generally it takes more tweaking, even kernel recompiles, to handle the Mac version; it seems easier overall to go with FAT32 (and all three O/S understand it, which is a potential bonus for some folk). There’s a tutorial here that discusses conversion of the file system if this is necessary.
  3. The music files must be in a format the iPod can play. The iPod supports
    AAC, MP3, and WAV. (This unfortunately leaves out several excellent open source formats such as Ogg Vorbis and FLAC.) This means that when songs are downloaded or ripped they must be in one of these formats. I chose MP3.

  4. The linux system must be able to recognize and mount the iPod. Dapper had no trouble at all with this. In fact it has the cutest little iPod icon for the mounted device. Generally speaking, the newer models with USB ports should not be problematic; if the iPod is first or second generation with firewire, there’s plenty of information via google search to deal with that.
  5. All told, two programs are necessary: one is to rip the music from the CDs in the correct format for the iPod, and the other is to sync the music over to the iPod. I used Sound Juicer to rip and gtkpod to sync
  6. MP3 files are tagged via ID3 so that the album, artist, and track information can be retrieved from the files. In most cases, the software that rips the music handles the basic tag info, but there are also other programs that will add additional tag information. There are different ID3 versions, and care must be taken that versions are not accidentally switched along the way (eg the ripper expects one, and the syncer the other). Sound Juicer, with the correct settings, will properly set up the basic tag info as it extracts the music.
  7. On Ubuntu, to eject the iPod (and stop the “do not disconnect” message, which will show as long as the iPod is mounted), make sure all programs such as gtkpod, Amarok, any filemanager displaying directories in the iPod, etc, are stopped, and then right click on the iPod icon and eject it or umount from command line. Otherwise the eject will fail with the message that other applications are using the iPod.

I found that the key to success lay in all the prep work on the music files I did before attempting to set them up on the iPod.

The basic sequence I am using now is:
Sound Juicer to rip the CD and then gtkpod to transfer them over. This is extremely basic! There’s no album cover art, no lyrics. Just album, artist, song names, track numbers, and playlists. I’m still working out the details of lyrics, album artwork, photos, and videoclips and will cover that in following articles.

Sound Juicer

Sound Juicer is the default CD ripper in Gnome. In Dapper, it pops up when an audio CD is inserted. The original configuration for Sound Juicer does not contain a profile for MP3, so the first step is to add such a profile.

This requires gstreamer-lame, id3v2mux. EasyUbuntu and Automatix should have installed these, but if not, searching through the Synaptic Package Manager should locate them. There’s extensive documentation about this here.

Start up SoundJuicer, and click on Edit->Preferences from the menu. In the dialog box near the bottom is a selection for different profiles, with an “Edit Profiles…” button to the right of this. A new dialog box will show; click on the New button along the top. For the Profile Name, I entered “CD Quality, MPG. The new profile is now listed in the list of profiles, so I could now select it and edit it. In this box, I put in CD Quality, Lossy for the profile name and MP3 for the description (to match the format of the predefined entries; there will now be two CD Quality, Lossy entries, but the type of file extension will distinguish between the two). The all important part is adding

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc preset=1001 ! id3v2mux

in the GStreamer Pipeline definition. For the file extension, I used mp3, and then I checked the Active? checkbox and saved it. Now back in the Preference dialog, I chose the new profile as the Output Format and closed the box.

At this point, SoundJuicer should rip MP3 format files without any trouble.

Some notes: I found SoundJuicer pretty straightforward to use. On the Dapper distro, it is the default application to pop up when an audio cd is inserted. It’s also available in the Applications->Sound & Media menu & installable from Synaptic Package Manager. It’s gnome based.

gtkpod

gtkpod is a small application that will build up a list of music files to be transferred over to the iPod and then sync it (actually transfer the chosen files) on demand. It can also copy files from the iPod back to the computer, and can do other management, such as delete files, etc. I got my copy through the Synaptic Package Manager, and other download versions are readily available.

The first thing to establish is the iTunesDB. This was completely non-obvious to me, but from the menu, Files->Read iTunesDB does the trick. I kept trying iTunesDB Sync and other approaches because the error message indicates that no syncing has happened, therefore, etc. and so on. Once I got that, then I was confused with how to set up a list of files to go to the iPod. I found it was necessary to click on the “iPod” part on the left first. I had been building lists on the “Local” section (which is still sitting there) and could not for the life of me figure out how to get it on the iPod. There’s two ways to add songs to the list on the right panel; files can be read in and listed individually, or all files recursively under a starting directory can be pulled in at once. Now clicking on the Sync button will transfer all the chosen files over to the iPod. Then exit the gtkpod application, make sure nothing else is peeking at the iPod, and eject it, to see the songs.

Some thoughts and cautions

Some things to keep in mind. Updates and upgrades in this area have been quite rapid. This means it’s very easy to google up outdated information. Always check the date of the article, and establish which Linux and iPod versions are under discussion (that’s why I listed mine above).

The biggest stumbling block by far will be the lack of documentation. What I describe above (SoundJuicer+gtkpod) sounds simple, and it is, but I spent no few hours trying to make sense of these programs and searching online for tips and information. If I want to check out other programs, say GNUpod, I expect it to take a few days just to figure out how to use it and what its shortcomings are. I will likely not find extensive documentation and precious little for the questions and concerns I have. So that needs to be kept in mind.

If there’s a forum or mailing list for something, check it out! In gtkpod’s case, the documentation sucks, but the gtk-questions mailing list is fabulous: lots of responsive and helpful people there. And hopefully some efforts are underway to document gtkpod, because I think it’s a very nice little program.

For KDE users/purists, I believe that Amarok can handle all of these aspects, which I will also investigate and post about.

I haven’t even gotten to photos and movies yet! *Wipes brow*

del.icio.us:short and sweet (sort of): using an ipod with linux  digg:short and sweet (sort of): using an ipod with linux

Comments (1)

ipod odyssey

Update: The info on SoundJuicer’s gstreamer settings is incomplete and will result in low kb/s rates and bad tags. Please see the next post for better information.

Wow.

Just…wow. I got an iPod recently and today I set out to start populating it with music using Linux. Not Mac, not Windows, but Linux.

To look at the copy, it’s pretty straight forward. For example, see here and here, which all cheerily say that, with a little bit of fiddling, it’s a breeze to set up one’s iPod with Linux.

Read the rest of this entry »

del.icio.us:ipod odyssey  digg:ipod odyssey

Comments (1)

« Previous entries

Bad Behavior has blocked 953 access attempts in the last 7 days.