Not sure that it requires any explanation (all you have to do is look at livejournal's front page).
Used google-blog-converters to grab all the posts and convert them to blogger.xml. Then used the import feature here on the settings tab. Worked great!
I then promptly deleted my livejournal account.
Thursday, July 7, 2011
Monday, April 11, 2011
konsole tabs with dbus in kde4.6
In the continuing automation saga with konsole at my job, KDE has come far enough with the dbus interface in 4.6 to allow me to bring up tabs again and perform actions in them with a script.
For this I created the following shell functions:
In scripts that I want automation, I include these functions:
I can then open a whole bunch of tabs at once and send them a command:
However I haven't gotten this to work from starting 'konsole -script' from a shortcut. Launching a script like this creates an infinite number of tabs launching the script in sequence. Very weird stuff.
For now, just start a konsole session and launch the script within the first tab. As you can deduce from the functions, it has to be the first tab you launch konsole with.
For this I created the following shell functions:
# konsole dbus functions
newtab()
{
dbus-send --session --dest=${KONSOLE_DBUS_SERVICE} --type=method_call --print-reply /konsole/MainWindow_1 org.kde.KMainWindow.activateAction string:"new-tab"
}
renametab()
{
sessionno=$1
tabname=$2
session="/Sessions/${sessionno}"
dbus-send --session --dest=${KONSOLE_DBUS_SERVICE} --type=method_call --print-reply ${session} org.kde.konsole.Session.setTabTitleFormat int32:0 string:"$tabname"
dbus-send --session --dest=${KONSOLE_DBUS_SERVICE} --type=method_call --print-reply ${session} org.kde.konsole.Session.setTabTitleFormat int32:1 string:"$tabname"
dbus-send --session --dest=${KONSOLE_DBUS_SERVICE} --type=method_call --print-reply ${session} org.kde.konsole.Session.setTitle int32:1 string:"$tabname"
}
sendtab()
{
sessionno=$1
cmd=$2
session="/Sessions/${sessionno}"
" dbus-send --session --dest=${KONSOLE_DBUS_SERVICE} --type=method_call --print-reply ${session} org.kde.konsole.Session.sendText string:"$cmd
}
closetab()
{
dbus-send --session --dest=${KONSOLE_DBUS_SERVICE} --type=method_call --print-reply ${KONSOLE_DBUS_SESSION} org.kde.konsole.Session.close
}
In scripts that I want automation, I include these functions:
# konsole functions
. ~/bin/kons-fn.sh
I can then open a whole bunch of tabs at once and send them a command:
PORTS=( 2022 2021 )
SESSIONS="
A_FU
B_BAR
"
command="telnet ${CONSOLE_SERVER}"
j=1
index=0
for i in ${SESSIONS}
do
newtab
let index=$j-1
let j=$j+1
renametab $j $i
sendtab $j "${command} ${PORTS[${index}]}"
done
closetab
exit 0
However I haven't gotten this to work from starting 'konsole -script' from a shortcut. Launching a script like this creates an infinite number of tabs launching the script in sequence. Very weird stuff.
For now, just start a konsole session and launch the script within the first tab. As you can deduce from the functions, it has to be the first tab you launch konsole with.
Thursday, December 3, 2009
tbird on FreeBSD
I recently moved to using thunderbird on freebsd and away from pine. I did this mainly because there are just too many oddly formatted html emails floating around work from people who are chained to lookout and don't know any better.
My pine config is still active and available but serves now only as a remote-in, or console bound backup mailer.
The first problem I encountered with t-bird is the helper apps. The list comes up blank from the installed freebsd port and there are no helper apps listed and no way to activate them. This was unlike pine where a url-viewer could be defined. With t-bird I discovered after much web digging if you have Freebsd/KDE/qt without gtk helper infrastructure, you'll need to define the url viewer for firefox. You do this under the advanced config editor, or in prefs.js:
For anything else, under pine/alpine you'd be editing your .mailcaprc, but under t-bird you'll need mimeTypes.rdf and Mime Edit. It was ridiculous how hard it was to find this functionality and for a long time I was hand editing the Mimetypes.rdf to add helper apps.
My pine config is still active and available but serves now only as a remote-in, or console bound backup mailer.
The first problem I encountered with t-bird is the helper apps. The list comes up blank from the installed freebsd port and there are no helper apps listed and no way to activate them. This was unlike pine where a url-viewer could be defined. With t-bird I discovered after much web digging if you have Freebsd/KDE/qt without gtk helper infrastructure, you'll need to define the url viewer for firefox. You do this under the advanced config editor, or in prefs.js:
user_pref("network.protocol-handler.app.ftp", "/usr/local/bin/firefox3");
user_pref("network.protocol-handler.app.http", "/usr/local/bin/firefox3");
user_pref("network.protocol-handler.app.https", "/usr/local/bin/firefox3");
For anything else, under pine/alpine you'd be editing your .mailcaprc, but under t-bird you'll need mimeTypes.rdf and Mime Edit. It was ridiculous how hard it was to find this functionality and for a long time I was hand editing the Mimetypes.rdf to add helper apps.
Friday, November 6, 2009
converting
In my ancient post on Scripting up some tabs with konsole in kde was for 3.5 era and dcop. I had a lot of scripts that would just blast open windows in a konsole session, automatically connecting to my various machines in the remote computer lab. Depending on what I was doing, I could just exec a sript from the desktop to connect and use a suite of machines in a tabbed konsole session.
With dbus, and the 4.x kde upgrade I lost all that. Recently I've started trying to convert the old stuff to dbus.
For example, setting tab titles:
It unfortuantely took me a long time to figure this out. One, since dbus-send spits out an incorrect error when the parameters are wrong. Instead of 'incorrect parameter,' you get 'no such method.' This makes sense from a OO standpoint since 'no such method' exists with 'those parameters''
dbus-send supports all sorts of types, and from introspection, I knew setTitle needed a int and a string. dbus-send supports all types of things int16, int32, etc..
Without looking at the source, you just kind of have to guess which types to send.
Now onto, auto new tabs, title naming, and finishing the conversion.
With dbus, and the 4.x kde upgrade I lost all that. Recently I've started trying to convert the old stuff to dbus.
For example, setting tab titles:
$ dbus-send --session --dest=$KONSOLE_DBUS_SERVICE --type=method_call --print-reply /Sessions/35 org.kde.konsole.Session.setTitle int32:1 string:"title"
method return sender=:1.88 -> dest=:1.187 reply_serial=2
It unfortuantely took me a long time to figure this out. One, since dbus-send spits out an incorrect error when the parameters are wrong. Instead of 'incorrect parameter,' you get 'no such method.' This makes sense from a OO standpoint since 'no such method' exists with 'those parameters''
$ dbus-send --session --dest=$KONSOLE_DBUS_SERVICE --type=method_call --print-reply /Sessions/35 org.kde.konsole.Session.setTitle
Error org.freedesktop.DBus.Error.UnknownMethod: No such method 'setTitle' in interface 'org.kde.konsole.Session' at object path '/Sessions/35' (signature '')
dbus-send supports all sorts of types, and from introspection, I knew setTitle needed a int and a string. dbus-send supports all types of things int16, int32, etc..
Without looking at the source, you just kind of have to guess which types to send.
$ qdbus $KONSOLE_DBUS_SERVICE /Sessions/35
method void org.kde.konsole.Session.close()
method QByteArray org.kde.konsole.Session.codec()
method QStringList org.kde.konsole.Session.environment()
method bool org.kde.konsole.Session.flowControlEnabled()
method int org.kde.konsole.Session.foregroundProcessId()
method bool org.kde.konsole.Session.isMonitorActivity()
method bool org.kde.konsole.Session.isMonitorSilence()
method int org.kde.konsole.Session.processId()
method void org.kde.konsole.Session.sendMouseEvent(int buttons, int column, int line, int eventType)
method void org.kde.konsole.Session.sendText(QString text)
method bool org.kde.konsole.Session.setCodec(QByteArray codec)
method void org.kde.konsole.Session.setEnvironment(QStringList environment)
method void org.kde.konsole.Session.setFlowControlEnabled(bool enabled)
method void org.kde.konsole.Session.setMonitorActivity(bool)
method void org.kde.konsole.Session.setMonitorSilence(bool)
method void org.kde.konsole.Session.setMonitorSilenceSeconds(int seconds)
method void org.kde.konsole.Session.setTitle(int role, QString title)
method QString org.kde.konsole.Session.title(int role)
method QDBusVariant org.freedesktop.DBus.Properties.Get(QString interface_name, QString property_name)
method QVariantMap org.freedesktop.DBus.Properties.GetAll(QString interface_name)
method void org.freedesktop.DBus.Properties.Set(QString interface_name, QString property_name, QDBusVariant value)
method QString org.freedesktop.DBus.Introspectable.Introspect()
Now onto, auto new tabs, title naming, and finishing the conversion.
Viewing /var/mail/username mail via thunderbird
Despite the really decrepit solutions you can find via Google, this is really easy.
1. create a "Movemail account"
2. exit thunderbird
3. cd ~/.thunderbird/{random}.default/Mail/localhost
4. ln -sf /var/mail/{username} Inbox
5. re-startup thunderbird
6. read mail.
1. create a "Movemail account"
2. exit thunderbird
3. cd ~/.thunderbird/{random}.default/Mail/localhost
4. ln -sf /var/mail/{username} Inbox
5. re-startup thunderbird
6. read mail.
Wednesday, September 10, 2008
Running TAHI's v6eval suite on linux systems
For many years I've been verifying our products stack at work with the TAHI organization's v6eval engine and conformance test suite. One of the good and bad things about it is that it ran on FreeBSD -- pretty much only on FreeBSD.
This is because in the beginning this organization also were also sponsoring the KAME stack that you could drop right into the FreeBSD kernel sources and come out with a highly compliant ipv6 stack. Well, like anything that was FreeBSD only, that made it difficult to run in a company that did Linux development.
It wasn't long before people tasked with ipv6 verification and strapped by Linux systems began attempting to port it. IBM first posted a patch to get the v6eval engine running, and they did a really good job. That was posted on some long lost IBM site, but I had a copy and saved it off to help people out with their Linux systems here. This patch worked for a long time, as long as you didn't upgrade your old 2.2 or 2.4 based Linux system.
That patch I have archived here: v6eval-2.2b6_linux.patch
Recently the v6eval code was updated so that it would, a. run on modern FreeBSD systems, and b. compile on modern C++ compilers. This change was good, because it actually made the code more portable in a way. A while back on the TAHI users email list a patch was posted for Fedora 8. This patch was based on the Debian port and makes changes for Fedora 8.
That patch I have archived here: v6eval_fedora8.diff
Here's the original message from the list (you can pull it from the TAHI user archives if you choose -- I removed the emails addresses/names).
The Fedora/Debian patch has some good bits but makes WAY too many unnecessary changes (reformatting code, rewriting Makefiles -- no big deal as it was someones rough personal copy posted to a list). When I ported to the automated test system here I did the following and was able to port it in just under a day:
That's it.
This is because in the beginning this organization also were also sponsoring the KAME stack that you could drop right into the FreeBSD kernel sources and come out with a highly compliant ipv6 stack. Well, like anything that was FreeBSD only, that made it difficult to run in a company that did Linux development.
It wasn't long before people tasked with ipv6 verification and strapped by Linux systems began attempting to port it. IBM first posted a patch to get the v6eval engine running, and they did a really good job. That was posted on some long lost IBM site, but I had a copy and saved it off to help people out with their Linux systems here. This patch worked for a long time, as long as you didn't upgrade your old 2.2 or 2.4 based Linux system.
That patch I have archived here: v6eval-2.2b6_linux.patch
Recently the v6eval code was updated so that it would, a. run on modern FreeBSD systems, and b. compile on modern C++ compilers. This change was good, because it actually made the code more portable in a way. A while back on the TAHI users email list a patch was posted for Fedora 8. This patch was based on the Debian port and makes changes for Fedora 8.
That patch I have archived here: v6eval_fedora8.diff
Here's the original message from the list (you can pull it from the TAHI user archives if you choose -- I removed the emails addresses/names).
Date: Thu, 3 Apr 2008 13:31:45 -0700
Subject: [users:00660] Re: Running Tahi on Linux
Here is the patch file for v6eval-3.0.12. Naturally the Tahi folk released a new version while I was building and verifying this patch file.
To use this, install the source from Tahi onto a Fedora 8 system and use the 'patch' command to apply this patch. You should then be able to use 'make' as before to
build the system and 'make install' to install it in /usr/local/v6eval. Note that there are probably some dependancies that I'm glossing over. If you have problems
building, let me know and I'll try to help you figure out what packages you need to install. The compiler does issue a lot of warnings about virtual functions that I
didn't chase down, but the system seems to still work for me.
While this patch is meant to be applied to the base source as available from Tahi, I won't claim to be the one who did all the necessary modifications. I started
with the tahi-linux package that according to the change log came from Kazuo Hiekata at IBM, then made changes to get it to compile on Fedora 8. My modification
mostly involved the Makefiles. Guess I should add my name to the change log as well. Maybe next time.
Let me know if there are any issues.
The Fedora/Debian patch has some good bits but makes WAY too many unnecessary changes (reformatting code, rewriting Makefiles -- no big deal as it was someones rough personal copy posted to a list). When I ported to the automated test system here I did the following and was able to port it in just under a day:
- extract the latest tarball
- grab 'pmake' package for my distribution and install (*BSD style make)
- grab 'byacc' package for my distribution and install (*BSD style yacc)
- apply minimalist 2.2b6 patch (read the instructions at the top of the patch file text)
- attempt to compile, and fix issues.
- pull very specific Linux OS related issues from Fedora/Debian patch over to extracted area.
That's it.
Monday, September 1, 2008
Patchiness of source control
I maintain several systems that I use day to day at my Job. One of these is a box I use for mostly code compilation that run Gentoo. The machine runs on a Tyan S2822-D, aka Thunder K8SD Pro.
When I decided to wipe this machine, which was running CentOS 3.x at the time, and drop Gentoo on it, I had been out of the Linux Kernel compilation game for quite a while. To make a long story short, I could not find the correct Kernel compile options (which have become inordinately numerous and bloated) in the 2.6 kernel to make this beast boot. The internet was very little use as to which ones I needed as well. After a couple days of free time spent trying to get the correct options, I gave up and used what did boot -- Gentoo's genkernel package.
Since I ply mostly with FreeBSD systems, having a 'GENERIC' kernel was very familiar to me, and I wrote it down as a 'good move overall' for the future. However, after many moons of regular 'emerge --sync' and 'emerge -vuD world' success stories, I came across a update that broke my genkernel compilation. I couldn't find any hints from internet groups or google searches. Last week I broke down and decided to fix the damn thing myself.
The error was fleeting to say the least and NOT logged in /var/log/genkernel.log. The compilation always died after the kernel compilation and during the busybox compilation. busybox in genkernel is 1.7.4 and gentoo's genkernel ships several patches to it. The compilation would die during this patch process. The error would appear only on the terminal and would not be logged:
patch: **** File shell/ash.c seems to be locked by somebody else under Perforce
There was a whole bunch of other failures that would make this scroll by, so unless you happened to troll the backbuffer you wouldn't catch this as the failure. To it's credit the gentoo genkernel process does mention the failure to patch as the key failure.
So I simulated the patch process, I ran 'tar -xjpf /usr/portage/distfiles/busybox-1.7.4.tar.bz2' in /var/tmp and ran 'patch -p1 < /usr/share/genkernel/patches/busybox/1.7.4/1.7.4-ash-timeout.diff' from the extracted directory. Sure enough, same error.
It turns out that since permissions are extracted by default with the tar command under the build process, patch has '-g' ON BY DEFAULT (from the manpage):
I was not amused. Anyway, I moved patch from /usr/bin/ to /usr/bin/patch.org and wrote this wrapper in /usr/bin/patch:
genkernel now compiles.
When I decided to wipe this machine, which was running CentOS 3.x at the time, and drop Gentoo on it, I had been out of the Linux Kernel compilation game for quite a while. To make a long story short, I could not find the correct Kernel compile options (which have become inordinately numerous and bloated) in the 2.6 kernel to make this beast boot. The internet was very little use as to which ones I needed as well. After a couple days of free time spent trying to get the correct options, I gave up and used what did boot -- Gentoo's genkernel package.
Since I ply mostly with FreeBSD systems, having a 'GENERIC' kernel was very familiar to me, and I wrote it down as a 'good move overall' for the future. However, after many moons of regular 'emerge --sync' and 'emerge -vuD world' success stories, I came across a update that broke my genkernel compilation. I couldn't find any hints from internet groups or google searches. Last week I broke down and decided to fix the damn thing myself.
The error was fleeting to say the least and NOT logged in /var/log/genkernel.log. The compilation always died after the kernel compilation and during the busybox compilation. busybox in genkernel is 1.7.4 and gentoo's genkernel ships several patches to it. The compilation would die during this patch process. The error would appear only on the terminal and would not be logged:
patch: **** File shell/ash.c seems to be locked by somebody else under Perforce
There was a whole bunch of other failures that would make this scroll by, so unless you happened to troll the backbuffer you wouldn't catch this as the failure. To it's credit the gentoo genkernel process does mention the failure to patch as the key failure.
So I simulated the patch process, I ran 'tar -xjpf /usr/portage/distfiles/busybox-1.7.4.tar.bz2' in /var/tmp and ran 'patch -p1 < /usr/share/genkernel/patches/busybox/1.7.4/1.7.4-ash-timeout.diff' from the extracted directory. Sure enough, same error.
It turns out that since permissions are extracted by default with the tar command under the build process, patch has '-g' ON BY DEFAULT (from the manpage):
-g num or --get=num
This option controls patch's actions when a file is under RCS or SCCS control, and does not exist or is read-only and matches the default ver-
sion, or when a file is under ClearCase or Perforce control and does not exist. If num is positive, patch gets (or checks out) the file from
the revision control system; if zero, patch ignores RCS, ClearCase, Perforce, and SCCS and does not get the file; and if negative, patch asks
the user whether to get the file. The default value of this option is given by the value of the PATCH_GET environment variable if it is set;
if not, the default value is zero if patch is conforming to POSIX, negative otherwise.
I was not amused. Anyway, I moved patch from /usr/bin/ to /usr/bin/patch.org and wrote this wrapper in /usr/bin/patch:
#!/bin/bash
/usr/bin/patch.org -g0 $@
exit $?
genkernel now compiles.
Subscribe to:
Posts (Atom)