(TL note: nareshov's diary)

Posts Tagged ‘Ubuntu

On Karmic Beta

leave a comment »

On Friday last week I happened to upgrade certain packages on my erstwhile Jaunty installation on my laptop. For some strange reason my touchpad ceased to work. I couldn’t move the mouse pointer. I couldn’t even get onto good ole’ Google because I couldn’t click on NetworkManager and select the radio button next to my CDMA USB modem entry!

The next day I issued a ‘do-release-upgrade’ and headed out to watch Tarantino’s “Inglorious Basterds” with Debayan and Vignesh. After I returned there was still an hour to go and so I continued to bootstrap my Debian-armel on the SD card for the Beagle board. And when it was all over, I had Karmic!

So, the touchpad worked now. Somewhat. I couldn’t tap on the touchpad to click on things like the menubar entries and so on. Turns out that Systems > Preferences > Mouse > Touchpad has a button which says “Enable mouse clicks with touchpad” disabled by default. I, on the other hand, could make my way through up to this point with the keyboard alone and enabled it. Phew.

The improvements from Jaunty are, as expected, quite a lot. And visibly so.

Take the shiny new 2.6.31 kernel, for example. It boots fast. And supports kernel mode setting for the revamped X. The improvements are so obvious that you can’t afford to not say “wow”. I haven’t done the “full-screen flash video” test yet, but I do like the snappiness when I switch between virtual consoles and X. Once again, I can live with the minimal compiz that’s turned on by default on an Ubuntu installation. Oh, and I did have another oh-that’s-new moment with the volume control. It doesn’t look like the old one but it does look like an incomplete version of the Windows 7-style volume manager. I couldn’t find a way to mute my laptop speakers and let all sound be audible only via my earphones. Thankfully, alsamixer works.

UPDATE: It turns out that selecting “Analog Headphones” under Sound Preferences > Output does the trick.

So far so good. Upgrading moar. Oh, and don’t forget ‘do-release-upgrade -d’ in a screen session. Also, E17 looks kickass.

Written by Naresh

October 8, 2009 at 7:56 pm

The right-way(tm) to convert an ubuntu-desktop to a kubuntu-desktop?

leave a comment »

Playing with distros at every whim is all I’ve been doing for quite some time now. I’ve been changing DEs too (GNOME -> KDE4 — failing which — -> KDE 3.5.8 :P).
Although my current laptop compile OO.o in about 4 hours compared to my previous AMD desktop which took about 7 hours, I still fear having to enable/disable numerous USE flags to get a decent KDE. Not to mention those feelings of regret of having chosen the monolithic ebuilds over the split ones or vice versa ~_~

Well, let’s get to the topic here: “Converting an ubuntu installation to kubuntu”

1. If you’ve just installed Ubuntu do not upgrade even if there are updates available.
2. Press Ctrl+Alt+F1 – get outside of X.
3. Run invoke-rc.d gdm stop
4 Run sudo tasksel and uncheck Ubuntu-desktop
5 Run sudo aptitude update && sudo aptitude dist-upgrade now
6 And finally, sudo aptitude install kubuntu-desktop

That should do the trick, which unfortunately didn’t work completely with me.
Possible reasons could be that I was doing this 2 months after the Ubuntu 7.10 release and network-manager-kde errored out on reconfiguring which depended on reconfiguring dhcdbd. Some weird thing. Just run step 6. again and again 😐

Written by Naresh

December 13, 2007 at 2:04 pm

Posted in Linux/BSD, Software

Tagged with , ,

Another Gentoo loyalist turns to Ubuntu in the campus

leave a comment »

This is the second person. Earlier it was Mandu. Who said that it was fun but it took too much it and that he doesn’t want to spend too much of the precious resource – time.
Yesterday, ManuBansal posts on iitk.questions.unix:

Manu Bansal wrote:
> Another Gentoo loyal turned away.
> All I wanted to do was to upgrade to Valknut-3.8 from 3.7. dclib won't
> compile, and I wouldn't know why. Nobody would know why. Then suddenly,
> working on a project one day, it would occur to me that probably new code
> wouldn't compile with my relatively old gcc. And I would decide to upgrade
> gcc. I wouldn't know why the system is not using the newer gcc, and then,
> not being that noob, I would unmerge the old gcc, in the hope that the new
> gcc would come in effect. It still wouldn't, so I would update environment
> etc, but that wouldn't help either. And then I would take the plunge,
> without knowing that I was about to, and reboot. And nothing would work
> anymore! All applications would bail out for missing glibc. So I would
> realize I've lost glibc, and apps were compiled against the old one. So I
> would again try to emerge the old one, and even python would complain for
> the lib! Wow! That IS stranded. Then, and only then, would I get to know
> that there's a full Gentoo gcc upgrade guide.
> That I was able to put back my system did have a good effect - it raised
> my confidence in my hack-debug-skills. But then what would I do?
> An "emerge -eav system" and then "emerge -eav world". And then I will
> realize ebuilds for half of my packages don't exist anymore!
> I'm still not saying Gentoo package management is bad. But is it useful at
> all? A system which CAN benefit from compile optimization benefits would
> die compiling packages before they can be used. A system that can compile
> fast doesn't need those optimizations. And even the never-beatable
> dependency management goes for a ride when you upgrade 200 packages (half
> of them being kde) at a go. And gcc upgrade remains dirty - all it has is
> some suite of grep-based scripts, in addition to usual emerge.
> If one has still to upgrade all 100-200 packages, wouldn't bins/rpms be
> better?
> "Murphy's Law of Gentoo installation: If a compile can fail, it will."
> -- source:
> What is it called? Ubuntu? Or Fedora? ...
> Manu.

And you know what? I forgot to mention the funniest idea they have in
emerge - once in a while, a package emerge would beep for 10 seconds,
trying to draw your attention to a super-important message about a followup
action to the installation, maybe even something like "follow the gcc
upgrade guide". And that will happen in a compile of 4 hours on a P4 with
abundant RAM, after which the compile will spit enough to drive out the
message from display cache. Do they expect us to sit and stare at the
compile all this while?

All this leaves me wondering. Was he so out of touch after all? Looking at the need to upgrade his gcc for the valknut upgrade, it hints that he hadn’t updated his system in a long-time. And that too, long enough not to realize that there’s a proper way to upgrade his gcc. He unmerged his gcc! At least, he could’ve unmerged it with the = and version number…

emerge -Cav =sys-devel/gcc-3.4.6-r4

(assuming that 3.4.6-r4 was the old version he was trying to get rid of). It still is a mystery why he had to do that when he could’ve googled to figure out that there’s a handy tool called gcc-config.
About the info warn qa messages – he should’ve made use of the ELOG system the recent versions of portage come with.
Here’s a snip of the /etc/make.conf.example

# logging related variables:
# PORTAGE_ELOG_CLASSES: selects messages to be logged, possible values are:
# info, warn, error, log, qa
# Warning: commenting this will disable elog
PORTAGE_ELOG_CLASSES="warn error log"

# PORTAGE_ELOG_SYSTEM: selects the module(s) to process the log messages. Modules
# included in portage are (empty means logging is disabled):
# save (saves one log per package in $PORT_LOGDIR/elog,
# /var/log/portage/elog if $PORT_LOGDIR is unset)
# custom (passes all messages to $PORTAGE_ELOG_COMMAND)
# syslog (sends all messages to syslog)
# mail (send all messages to the mailserver defined
# save_summary (like "save" but merges all messages
# in $PORT_LOGDIR/elog/summary.log,
# /var/log/portage/elog/summary.log if
# $PORT_LOGDIR is unset)
# mail_summary (like "mail" but sends all messages in
# a single mail when emerge exits)
# To use elog you should enable at least one module

# PORTAGE_ELOG_COMMAND: only used with the "custom" logging module. Specifies a command
# to process log messages. Two variables are expanded:
# ${PACKAGE} - expands to the cpv entry of the processed
# package (see $PVR in ebuild(5))
# ${LOGFILE} - absolute path to the logfile
# Both variables have to be quoted with single quotes
#PORTAGE_ELOG_COMMAND="/path/to/logprocessor -p '\${PACKAGE}' -f '\${LOGFILE}'"

# PORTAGE_ELOG_MAILURI: this variable holds all important settings for the mail
# module. In most cases listing the recipient address and
# the receiving mailserver should be sufficient, but you can
# also use advanced settings like authentication or TLS. The
# full syntax is:
# address [[user:passwd@]mailserver[:port]]
# where
# address: recipient address
# user: username for smtp auth (defaults to none)
# passwd: password for smtp auth (defaults to none)
# mailserver: smtp server that should be used to deliver the mail (defaults to localhost)
# alternatively this can also be a the path to a sendmail binary if you don't want to use smtp
# port: port to use on the given smtp server (defaults to 25, values > 100000 indicate that starttls should be used on (port-100000))
# Examples:
#PORTAGE_ELOG_MAILURI="root@localhost localhost" (this is also the default setting)
#PORTAGE_ELOG_MAILURI="user@some.domain mail.some.domain" (sends mails to user@some.domain using the mailserver mail.some.domain)
#PORTAGE_ELOG_MAILURI="user@some.domain user:secret@mail.some.domain:100465" (this is left uncommented as a reader exercise ;)

# PORTAGE_ELOG_MAILFROM: you can set the from-address of logmails with this variable,
# if unset mails are sent by "portage" (this default may fail
# in some environments).

# PORTAGE_ELOG_MAILSUBJECT: template string to be used as subject for logmails. The following
# variables are expanded:
# ${PACKAGE} - see description of PORTAGE_ELOG_COMMAND
# ${HOST} - FQDN of the host portage is running on
#PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"

It was all there. Gentoo might not be just about optimizations. There’s unlimited scope for flexibility here. A little reading up saves a hell lot of headache later. And, why do you have to read so much? Because, probably, it was your choice to use Gentoo in the first place – and Gentoo doesn’t come to you as a desktop-distribution but as a meta-distribution. Do the initial setup well and live happily ever after.

Written by Naresh

March 28, 2007 at 1:18 am

Posted in College Life, Newsgroups, Software

Tagged with , ,