It is true that making /var/cache/pbuilder/build a tmpfs makes a noticeable speed difference. But it seems you cannot cache the downloaded debs: ln: creating hard link ...: Invalid cross-device link.
I recently bought an external USB harddrive, made by Toshiba. It’s the HDDR500E03X model with 500GB space, internal shock sensor and ramp loading technology. Now yesterday I learned, that I can also cover its health status using the smartmontools. The usb* device types did not fit, but the sat type worked. It is as easy as running:
smartctl -d sat -c /dev/sdb smartctl -d sat -t long /dev/sdb
Connecting a NOKIA 6310i mobile phone via serial DLR-3P cable and the serial connector of the laptop (for Bluetooth see part II): After installation of the gnokii package(s) the the configuration file says:
model = 6510 connection = dlr3p
Then gnokii reports:
$ gnokii --identify GNOKII Version 0.6.28 IMEI : XXXX Manufacturer : Nokia Modell : 6310i Product name : NPL-1 Revision : V 5.22
So I got a little bit further with my little toy.
Bluetooth works. The packages gnome-bluetooth and bluez are installed and the kernel module bluetooth is loaded. hciconfig reports this:
# hciconfig hci0: Type: USB BD Address: XX:XX:XX:XX:XX:XX ACL MTU: 310:10 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:11354 acl:105 sco:0 events:286 errors:0 TX bytes:4012 acl:99 sco:0 commands:66 errors:0
I tried to connect to a SAMSUNG and a NOKIA mobile phone. After enabling visibility of the phone the bluetooth-applet (gnome-bluetooth) showed the device. However I got an error saying “The name org.openobex was not provided by any .service files” when trying to access the mobile device. This was solved by installing obexd-server obex-data-server. Then I was able to access the phone contents via Bluetooth.
I recently tried to debug the mopac7 build error. I installed the qemu(-qemu-kvm) emulator. Loading of the kvm_intel module failed with “kvm: disabled by bios”. But this was easy to solve by enabling the Intel virtualization technology in the BIOS: push and hold the ESC key during startup until the laptop tells you to press the F1 key. Then enable the related BIOS option and done.
A tragic loss has hit the open source software community. Warren Lyford DeLano, among other things, open source advocate, scientist and the author of the famous PyMOL molecular visualization system, suddenly passed away at the age of 37. I remember you as a genial, pleasent intelligent guy and software author. It has been a pleasure to work with you. Good bye.
I’m back from the conference at Berlin “Faktor X - Tag der natürlichen Ressourcen”, a side-conference of the World Resources Forum 2009 in Davos.
It was pretty interesting, although the topic is not new. If you don’t know it: We are running out of (several) resources. The main topics going through the media are often “energy” and “oil”. Well, several metals will become much more problematic much more earlier! So, what is the aim: material-, product- and production-efficiency and recycling/upcycling(/downcycling).
One of the topics mentioned at the conference was the IT industry. One of the keywords is “green IT” - more efficiency through IT, more efficiency by more efficient hardware, better recycling of hardware, …. Another point was “more efficiency by more efficient software”. One of the questions mentioned was “how much resources costs a click at google”. I think, one can adapt this question to almost every software. We have several software, which is widely used. I’ll just mention the apache web-server. Would’t it be good to know, that this widely used software won’t waste CPU cycles for nothing?
So what about a GSoC project checking such “often/widely used” software for efficiency (besides checking for buffer or heap overflows or NULL pointer dereferences)? Can anybody imagine such a project? What is your opinion?
I always wanted to write a short howto for Debian package maintainers, how to write a manual page in GROFF. This is useful for short documents (for longer documents, docbook/docbook-xsl can be a good choice). I already have written some parts. However, here is the first part of hints. More might follow later.
The name section is (probably) the only place, where exactly one hypen-minus \- must appear. The hyphen-minus is the delimiter between the command name and one-line description.
.SH NAME foo-bar \- foos the template foo-what-bar
Using a .PP macro directly following a .SH or .SS macro is useless. This macro should be used between paragraphs:
.SH OPTIONS The program follows the usual GNU command line syntax, with long options starting with two dashes (`\-'). .PP A summary of options is included below.
To describe options or files it’s usually useful to make use of the .TP macro.
.SH OPTIONS .TP .B \-f, \-\-force Force the execution of the specified command.
.SH FILES .TP .I ~/.foobar Per user configuration file.
To create more than one intended paragraph the .IP macro can be used.
.TP .B \-f, \-\-force Force the execution of the specified command. .IP This option has no effect in conjunction with \fB\-\-foo\fP.
Usually we don’t want URLs or URIs to be hyphenated. This can be done using the \% sequence. Typical examples:
A short tutorial is available online at \fI\%http://foo.tld/some/path/here/manual.html\fP.
On a Debian system the complete text of the GNU General Public License version 2 can be found in the file \fI\%/usr/share/common-licenses/GPL\-2\fP.
The common markup is to write the person name in bold letters and the mail address in roman letters is put into angle brackets. It’s usually a good idea to mark where the mail address starts and ends. We can use the \& sequence as shown in the following example:
\fBDaniel Leidert\fP <\&daniel.leidert@wgdd.de\&>
I tried to connect my university workstation to the wireless eduroam network on the campus. The workstation was delivered with an Abit AirPace wlan card (probably an Atheros 5006 chipset). The first thing necessary was the ath5k kernel module (my first shot using ndiswrapper didn’t work). Both Debian lenny and Ubuntu intrepid-updates provide it.
Now there are generally 3 ways to connect to the AP. All making use of wpasupplicant. Further the certificate (may differ for the universities) is necessary.
This is described at the sites of my university. It’s written in German, but it should still be easy to understand. Let’s just mention the snippet for /etc/wpa_supplicant/wpa_supplicant.conf:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=2
ap_scan=1
fast_reauth=1
network={
ssid="eduroam"
key_mgmt=WPA-EAP
proto=RSN
pairwise=CCMP
group=TKIP
eap=TTLS
anonymous_identity="anonymous@tu-dresden.de"
identity="****@tu-dresden.de”
password=”****”
ca_cert=”/etc/wpa_supplicant/TUD-CACert.pem”
phase2=”auth=PAP”
}
Instead of the script suggested at the site above, you can also use this snippet in /etc/network/interfaces:
auto wlan0 iface wlan0 inet dhcp wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
It is also possible to put the values directly into /etc/network/interfaces:
auto wlan0 iface wlan0 inet dhcp wpa-ssid eduroam wpa-proto RSN wpa-group CCMP TKIP wpa-pairwise CCMP TKIP wpa-key-mgmt WPA-EAP wpa-eap TTLS wpa-ca-cert /etc/wpa_supplicant/TUD-CACert.pem wpa-phase2 "auth=PAP" wpa-anonymous-identity anonymous@tu-dresden.de wpa-identity ****@tu-dresden.de wpa-password ****
Here is a screenshot of the authentication dialog.
So now everybody at the University of Dresden wanting to use eduroam should hopefully be able to configure this connection on his Debian/Ubuntu system.
Maybe you will observe a changed mouse and keyboard behaviour after updating X.org recently in Debian Sid. Then you will probably discover the warning mentioned in the title in your X.org server log /var/log/Xorg.0.log. The very short and dirty solution to get things working for the moment is to put this into your /etc/X11/xorg.conf:
Section "ServerLayout"
Option "AutoAddDevices" "off"
EndSection
See the first entry in /usr/share/doc/xserver-xorg/NEWS.Debian.gz and follow the mentioned links for more information. However, the above solution should only be a temporary workaround: Try to migrate things (I will post changes for my system asap).
Now that Lenny has been released I’ve updated some machines and found just one flaw. There is a cvsd installation, which has been extended with an OpenSSH server. After the upgrade the server refused the connection. Enabling debugging output showed:
sshd[...]: fatal: ssh_selinux_getctxbyname: ssh_selinux_getctxbyname: security_getenforce() failed
in the log. Searching the web a bit revealed, that the CHROOT now needs a mounted /proc. Done and everything works :)
Ok, shit sometimes also happens to Debian users.
Now I read a lot of FUD, flames, arrogant claims and much more bad things, including blaming of downstream in general.
Well, Debian maintainers are NOT upstream authors. Maintainers often care about a lot more than just 1 package. Now I wonder if one can really expect, that maintainers know the source code of their packages as good as upstream authors do? Is this, what the user or the Debian project expects from a package maintainer? I agree, that this would be the ideal situation. But how realistic is it, if one maintains 10, 20 or more packages?
Normally users report us issues. We take a look at the source, try to catch the issue, track it down and fix it. And IMHO in almost all cases this is enough and it lets us handle several packages. And maybe this is also, what happened here. The maintainer got a report, tracked it down and tried to fix it. It seems, he posted it to the openssl-dev list, which is to my reading considered for such questions, and got a positive response. And with fixing it, he made a horrible mistake. But apparently it also seems, that the question had been discussed earlier more than just once (I wish, the OpenSSL guys would have created the FAQ entry earlier).
I don’t want to blame the maintainer for doing this mistake. We are humans. But do we need another instance, that (periodically) checks (probably only Debian-specific) patches/changes to security relevent software or do we need different requirements for maintainers of such software [1] or should we simply archive this under “Shit sometimes happens … even to Debian users”?
[1] Consider gnupg which is currently almost unmaintained. It also has Debian specific patches applied and I wonder, which skills the new maintainer should or must(?) have (IIRC this question was raised in the linked threads too)?
I’m sorry for any inconvenience you had yesterday or today trying to access my web services. But I had to perform some long standing maintenance tasks. The service is now running again. If you still observe problems, please don’t hesitate to tell me.
Wie vor wenigen Tagen veröffentlicht, hat das Lenkungsgremium des DIN-Normenausschusses Informationstechnik und Anwendungen (NIA) entschieden, dass bei der Abstimmung zum OOXML-Schrott “nach formalen Kriterien der Prozessablauf in der ISO nach Meinung des Lenkungsgremiums” nicht “fehlerhaft gewesen sei”.
Bei gerade einmal 7(!) von insgesamt 20 Stimmen, die dafür stimmten (6 stimmten explizit dagegen und eine Ja-Stimme holte man sich auch noch vom hauptamtlichen Mitarbeiter des DIN), bleibt mir nur zu sagen: Wohl kaum, liebes DIN! Mit diesem Ergebnis dann auch noch von einer “falschen und irreführenden” Berichterstattung bei den objektiven Berichterstattern zu sprechen, ist einfach nur unverschämt. Wenn gerade einmal 1/3 der Stimmberechtigten votieren, dass ein Verfahren keine Verfahrensmängel hatte und das als Beweis dieser These herangezogen wird, dann spreche ich von einer falschen und irreführenden Berichterstattung bei der DIN.
Because my diploma exams are getting nearer, I have to reduce my contribution to the Debian project for the next two months (up to mid/end of May). There is fortunately currently not much to do for me and also no need to NMU my packages. But please read the following notes, if you (still) think there is a reason for a NMU:
Done. All related packages have been fixed. My sponsor just needs to upload psicode to fix the last outstanding bug.
PS: Also the build-twice-in-a-row release goal will be reached by the upload of the apbs update by my sponsor.
Almost done. mpqc already reached the buildds. ghemical has been uploaded, but waits for mopac7 and libghemical, which are in NEW because of the new library names.
apbs and psicode already have been transitioned.
Ok, I’ve closed almost all relevant bugs in my packages. There are a few outstanding bugs that should be examined for Lenny and can be fixed in NMUs - preferable via delayed NMU queue and an information to the debichem group:
For the xmlto package it was planned to add the dblatex toolchain for PDF/PS/DVI creation because passivetex will very probably never have a comeback in Debian and docbook-xsl/fop is not fully main and cannot create DVI output. In the case you want to help, feel free to add this feature by NMU to experimental (maybe with version 0.0.21~dblatexX.Y). A first patch is available in bug report #416622.
It is possible that there will be a new upstream release for docbook-xsl in the near future. DO NOT consider uploading it by NMU if you did not test it! This upcoming release ships manpage stylesheets, that have been rewritten in large parts. So regressions can be expected. Fortunately Michael Smith and me agreed, that we should test it carefully, before the release is done. Unfortunately I will not have the time to do it. So if you consider uploading it, please get in contact with Michael (xmldoc) and offer your help testing it. He added (and I hope, many Debian packagers and packaging groups will like that) some kind of regressions tests. These tests build the manpages from several Debian packages: e.g. samba, apt, aptitude, git, fglrx and some more. There are further some new supported features, that should be added to the manpage example shipped with the Debian package. I also planned to split the source package (atm, docbook-xsl and docbook-xsl-doc tarballs are merged together for Debian) as soon as docbook-xsl-ns is packaged - which I wanted to do with the next upstream release. So consider all of the above notes if you plan an NMU to upload a new upstream release and in question, mail me and wait for my answer (which will need some days).
In all other cases, new upstream releases should be easier to handle.
All my ITPs are delayed. However if you plan to still upload one of these packages, you should consider the following notes:
Several lintian warnings have already been fixed in the SVN repositories used for my packages but have not yet been uploaded.
I really only plan to reduce my work during the preparation and the exams. So whatever you do, please try to make it easy for me to continue my packaging work after the exams :)
pbuilder with default settings will fail to build a package depending on sun-java5 or sun-java6, because the license needs to be accepted first.
Now some time ago I saw a patch for pbuilder itself to “fix” this, but for the time beeing I used to set DEBIAN_FRONTEND to readline in my pbuilderrc. But today Michael Koch came up with much better suggestions: Preset the debconf value in the CHROOT and save it.
It’s pretty easy:
$ sudo pbuilder login --save-after-login # echo "sun-java5-jdk shared/accepted-sun-dlj-v1-1 boolean true" | debconf-set-selections # echo "sun-java6-jdk shared/accepted-sun-dlj-v1-1 boolean true" | debconf-set-selections # exit
and voila, problem solved. Thanks to Michael for the tip.
Update
Manual Prinz suggested a slightly different way, that realizes the same debconf setting, but with hooks:
http://lists.debian.org/debian-java/2008/05/msg00024.html.
I promised it some time ago and now it has been done: Debian packages for the development tree (1.1 series) of Bluefish are ready for Debian users (i386 only). The packages can be installed along with the stable version, so you can safely test new features and give us feedback and bug reports.
NOTE: The packages cannot be (re)built on Etch, because debhelper version 5.0.57 or higher is necessary. I will fix this part of debian/rules soon, so it can be (re)built on Etch too.
Some days ago I wrote down my experiences with packaging docbook-defguide. The main (remaining) issues I mentioned were the resources and the time the package needs to build. Even on an AMD X2 4600+ with 6GB of RAM it needs 7-8 hours.
Today I met with Torsten Werner. He mentioned, that there are some move JVMs I could try. So I tested alternatives to GIJ this night. I found this short summary about free JVMs, which was some kind of interesting.
I began with cacao, which seemed to be fast, but it was killed very early in the build process with an java.lang.OutOfMemory error. Even playing around with the -Xms and -Xmx switches in buildtools/saxon.sh did not help. So I dropped cacao from the list. Seems both cacao and kaffe create similar problems here and are not suitable for building the package.
Second alternative I tried was sablevm. It directly throw out some warnings or errors so I directly dropped it too.
Next JVM was jamvm. But it was as slow as GIJ. So I dropped it from the list of alternatives too.
Then I found an interesting statement in the article I linked somewhere above. The author said, that his perfomance test time with GCJ/GIJ reduced from 433 to 9 seconds, when he compiled his application into a native executable. So I took a fast look through the docbook-defguide build dependencies and found, that Debian already provides a natively compiled Xerces package libxerces2-java-gcj. But there were no packages for libsaxon-java, libxml-commons-resolver1.1-java and docbook-xsl-saxon. So short and dirty: I downloaded the source for these packages, added the necessary stuff to get natively compiled packages too, built and installed them. Fortunately packages with native code already exist (JAXP 1.3 and Xerces) for their dependencies.
And what should I say: Now building the TDG needs less then 512MB RAM and it builds in around an hour … even on my system. I will ask the Debian Java maintainers to add -gcj packages for Saxon and XML-Commons and fix my own docbook-xsl-saxon package. This will hopefully help maintaining docbook-defguide.
Ok guys. After spending several hours of this weekend to package the latest release of Norman Walshs DocBook: The Definitive Guide, I’m now proud to tell you: It’s done!
I was able to build the package with a free Java engine (GIJ) so docbook-defguide can stay in main. However, it was some kind of disappointing: Sun Java needs an hour and a maximum heapsize of 512MB to build the package on my system. GIJ needs 16 hours and a maximum heap size of 1GB to build. kaffe, which I tried too, fails much earlier than GIJ with a maximum heap size of 512MB. So I decided against it and for GIJ.
If you know of a way to speed up the build process (besides the possibility to buy a faster system … except you want to make it your christmas or birthday present for me *g*), don’t hesitate to tell me. The packaging files are in the Debian XML/SGML groups SVN repository.
However, expect the package in your Debian repository soon (guess, my sponsor wants to rebuild it, which may need another 1x hours :)).
Ardo van Rangelrooij kindly offered to build the package on an AMD X2 4600+ with 6GB. The build time decreased to at least 7-8 hours. The package will be uploaded to the Debian archive within the next days.
Now that I discovered this nice flag I checked a few of my packages. It works nice for the gnome-chemistry-utils application packages. Unfortunately libgcu0 does not benefit from the flag because of libtool bug #347650. However there is an appreciably difference in the dependencies for the plugin and application packages, where the amount of dependencies decreased. For example compare the old
Depends: iceweasel | iceape-browser | xulrunner, libart-2.0-2 (>= 2.3.18), libatk1.0-0 (>= 1.20.0), libc6 (>= 2.6.1-1), libcairo2 (>= 1.4.0), libgcc1 (>= 1:4.2.1), libgconf2-4 (>= 2.13.5), libgcu0 (<< 0.9), libgcu0 (>= 0.8), libgl1-mesa-glx | libgl1, libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.14.0), libglu1-mesa | libglu1, libgnomecanvas2-0 (>= 2.11.1), libgnomeprint2.2-0 (>= 2.17.0), libgnomeprintui2.2-0 (>= 2.17.0), libgnomevfs2-0 (>= 1:2.17.90), libgoffice-0-4 (>= 0.4.2), libgsf-1-114 (>= 1.14.7), libgtk2.0-0 (>= 2.12.0), libgtkglext1, libice6 (>= 1:1.0.0), libnspr4-0d (>= 1.8.0.10), libopenbabel2, liborbit2 (>= 1:2.14.1), libpango1.0-0 (>= 1.18.3), libsm6, libstdc++6 (>= 4.2.1), libx11-6, libxml2 (>= 2.6.27), libxmu6, libxt6, zlib1g (>= 1:1.2.3.3.dfsg-1)
and the new Depends field for gcu-plugin:
Depends: libc6 (>= 2.6.1-1), libgcc1 (>= 1:4.2.1), libgcu0 (<< 0.9), libgcu0 (>= 0.8), libglib2.0-0 (>= 2.14.0), libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0), libnspr4-0d (>= 1.8.0.10), libstdc++6 (>= 4.2.1), libx11-6, libxml2 (>= 2.6.29), iceweasel | iceape-browser | xulrunner
As another example bluefish now (the next upload) really only shows the necessary dependencies. Compare the current:
Depends: libart-2.0-2 (>= 2.3.18), libaspell15 (>= 0.60), libatk1.0-0 (>= 1.20.0), libbonobo2-0 (>= 2.15.0), libbonoboui2-0 (>= 2.15.1), libc6 (>= 2.6.1-1), libcairo2 (>= 1.4.0), libfontconfig1 (>= 2.4.0), libgconf2-4 (>= 2.13.5), libglib2.0-0 (>= 2.14.0), libgnome2-0 (>= 2.17.3), libgnomecanvas2-0 (>= 2.11.1), libgnomeui-0 (>= 2.17.1), libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0), libice6 (>= 1:1.0.0), liborbit2 (>= 1:2.14.1), libpango1.0-0 (>= 1.18.2), libpcre3 (>= 6.0), libpopt0 (>= 1.10), libsm6, libx11-6, libxcomposite1 (>= 1:0.3-1), libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3 (>= 1:4.0.1), libxi6, libxinerama1, libxrandr2 (>= 2:1.2.0), libxrender1
to the “upcoming” Depends field:
Depends: libaspell15 (>= 0.60), libc6 (>= 2.7-1), libglib2.0-0 (>= 2.14.0), libgnomeui-0 (>= 2.17.1), libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0), libpango1.0-0 (>= 1.18.3), libpcre3 (>= 6.0)
Nice result. I should check (my) other packages too :) Maybe that’s also something for debichems TODO list.