Wednesday, 9 February 2011

Upgrade from lenny to squeeze - first impressions

Update: I reported the deluge issues and added a new problem about the lack of click on tapping on the touchpad.

I know that installation reports and upgrade reports need to be submitted to the BTS, but I just want to point out some issues for people that might hit the same issue on upgrade from lenny to squeeze.

But before that I must say I like the new Debian site(s) look.

Issue number one: When upgrading from lenny's deluge to squeeze's deluge, the new version of the app is quite different from the prevoious version. Here are some things to take into account:
  • when starting for the first time the new version it will take ages to check (and probably recalculate some checksums); make sure you don't mind the I/O activity when you start it; a torrent will not be available until this check is done
  • the new version relies on a client-server model which is disabled if you use the "classic mode" (Edit->Preferences->Interface)
  • some features available in the old version are not available in the new version (e.g.: graph for traffic and embedded search function)
  • some features are availbale as modules, but there are just a few modules
  • when starting the graphical interface in the new mode, don't use the "Start daemon" button, use the "Connect" button. If you start the daemon via the "Start daemon" button the "Connect" button will become "Disconnect" although the client is NOT connected. Using the "Connect" button directly solves the problem.
  • There is an ugly side panel (on the left side) which, IMHO has no real function or use, except filtering in the view the active downloads or similar things
  • when choosing the place to save a torrent and trying to set that place as the default location, deluge will not remember that setting
  • closing now (with the daemon option) the app will close just the client, but the server/daemon will remain in the background, unless is explicitly closed (there is a dedicated menu entry)
Issue number 2: I seem to experience some weird glyph/graphic area reshuffling in GNOME (maybe X?) after recovering from hibernate. With a total (according to my current sloppy counting) 5 resumes, things get back to normal, but I suspect the next hibernate-resume cycle will restart the glyph reshuffling cycle.

By glyph/graphic area reshuffling I mean alterations of the shapes of the glyphs (and some areas on the background picture) in such a manner that it seems that within a set of 8/16/N (?) lines are shifted/rotated sideways with some undefined and different ammount each, but in a reproducible manner ("b" will always be doodled in the same way, no matter if is in the word "be" or if is in the word "absurd".

I'll try to provide some picture in the bug report, once I report this issue in BTS.

Update: I reported this in Debian's BTS and upstream (with screenshots, too). I am not convinced the problem is in the kernel since I tried an old kernel and saw the same issue. I suspect X is at fault.

Issue number 3: This is more like a convenience issue. In the past I was using "hibernate" with uswsusp which I understand is now broken beyond repair and replaced by pm-utils. The thing I miss in the hibernate process now is the ability to abort the hibernation process as it was possible in lenny's uswsusp by pressing the backspace key during the storing of the state on disk phase.

Issue number 4: The upgrade process was quite tedious because once I tried upgrading aptitude, python2.6 was pulled in and almost all apps ended up needing upgrading due to the chaining of necessary package upgrades.

Issue number 5: For some weird reason pulseaudio was initially installed making playback of any audio impossible (the apps wanting to emit noises would just freeze but they were TERM-inatable) and later I've seen a default null audio sink was defined for me. Killing pulseaudio and removing the ~/.pulse directory fixed the issue (but I should probably see why pulseaudio didn't work properly in the first place because I suspect the problem will reappear at the next restart - I usually use hibernate).

Issue number 6: Tapping the touchpad no longer results in a click. Maybe some packages got removed? And, no, it is the same when I remove the external mouse, so it is not because of some smart behaviour of that sort.

Otherwise I am quite satisfied with the result of the upgrade. A huge "thank you" to all people involved in the development of squeeze.


__DL__ said...

I do use pm-hibernate for some time, but in /etc/pm/config.d/89-local.conf I put SLEEP_MODULE=uswsusp, and I do have the "interrupt with backspace" feature.

info said...

uswsusp still works fine on my laptop.

Anonymous said...

Please report some bugs about these issues.

Philipp Kern said...

The clicking issue is an upstream decision, which should also be findable with a tad of googling. Sadly I don't know how it's fixed nowadays. It used to be in HAL, which is no longer queried, maybe Gnome offers some settings for it too...

Rodrigo Hausen said...

Issue no. 6: it's not a bug, it's a feature. The Debian wiki has more information on tapping. The instructions on the wiki enable tapping only for the gdm login screen. For user sessions, you must enable tapping using System -> Preferences -> Mouse -> Touchpad; this must be done on a per-user basis.

Anonymous said...

For the touchpad, if you simply go to System -> Preferences -> Mouse

Click on the Touchpad tab, there is a checkbox for enabling clicks off of the touchpad.

Not sure why it is turned off by default, but it is not like they took the ability away altogether.

Anonymous said...

For Issue no. 6 you can add to your xorg.conf something like
Option "TapButton1" "1"
Option "TapButton2" "2"
Option "TapButton3" "3"
in the synaptics input section. With this you have one finger, two finger and three finger tapping enabled - if supported by your device - and it's system wide.

Anonymous said...

"closing now (with the daemon option) the app will close just the client, but the server/daemon will remain in the background, unless is explicitly closed (there is a dedicated menu entry)"

So, I think this is absolute correct behaviour. The client disconnects from the srver. Why should the server shut down? If someone wants this, he can use the traditional interface.

ShadowAdler said...

Did you get any resolution to the glyph/graphical issue, and did you post screenshots anywhere? I think by the description that I am having similar problems with KDE4- but I've not seen any solutions anywhere...

eddyp said...

@ShadowAdler: I reported the issue in Debian.

Some suggested that the problem comes from the kernel, but I am not convinced since I tried the old kernel I used before the upgrade and the problem is still there.