cas

 

from the whinge of the day dept:

I started a bzr branch of calibre about 2.5 hours ago because I wanted to see how difficult it would be to understand the code and make a few changes. The calibre Get Involved page warns that it can take about an hour….which is excessive to begin with and, worse, a huge understatement.

$ date ; ps u -Cbzr
Sat Apr 14 15:10:00 EST 2012
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cas      14279  3.0  1.3 286836 215976 pts/3   S+   12:39   4:36 /usr/bin/python /usr/bin/bzr branch lp:calibre

It's still far from finished.

cas@ganesh:/usr/local/src/calibre$ bzr branch lp:calibre
You have not informed bzr of your Launchpad ID, and you must do this to
write to Launchpad or access private data.  See "bzr help launchpad-login".
1395260kB    65kB/s - Fetching revisions:Inserting stream:Estimate 178815/203940

a git clone of a much larger project would have been finished in mere minutes. WTF is bzr so horrendously slow?

It's not my connection, I'm on an otherwise idle ADSL2 connection, that syncs about 14Mbps.  i.e. capable of downloads of up 1.4 megabytes per second, not the 50-70kB/s that bzr is dawdling along at.  It's not my CPU, an AMD 1090T hex-core overclocked to 3.7GHz (and almost completely idle)…and since I have 16GB RAM, it's not lack of RAM either.

Is there anything good about bzr that makes people actually want to use it?  or is it just the association with ununtu and launchpad?

maybe the purpose is to actively discourage casual involvement….you have to make a massive life commitment and run the gauntlet of tediously long waits before you can even look at the code.

No wonder github is so popular.

 

 

how embarassing, i make a point of asking for comments and critique on my previous post but comments didn't actually work unless you're logged in.  I only noticed because someone emailed me.

It was the admin-ssl plugin.  de-activated now, so comments are working again.

A few people tried to add comments according to the log – if you feel like making them again, go right ahead.

thanks

Craig

 

 

I’m finally getting around to making myself learn python as more than just a read-only language. Working with Openstack kind of requires it.

So far, I like it. Much more than I thought I would as an unrepentant sh and perl using systems geek. And getting over my distaste for the white-space issue is also proving to be much easier than I thought it would (although I still think that block-delimiters like {} make the code easier to read…PyHeresy, I know)

While hacking the /usr/bin/glance command to have less ugly output, and adding a –csv option to list the image index in a usefully parseable format, I needed to figure out how to get the terminal size (height,width).

This, cobbled together from various google search results, seems to work. It’s probably not strictly-correct python idiom, and there’s probably a better way of doing it. Comments and critique are welcome.

def get_terminal_size(fd=1):
    """
    Returns height and width of current terminal. First tries to get
    size via termios.TIOCGWINSZ, then from environment. Defaults to 25
    lines x 80 columns if both methods fail.
 
    :param fd: file descriptor (default: 1=stdout)
    """
    try:
        import fcntl, termios, struct
        hw = struct.unpack('hh', fcntl.ioctl(fd, termios.TIOCGWINSZ, '1234'))
    except:
        try:
            hw = (os.environ['LINES'], os.environ['COLUMNS'])
        except:  
            hw = (25, 80)
 
    return hw
 
def get_terminal_height(fd=1):
    """
    Returns height of terminal if it is a tty, 999 otherwise
 
    :param fd: file descriptor (default: 1=stdout)
    """
    if os.isatty(fd):
        height = get_terminal_size(fd)[0]
    else:
        height = 999
 
    return height
 
def get_terminal_width(fd=1):
    """
    Returns width of terminal if it is a tty, 999 otherwise
 
    :param fd: file descriptor (default: 1=stdout)
    """
    if os.isatty(fd):
        width = get_terminal_size(fd)[1]
    else:
        width = 999
 
    return width
 

zfsonlinux recently added support for visible .zfs snapshot directories, so you no longer have to mount a snapshot to browse/view/recover files from it.

This is good, but has caused my rsync backup to zfs script to complain about being unable to delete files in the .zfs directory (which is in the backup but not in the source).

e.g.

sending incremental file list
rsync: delete_file: unlink(.zfs/snapshot/2012-03-31/vmlinuz.old) failed: Read-only file system (30)
rsync: delete_file: unlink(.zfs/snapshot/2012-03-31/vmlinuz) failed: Read-only file system (30)
[...]
cannot delete non-empty directory: .zfs/snapshot/2012-03-31
rsync: delete_file: rmdir(.zfs/snapshot/2012-03-31) failed: Device or resource busy (16)
rsync: delete_file: unlink(.zfs/snapshot/2012-03-30/vmlinuz.old) failed: Read-only file system (30)
rsync: delete_file: unlink(.zfs/snapshot/2012-03-30/vmlinuz) failed: Read-only file system (30)
[...]

The solution is to tell rsync to ignore .zfs directories on the destination.

1. use the -F option to make rsync use /.rsync-filter
2. create or add the following line to /.rsync-filter

-r .zfs/***
-s .zfs/***

On the first line, the ‘-’ makes it an exclude rule, and the ‘r’ indicates that the rule applies to the receiving side. Together, ‘-r’ prevents rsync from attempting to delete the .zfs directories

On the second line, the ‘-s’ indicates that the rule applies to the sending side, preventing rsync from trying to backup any .zfs snapshot directories. This is only useful when backing up a ZFS filesystem.

 

Does anyone use fstrim on an XFS formatted SSD partition?

I’ve got two systems with XFS root partitions that fstrim seems to do (almost) nothing on, but it seems to work correctly on another system with formatted with ext4.
Continue reading »

 

This has been a minor annoyance for the last few months, and I've finally figured out how to fix it:

Sometime within the last few months, an upgrade prevented Chromium from finding its application icon…with the result that when minimised (or displayed in the panel window list or Alt-Tab) it used the default application icon.

It looks to me as if the problem is that Chromium is now looking for chromium-browser.svg but chromium.svg is what's on my debian system.

To restore, all you need to do is:

$ mkdir -p ~/.local/share/icons/hicolor/scalable/apps
$ cd ~/.local/share/icons/hicolor/scalable/apps
$ ln -s /usr/share/icons/hicolor/scalable/apps/chromium.svg chromium-browser.svg

great, done. Now my chromium windows don't look the same as my mrxvt windows in Alt-Tab, they're quite clearly Chromium windows. The icon now looks like this: rather than an icon i'd insert here if i knew what its filename is – it looks like a white window with a blue title bar and a thinner blue bar at the bottom (about half the height/thickness of the "title bar") I've spent half an hour searching for it and have given up – anyone know what it is?

alternatively, use cp rather than ln – just in case some future upgrade removes or renames the chromium.svg file

 

I got home from work tonight and zfs had reported that one of the disks in my main pool was dying.

no great problem. insert a disk i had spare, and run zpool replace like so:

ganesh:~# zpool replace -f export  scsi-SATA_WDC_WD10EARS-00_WD-WMAV50933036 scsi-SATA_ST31000528AS_9VP16X03

and now it’s just a matter of waiting until the data has “resilvered” and i can remove the old dying drive.

ganesh:~# zpool status export -v
  pool: export
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scan: resilver in progress since Mon Nov 28 19:25:49 2011
    75.1G scanned out of 2.29T at 88.3M/s, 7h17m to go
    18.0G resilvered, 3.21% done
config:

        NAME                                                   STATE     READ WRITE CKSUM
        export                                                 ONLINE       0     0     0
          raidz1-0                                             ONLINE       0     0     0
            scsi-SATA_WDC_WD10EACS-00_WD-WCASJ2114122          ONLINE       0     0     0
            scsi-SATA_WDC_WD10EACS-00_WD-WCASJ2195141          ONLINE       0     0     0
            scsi-SATA_WDC_WD10EARS-00_WD-WMAV50817803          ONLINE       0     0     0
            replacing-3                                        ONLINE       0     0     0
              scsi-SATA_WDC_WD10EARS-00_WD-WMAV50933036        ONLINE       0     0     0
              scsi-SATA_ST31000528AS_9VP16X03                  ONLINE       0     0     0  (resilvering)
        logs
          scsi-SATA_Patriot_Torqx_278BF0715010800025492-part6  ONLINE       0     0     0
        cache
          scsi-SATA_Patriot_Torqx_278BF0715010800025492-part7  ONLINE       0     0     0

errors: No known data errors

(I use /dev/disk/by-id device names so I don’t have to care about the kernel detecting the disks and disk controllers in a different order on each reboot…also makes it easier to identify which disk is having a problem as I can squint at the front of the drives in my Lian Li 4-in-3 hotswap bays and read the serial number sticker)

OK, yeah, sure…it’s not that much different from replacing a dying drive in an mdadm or hardware raid array but one nice advantage of zfs over raid is that it only resyncs the data in use, not the empty or unused blocks. given that these are 1TB drives in a raidz vdev, and the pool is 63% used that means syncing only about 630GB rather than 1TB.

ps: in the time it’s taken to write this, it’s up to 10.11% done. 88MB/s reading data from the existing raidz drives and writing to a single drive isn’t too bad at all.

 

Dear lazyweb,

I bought an Aten CS1784A DVI+USB KVM switch a couple of months ago. I’m pretty happy with it except for one annoying problem.

It has a Dell multimedia USB keyboard plugged into it (picked it up from a swap meet for $15 – nice. it's a pretty good keyboard in its own right but i mostly bought it to match what I use at work), and a Logitech MX518 mouse connected. Also two computers – one runs Linux only. The other is switched off most of the time, but is occasionally powered up to boot into either Linux to experiment with stuff i don't want to do on my main system (like gnome 3) or sometimes Win7 to play games.

OK, that’s the background data. Here’s the problem

Whenever I reboot either of the Linux installations, the KVM stops recognising the keyboard. I have to unplug the keyboard and plug it back in before any input is recognised. Keyboard input doesn't get through to the currently active system, and I can't even use the KVM's magic key <ScrlLock><ScrlLock>n<Enter> to switch between systems – it doesn't even beep after the 2nd ScrlLock as it should, so it seems as if all keyboard input is ignored by the KVM, or the keyboard is totally confused and not sending anything. The mouse continues to work during this.

Rebooting Win7 doesn't do this. The keyboard just works as it should.

The problem occurs sometime between the time Linux is selected from the Grub2 menu and the gdm login screen is displayed (same result with both gdm on my main system and gdm3 on my secondary system).

The keyboard works when plugged directly into either system, without the KVM. I’d been using it for several months before I got the KVM, and I’ve tested that it still works correctly across a reboot if i plug it in directly.

 

Googling for "+linux +CS1784A" just gives me hundreds of pages from web sites selling the KVM, but no useful info.

Anyone seen anything like this before? Can anyone think of anything that linux might be doing in it's console or X initialisation that would confuse the KVM?

it's not a huge problem because I really don't reboot all that often – more of an annoyance that I'd like to go away.

 
  1. Non-resizable configuration windows.  I have a 1920×1200 screen but the window manager provides no way to resize windows like the System Settings window.  Result is that the window is quite small and, worse, has a scroll bar for no good reason when another hundred or so vertical pixels would easily display everything. Even another 30 or so horizontal pixels would allow more icons per line under Hardware, reducing the number of lines, and again allowing the entire list of available settings to be displayed without a scroll bar. Instead, to see all of the options I have to scroll down.  And these people call themselves user-interface and usability experts.

    It's not up to the gnome developers to decide that I never need to resize certain windows or certain kinds of windows. It's up to me to decide that. They're not at my desktop, using my screen. I am.

  2. No way to disable a shell extenstion from the command line.  I installed the gnome-shell-extensions package and was trying out various extensions to see if they made gnome shell tolerable.  Enabling one of them (i forget exactly which one), immediately displayed some "Oh no! Something has gone wrong. A problem has occured and the system can't recover. Please log out and try again." leaving me no option but to log out.

    An absolutely fucking useless error message. "Something" has gone wrong. A little fucking detail might help me to diagnose the problem and fix it. Like a trace of whatever the fuck it was doing when "Something went wrong".

    When i logged back in, it crashed again, with the same useless error screen.  So, now I can't even log in to Gnome Shell.  I've tried logging in to Fallback mode, but the Extensions tab is empty in gnome-tweak-tool (because, of course, nobody would want to configure Shell Extensions from fallback mode, would they?).

    I can't even find any way of listing which shell extensions are enabled, let alone disable one of them.  Hell, I'd settle for disabling all of them, and then carefully re-enabling them one-by-one until I rediscovered the culprit.

  3. Oh, wait. I finally found /org/gnome/shell/enabled-extensions in dconf-editor. it's a text field with an array of items. so far, so good. The "editor" (and i use that term very loosely) for text fields is garbage. It can't even wrap lines so that it displays the whole field without a horizontal scroll bar – probably my all-time least favourite user-interface element. Have gnome devs never heard of multi-line text-edit fields?

    Rather than fuck around with a crappy GUI editor, it's far easier to:

    $ dconf read /org/gnome/shell/enabled-extensions > /tmp/extensions
    $ vi /tmp/extensions
    $ dconf write /org/gnome/shell/enabled-extensions "$(cat /tmp/extensions)"
    

    I guess now it's time to log out from fallback mode to find out if I can log back in to Gnome Shell again. [ nope. didn't work ]

  4. Add non-resizable user-interface elements to item 1. above. So far, Gnome devs are doing a great job of regressing to the crap usability of the Windows GUI

    here’s a useful rule of thumb for things like that: Every single window, every single user-interface element should be resizable and tweakable by the user. And the system should remember all user changes so that they don’t have to waste a few minutes every time they run an app resizing things to suit their requirements.

    Gnome 2 mostly had that. Gnome 3 seems to have lost a large part of it along the way

    Second rule of thumb: If the user happens to replace their monitor or run it in a mode too small for the current settings, then they should revert to some sane default.

    Even better, it should remember the settings for each resolution – choosing either sane defaults or the user’s settings for the nearest similar resolution if the user hasn’t created custom settings for that resolution yet.

  5. Lack of documentation.  here's a good example:

    $ gnome-shell-extension-tool help
    Usage: gnome-shell-extension-tool [options]
    
    $ man gnome-shell-extension-tool
    No manual entry for gnome-shell-extension-tool
    See 'man 7 undocumented' for help when manual pages are not available.

    What more needs to be said?

    At least /usr/bin/dconf has built-in help. Which is great, since it doesn't have a man page either.

Update: About three hours of stuffing around later, and I’ve finally got Gnome Shell running again. I have NFI what actually fixed it, it could have any one of the dozens of settings I fucked around with. Nor do i have any idea what the actual problem was.

And after all that, the extensions I tried still don’t make Gnome Shell tolerable. They make it less *intolerable* (bottom-panel extension in particular), but that’s still a long way from being tolerable

i’m really trying hard to find some way to come to terms with Gnome 3. I’ve been trying for months now. But every time I give it another trial, I just end up hating it even more

I’m glad I have more than one desktop machine to use, so i can experiment with odious shit like Gnome Shell without fucking up my main working environment. So it’s back to my main desktop machine and gnome2. Eventually I’ll have to upgrade that, but xfce4 is looking to be my best option. I already switched to xfce4 on my desktop machine at work last week, and it’s pretty good…certainly far better than the Gnome 3 fallback mode i’ve been using there for the last 5 or 6 months.

Thanks, Gnome devs – you’re making a fantastic advertisement for XFCE. I wouldn’t have bothered trying it again if I hadn’t been forced to.

ps: before anyone says “wait for Gnome 3.2, it’s much better”. Todays waste of time *was* using Gnome 3.2

 

I've been unable to solve this problem for a few weeks now, so i'll try posting it to my blog – maybe someone out there knows the answer.  Would very much appreciate a clue on this one.

I've got a VM on a citrix xenserver 5.0.0 machine that won't start. it was running fine until it was rebooted on a Fri afternoon, a few weeks ago.

Starting it from the (windows-only) xencenter GUI results in:

   "This VM cannot be started, as its network interfaces could not be
   connected. One of the NICs is in use elsewhere."

Starting it from the command line results in:

# xe vm-start uuid=88915b63-d794-e021-4f78-b03f46e352b0
Cannot plug VIF
VIF: 5dfd3886-8b48-20e5-4231-30284d7b185d

anyone seen this before?  know how to fix?

Continue reading »

© 2012 Errata Suffusion theme by Sayontan Sinha