Search Results: "tar"

Someone asked on the PyGTK mailinglist if it is possible to reuse certain parts of a libglade window several times within an application.
It certainly is, and it's not even hard to do!

I've quickly written a demo application to show how it's done.

Glade widget tree

The user interface designed in glade is really simple, a textbox with two toggle buttons underneath. Activating one button will display a second, disparate textbox beside the original one. Deactivating it will remove that second textarea.
The other button will display and remove a copy of the first textbox which was there from application startup.
The full widget tree of this interface is shown in the first screenshot.

The actual code to the demo application is rather brief.
Continue reading "PyGTK/glade object reuse"

First, a question: dear lazyweb, how do I completely disable non-SSL access with lighttpd? I can't seem to find how to have a lighttpd SSL-only configuration. (and only binding port 80 on localhost does not count for an answer)

On to the subject. While it's easy to add SSL to lighttpd and enable PHP (through fastcgi) and Debian makes it even easier with it's lighty-enable-mod tool if you only do it once in a blue moon then it's not exactly resident knowledge. So here are the steps to do it, on Debian Etch:

apt-get the lighttpd, php4-cgi or php5-cgi, and openssl packages
lighty-enable-mod fastcgi
if using php5, update the path to the cgi binary in /etc/lighttpd/conf-available/10-fastcgi.conf (it's preconfigured for php4)
lighty-enable-mod ssl
update the path to the SSL certificate in /etc/lighttpd/conf-available/10-ssl.conf
restart the lighttpd server

That's all there is to it. Well, strictly speaking there's a step 4a: install a certificate; but that's arguably not a part of the configuration process.
(for reference: openssl req -new -x509 -keyout /etc/lighttpd/selfcert.pem -out /etc/lighttpd/selfcert.pem -days 365 -nodes will generate a self-signed certificate)

apt-get the lighttpd, php4-cgi or php5-cgi, and openssl packages
lighty-enable-mod fastcgi
if using php5, update the path to the cgi binary in /etc/lighttpd/conf-available/10-fastcgi.conf (it's preconfigured for php4)
lighty-enable-mod ssl
update the path to the SSL certificate in /etc/lighttpd/conf-available/10-ssl.conf
restart the lighttpd server

Last week I did again some work on nagios-plugins. After the announcement of Dann Frazier to upload NMU to fix a trivial bug, I thought it’s time again to give some extra care to the package. So I prepared 1.4.11-2 fixing the important bugs and uploaded it. I also commited some minor fixes to the svn, so these issues will get fixed by the next upload. Since the development of policyd-weigh stalled and unfortunately maybe get stuck, I was looking for an alternative, which maybe found with postfwd. It’s quite flexible but it also will take more time (and care!) to get a reliable configuration, which maybe effective as policyd-weight (still) is right now. While checking the dependencies for postfwd I noticed that Net::DNS::Async isn’t available in Debian (yet). So I decided to create a package starting with dh-make-perl, join the Debian Perl Group and let it review. Damyan Ivanov was so kind to review and upload it, Gregor Herrmann did also give some much useful hints. Thanks to both! And yes, I also found time to step forward with NM, since I was overloaded the last weeks with usual work and life. Thank to my AM to be so appreciative.

There are plenty of reasons why a company might provide a web form as the only means for customers to get in touch with their customer support department: for instance, the web form compels the customer to send along important information with the first request, therefore saving time (and money) for the customer service department. Even though I hate web forms, I sometimes do fill them in and usually get an answer back; it works. Every once in a while, however, I ll encounter a form designed by people without any form of understanding of the role of a customer for any business (it s the most important asset ). Such is the case when the form limits the message to a certain number of characters. Obviously, no customer service agent wants to read novel-length prose when fielding incoming requests, but a few hundred characters may also not be enough to get the point across. Star Alliance, for instance, expects you to get your point across in 300 characters. I find it hard to imagine that people write lengthy texts into web forms, unless they have more information to get across. I also see no technical reason for limiting the length of the text which can be submitted. The only logical explanation I have is that those companies give a flying food about customers and would much rather not have them contact the support department. NP: The Flower Kings: Back in the World of Adventures

In case you didn’t know, I’ve decided to resign as atheme project lead. This is for a few reasons:

Firstly, I have felt overall ineffective in this role since late 2007. This is probably due to the fact that disagreements between me and several other people have resulted in people leaving the organization to work on other projects, and the fact that atheme has not grown in any significant way since last year’s Summer of Code event.
Secondly, I am busy with a lot of other things and do not have time to give the proper attention this role needs. This role is basically defining the direction that atheme grows in, and capitalizing our strengths to expand the project and promote it. I see the lack of growth and proper promotion as a personal failure.
Thirdly, at the moment I am under a lot of stress due to dealing with various issues at the moment, which is leaving me irritable and generally quick to anger. This is not a quality we want in our project leadership. In short: I’m fucking up, and it needs to stop. So right now, I am resigning as project lead. If people want me back when I am under less pressure in general, then that’s great.
Fourthly, we need to see new leadership in atheme anyway, to keep things interesting. Without a regular change in leadership, people will start to see us as someone’s personal project, and that’s not the case with atheme.

However, just because I’m resigning as project lead doesn’t mean that I will stop working on projects I care about inside atheme, like audacious, mowgli, and mcs. These projects are critical components of the modern FOSS desktop, and I intend to continue working on them. This is purely an administrative change, so that any mistakes or stupidity I do have no effect on atheme.org’s overall health. I hope to see many other Atheme members step up and try to become project lead. Under the right leadership, atheme’s projects could become a much more notable platform in FOSS development within a short amount of time. Update: Due to popular demand, I have changed my mind. I’m no longer resigning as project lead of atheme.

This October, our church celebrates its hundredth anniversary. All this year, every so often, we are having brief "historical moments" during church.

Today, our temporary choir director -- and my high school band teacher -- was a Vorsanger. He got up during church and discussed how hymn singing was done in the early days of the church. Today, our Mennonite church sings in a variety of styles, most commonly 4-part music accompanied by a piano, and no director. But we also sing more "contemporary" styles.

Back in the earlier days, the church didn't have hymnals with music for everyone. The Vorsanger -- song leader -- would sing each phrase, then the congregation would sing it back in unison, throughout the whole song. Hymns that the congregation already knew well would just be sung normally, in unison, with the Vorsanger directing.

Not only did the Vorsanger lead the singing, but he or she also chose the music -- not the pastor. As the church purchased first a pump organ, and later a piano, the instruments would sometimes be used to accompany the singing. The musicians never knew what would be sung in advance. One 80-year-old member of our congregation remembered the she started to play for church at 8th grade. But much of the time, there would be no instrument, not even to pick the starting pitch.

This morning, we sang Holy God, We Praise Thy Name with the Vorsanger. It's a familiar song in our church, but we generally sing it in English. The Vorsanger taught it to us in German, the older people in church would have remembered it. He finished his introduction, stepped away from the microphone, and rang out with the first phrase.

Gro er Gott, wir loben dich

Then we all sang the phrase back to him, in unison. On to the next phrase, back and forth for the rest of the hymn. Terah and I were in the choir area, behind him, but could hear him -- and the rest of the congregation -- just fine.

At the end, our Vorsanger for a day said he thought we got it, so we sang through it again, still in unison, but without him leading us on each phrase.

Gro er Gott, wir loben dich,
Herr, wir preisen deine St rke,
Vor dir beugt die Erde sich
Und bewundert deine Werke.
Wie du warst vor aller Zeit,
So bleibst du in Ewigkeit.

What a powerful way to feel connected to the people that worshiped at the same place so many years ago.

As our director said before we sang in choir this morning, music can say so much more than words.

dpkg-cross updates
uploaded to Debian unstable



   * General support for querying endianness of an architecture.

   * Update standards version (no changes)

   * Add Cvs-CVS field to debian/control

   * Reinstate detect_arch for improved build test checks in emdebian-

     tools

   * get_endianness: new function for Emdebian TDeb support

This provides support for architecture-dependent TDebs in Emdebian as well as adding detection of armel.

emdebian-tools 0.8.3
Uploaded to Emdebian



   * Interim Emdebian release.

   * emsecondstage: ensure cdebconf environment is setup before

     configuring packages

   * emdebian.gpe: Add extra packages needed to allow the gpe package set

     to boot.

   * Emdebian::Tools, (create_patches) : skip generated files.

     [*.debhelper, *.substvars, files]

   * em_installtdeb: support special modes via debian/xcontrol

   * Support unpack method in basic emsandbox rootfs

   * embootstrap: continue after some errors

   * Support unpack method in gtk emsandbox rootfs

   * Simplify basic empdebuild chroot and copy in hostname files

   * empbuilderlib: add support for creating skeleton versions of

     /etc/group and /etc/passwd.

   * empbuilderlib: add an approximate time set func for use when no

     network is available.

   * emsecondstage: configure cdebconf before others so that the database

     is ready

   * embootstrap: use the new support in empbuilderlib for group, passwd

     and date

   * Add --arch support to em_installtdeb

   * Depend on new support in libdebian-dpkgcross-perl

   * empdebuild: force the -S argument to apt-cross to prevent

     intermittent failures

   * empbuilderlib: parse the .list contents from dpkg

   * embootstrap: ensure buildplace is clean before starting a fresh

     debootstrap

   * emdebuild: use dpkg-cross support for detect arch to distinguish

     between arm and armel binaries

   * Emdebian::Tools. add parse_xcontrol function for easy queries of

     debian/xcontrol

   * pbuilder/emdebian.crossd gpe gtk : Tidy up the scripts with routine

     calls to the empbuilderlib library

   * pbuilder/empbuilderlib: Add some common routines to help make the

     rootfs bootable

   * pbuilder/emsecondstage: bring into line with other changes in the

   * empbuilderlib.3 : Add a manpage for the expanded set of common

     functions in empbuilderlib

   * Suggest file-roller for inspection of rootfs tarballs

   * emdebhelper.mk: sync with recent changes in CDBS for debhelper

     support

Reasoning
OK, so why upload emdebian-tools to Emdebian when it depends on the update to dpkg-cross in Debian?
Well, emdebian-tools is becoming a bit of a behemoth. I mean a package that has only existed for 12months and has had over 30 releases, increasing in size from 30kb to over 500kb (without counting dependencies) and which encompasses a gammut of scripts with different roles is just begging for a functional package split.
Package splits take time - not just the time in NEW but all the testing to ensure that each split can be installed separately without falling over "Unable to find foo in @INC" etc.
At the same time, emdebian-tools is both rapidly developing and becoming remarkably stable (which gives some indication of just how diverse it has become).
So I'm heading for a 1.0.0 release before Lenny and to achieve that, I want to split it:

emdebian-tools - umbrella package consisting of the core build scripts (perl) - these are becoming quite stable - that depends on all the others.

emdebian-archive-keyring - tiny package that just implements SecureApt for the Emdebian repository.

emdebian-rootfs - the rapidly developing (shell and perl based) root filesystem management scripts, based on debootstrap and pbuilder.

libemdebian-tools-perl - a standard perl module of common functions for the other packages.

This allows people to use the toolchains with the smallest package, prepare root filesystems from prebuilt binary packages with just three of the four and only those who build packages will need all four.
So the plan, overall, is to keep updating emdebian-tools in Emdebian unstable during the time that emdebian-tools 0.9.0 goes through NEW in Debian. Then, when 0.9.x is in testing and any issues from the split are resolved, 1.0.0 can be uploaded to Debian.

Package split issues in general
Something that bugs me with package splits is this stable vs development issue within the same source. I think it would be sensible to only upload emdebian-tools (the stable bit) if it changes but to upload emdebian-rootfs as often as necessary whilst still building from the same source.
This issue will also bite when Emdebian deploys other functional package splits and seeks to improve apt itself to handle many, many more binary packages.
It's also a similar idea to allowing translators to upload TDebs separately from normal package updates.
Why should I have to split the source in $RCS in order to upload package splits separately? Other upstream teams won't do that so Debian needs a solution.
Why should users have to download emdebian-tools 1.0.1 which is absolutely identical to 1.0.0 just because emdebian-rootfs needed lots of updates in 1.0.1. (Remember, emdebian-tools will depend on emdebian-rootfs so when emdebian-rootfs is updated, all users of emdebian-rootfs and all users of emdebian-tools will get the update. Yet I don't see why emdebian-tools itself needs to be touched.)
It is plain daft.
I've seen similar issues in other environments where, for various very good reasons, users need to limit the bandwidth and duration of apt downloads. For Emdebian, we also need to limit the total amount of data downloaded by apt-get upgrade simply because free space on the device can be severely restricted - my target device will have about 7Mb free space and that is regarded as "under-utilised". Downloading an entire package just to update /usr/share/foo/changelog.gz in such circumstances is just plain stupid. I know we can do better than that.
Apt needs to become much more intelligent and have a way of only downloading the changes in packages instead of the entire .deb - something along the lines of an rsync method. To get that working, the actual package names need to be munged so that rsync can compare foo_1.2.3-1_all.deb against foo_1.2.3-2_all.deb by having both symlinked as foo_current_all.deb. (dpkg-name can restore the original name if needed.)
Such a method must be possible and would have enormous benefits for packages like OOo where each upload can't be changing 100% of the code each time, yet we all have to download Mb after Mb of content that is identical to what dpkg is about to replace.
Am I just ranting or does this strike a chord on the lazyweb in general?
The slowest part of many desktop experiences of Debian could well be the time taken to download updates - not everyone has multi Mb broadband.

Since my last example of fixing a bug received some interesting feedback (although I notice no upload of the package in question ..) we'll have another go. Looking over my ~/.bash_history file one command I use multiple times a day is make. Happily GNU make has at least one interesting bug open:

#419190 - make: double free or corruption

I verified this bug by saving the Makefile in the report and running make:

skx@gold:~$ make
make: file.c:84: lookup_file: Assertion  *name != '\0'' failed.
Aborted

(OK so this isn't a segfault; but an assertion failure is just as bad. Honest!) So I downloaded the source to make, and rebuilt it. This left me with a binary with debugging symbols. The execution was much more interesting this time round:

skx@gold:~$ ./make
*** glibc detected ***
  /home/skx/./make: double free or corruption (fasttop): 0x00000000006327b0 ***
======= Backtrace: =========
/lib/libc.so.6[0x2b273dbdd8a8]
/lib/libc.so.6(cfree+0x76)[0x2b273dbdf9b6]
/home/skx/./make[0x4120a5]
/home/skx/./make[0x4068ee]
/home/skx/./make[0x406fb2]
...
[snip mucho texto]

And once I'd allowed core-file creation ("ulimit -c 9999999") I found I had a core file to help debugging. Running the unstripped version under gdb showed this:

(gdb) up
#5  0x00000000004120a5 in multi_glob (chain=0x1c, size=40) at read.c:3106
3106			    free (memname);

So it seems likely that this free is causing the abort. There are two simple things to do here:

Comment out the free() call - to see if the crash goes away (!)
Understand the code to see why this pointer might be causing us pain.

To get started I did the first of these: Commenting out the free() call did indeed fix the problem, or at least mask it (at the cost of a memory leak):

skx@gold:~$ ./make
make: *** No rule to make target  Erreur_Lexicale.o', needed by  compilateur'.  Stop.

So, now we need to go back to read.c and see why that free was causing problems. The function containing the free() is "multi_glob". It has scary pointer magic in it, and it took me a lot of tracing to determine the source of the bug. In short we need to change this:

free (memname);

To this:

free (memname);
memname = 0;

Otherwise the memory is freed multiple times, (once each time through the loop in that function. See the source for details). Patch mailed.

Rapha l s my homeboy.

$ notAptable --help
notAptable [--version] [--help] [-s/var/lib/dpkg/status] [-aptf/path/to/aptavail/equiv/file] [-aptx'apt-cache dumpavail'] [-ipackagename]
List packages which are installed on the system but are not known by apt.
Options:
-s Path to file to use when grepping for installed packages
-aptf Path to file to use when grepping for the apt-able packages
-aptx Same as above but instead of being a file the specified command is executed
-i Exclude a package that would otherwise be listed
When not overriden by an option the default files/data is up to grep-dctrl's defaults
This script is said to report packages that were removed from the archive
(except those listed in /home/raphael/.listNotAptable.ignore)

Copyright 2008 by Raphael Geissert <atomo64@gmail.com>

With this simple script I wrote I got rid of about 45 packages (libraries, programs, etc, etc) what are no longer in the archive.
My question is: on what package should this script be shipped? debian-goodies? devscripts?

Hope somebody else finds this script useful and puts it in their weekly cronjob as I did :)
Get it from http://alioth.debian.org/~atomo64-guest/notAptable until it is shipped in some package.

Tomorrow I turn 32, so I've got to be all mature and responsible and stuff now. Maybe. This means no more song lyrics will be used for blog titles. Instead I shall switch to film quotes. Films are more mature than songs, right? There are three candidates standing for the DPL this year. I'm glad I didn't stand, but I came pretty close to doing so. I just think I'd be unlikely to receive the votes, and busy enough to fail even if I did get picked. It seems to me that every year people promise to do too many things; fixing NEW, fixing the NM process & etc.. Me? I'd have only one goal: Open up the keyring-handling. Nothing more. Nothing less. (Sure I'd blow all the Debian money on new toys for people but that'll be our little secret ;) Anyway since there was a bit of interest I've uploaded a new steam engine video and I've started to document some of my collection:

My steam engine page.

More updates later. Really I need to sit down, clean my toys, and then get some good pictures taken. Maybe next month I'll find the time. (Ha!)

When you join an academic department, you are just one body and mind among many others doing what you do: teach, write, go to conferences, answer a lot of student emails, advise, etc. However, what you don’t get to do is really see your colleagues very often. While we come together far too frequently for faculty meetings, once you are done, you just want to scuttle out of the room (and as quickly as possible) to continue what seems to be an endless stream of work. But over the course of months and years, there are times and moments when you do come across your colleagues and their work: you may assign some of their work in your class class, go see them speak at an event, or learn about their work over coffee. This weekend during a PhD prospective weekend, I finally got to learn about what is probably one of the coolest projects to come out of my department, The Dead Media Archive run by Ben Kafka and Alex Galloway for their Dead Media Archeology Class. Loosely inspired by a mailing list by the same name started years ago by Bruce Sterling (which eventually suffered its own death), they are collecting information and analyzing the significance of all sorts of Dead Media, some of which were quite present and important for our economy and communication systems, others which flickered much more briefly as a bright idea but never really caught on. As part of their class assignments, students have to write in-depth descriptions, histories, and analysis’ of these objects and they are fantastic; so if you are into dead media, do check out the archive.

I just finished re-reading one of my favorite books, Neil Stephenson's Cryptonomicon. I don't often reread books, but this one is really a classic, and I got even more out if it the second time around. If for some reason you haven't already read it, and you are the type of person who likes sci-fi, startups, computers, crypto and the like, I'd highly recommend it. I'm a pretty quick reader, so having a book that lasts a week or two is also a pleasant change from briefer, quicker material. There are lots of subtle references and nuances to keep your mind entertained outside of the main story line, which is pretty good in and of itself, spanning two timelines, one during the second world war, and one in the late nineties (it's been a while since I've had to type startx to launch a GUI on Linux!).

Much as been done on ctioga since the last release, not even two weeks ago: small bug fixes, tangents improvements, the rebirth of a --subplot option, a saner framework for plot styles... But the most significant improvement in my opinion is the possibility to make non-linear axes: you just need to provide a two-ways transformation between the standard coordinates and the axis coordinates, and ctioga does the rest:

ctioga -N --xpdf --math --math-xrange 2:8 \
  'sin(x)' --xaxis bottom --new-axis biniou top \
  --axis-function biniou 1/x 1/x \
  --lines-color biniou Gray --no-title

As you can see, I did profit to add the possibility of background lines corresponding to the axes' major ticks. The only real trick that is left is to find a decent way to partition the target segment so that they ticks are "natural" (not 0.34759, for instance) and reasonably equally spaced. I thought other plotting programs had dealt with this, but in fact, that doesn't seem to be the case: I'll have to do that myself.

* Just say ‘Hi’ to me, if you are in BLR. I’ll be here

Even, after journey of 22 hours, I am very much fresh like lime soda. Work is not yet started, but getting into it. I have joined Comat, where very familiar guys - Jace, Parthan and Kushal rocks. Thanks guys for warm welcome!