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 recently got a Toshiba Tecra A10-1HU laptop. This is a series describing my experiences with this hardware using Debian Sid.
This one comes without any operating system. So I got a recent testing-netinstall CD-image and ran the installer procedure (in expert mode). Everything went fine and I ended with a shiny Squeeze and kernel 2.6.30. Because I use Sid as my usual system, my first action was a dist-upgrade to Sid.
This is what lspci -nn tells:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) 00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07) 00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03) 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03) 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03) 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03) 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03) 00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 [8086:2944] (rev 03) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93) 00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03) 00:1f.2 SATA controller [0106]: Intel Corporation ICH9M/M-E SATA AHCI Controller [8086:2929] (rev 03) 01:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232] 05:0b.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ba) 05:0b.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04) 05:0b.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 21) 05:0b.3 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev ff) 05:0b.4 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 11) 05:0b.5 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev 11)
The integrated graphics chipset, an Intel GMA 4500M HD, works with the xserver-xorg-video-intel package and the default X.org configuration. No custom /etc/X11/xorg.conf is necessary.
The (IMHO non-reflecting?) display runs at 1280×800 at 60 Hz.
The integrated Intel 82567LM Gigabit Network device works with the e1000e kernel module. No customization was necessary.
The notebook comes with the so called Toshiba Dual Pointing Device a touchpad (+2 buttons) and a trackpoint (+2 buttons). Both worked without customization.
apmd and acpid handle this. No problems yet. Suspend/Resume works. I did not yet test (and I’m not sure if I should) hibernate and uswsusp.
The webcam is a CNA7157 model or at least detected as such. The video4linux modules handle it and the cheese application produces pictures.
It works. Module and package information will follow as soon as I figure them out.
The notebook comes with an Intel WiFi Link 5100 device. It does not work out-of-the-box. Following this article, I’ve installed the firmware-iwlwifi package and loaded the iwlagn module.
For the sound device to work the snd_hda_intel module is necessary. Further the following lines must be added to /etc/modprobe.d/alsa-base.conf
# not sure about the first line, start adding the second only options snd-cmipci mpu_port=0x330 fm_port=0x388 options snd-hda-intel index=0 model=toshiba position_fix=1
After installing the sensors-applet I got two identical temperature displays. I’m not sure what they show. Anybody an idea how to examine this?
The notebook comes with an internal modem device:
00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07)
From what I read I need hsfmodem or the sl-modem packages. “Unfortunately” the latest version is not available for amd64 from the archive, although it seems to have been built.
I did not yet test
This what lspci -k -nn tells about the used kernel modules:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: agpgart-intel 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) Subsystem: Toshiba America Info Systems Device [1179:0004] 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem: Toshiba America Info Systems Device [1179:0004] 00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07) Subsystem: Toshiba America Info Systems Device [1179:0001] 00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: e1000e 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: ehci_hcd 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: HDA Intel 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03) Kernel driver in use: pcieport-driver 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03) Kernel driver in use: pcieport-driver 00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 [8086:2944] (rev 03) Kernel driver in use: pcieport-driver 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: ehci_hcd 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93) 00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] 00:1f.2 SATA controller [0106]: Intel Corporation ICH9M/M-E SATA AHCI Controller [8086:2929] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: ahci 01:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232] Subsystem: Intel Corporation Device [8086:1201] Kernel driver in use: iwlagn 05:0b.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ba) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: yenta_cardbus 05:0b.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: firewire_ohci 05:0b.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 21) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: sdhci-pci 05:0b.3 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev ff) Kernel driver in use: ricoh-mmc 05:0b.4 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 11) Subsystem: Toshiba America Info Systems Device [1179:0001] 05:0b.5 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev 11) Subsystem: Toshiba America Info Systems Device [1179:0001]
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).
The recent update to udev 0.140 lead to a system without network access to me. The error messages were:
Running 0dns-down to make sure resolv.conf is ok...done. Setting up networking.... Configuring network interfaces... ioctl[SIOCGIFFLAGS]: No such device Could not get interface ‘ath0′ flags ioctl[SIOCSIWPMKSA]: No such device ioctl[SIOCSIWMODE]: No such device Could not configure driver to use managed mode ioctl[SIOCGIWRANGE]: No such device ioctl[SIOCGIFINDEX]: No such device ioctl[SIOCSIWENCODEEXT]: No such device ioctl[SIOCSIWENCODE]: No such device ioctl[SIOCSIWENCODEEXT]: No such device ioctl[SIOCSIWENCODE]: No such device ioctl[SIOCSIWENCODEEXT]: No such device ioctl[SIOCSIWENCODE]: No such device ioctl[SIOCSIWENCODEEXT]: No such device ioctl[SIOCSIWENCODE]: No such device ioctl[SIOCSIWAP]: No such device ioctl[SIOCGIFFLAGS]: No such device wpa_supplicant: /sbin/wpa_supplicant daemon failed to start /etc/network/if-pre-up.d/wpasupplicant exited with return code 1 SIOCSIFADDR: No such device ath0: ERROR while getting interface flags: No such device SIOCSIFNETMASK: No such device SIOCSIFBRDADDR: No such device ath0: ERROR while getting interface flags: No such device ath0: ERROR while getting interface flags: No such device Failed to bring up ath0. done.
It seems, the update added rules to /etc/udev/rules.d/70-persistent-net.rules by increasing the device number and applying the last applicable NAME directive instead of the first one. This lead to the following file here:
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="XX:XX:XX:XX:XX:a7", ATTRS{type}=="1", NAME="ath0"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="XX:XX:XX:XX:XX:18", NAME="eth0"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="XX:XX:XX:XX:XX:XX", NAME="eth1"
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="XX:XX:XX:XX:XX:18", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
# PCI device 0x168c:0x0013 (ath_pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="XX:XX:XX:XX:XX:a7", ATTR{type}=="1", KERNEL=="ath*", NAME="ath1"
So the devices created were eth2 and ath1 but /etc/network/interfaces contained entries for eth0 and ath0. So fixed /etc/udev/rules.d/70-persistent-net.rules and rebooted.
<rant>Is it really necessary to break network access with an update???</rant>
I forgot this one: #521521.
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 :)
Gratulation und ein riesiges “Danke!” an unsere Deutsche Nationalmannschaft für diese schöne und eigentlich grandiose Europameisterschaft. Ihr habt uns auch ohne den Titel Spaß und Freude gebracht und das Sommermärchen fortgesetzt. In 2 Jahren geht’s weiter ;)
Yesterday I stumbled about files and dead symlinks left in /usr/lib/python2.3/site-packages/ on my Sid box. These files/symlinks seem to have been shipped/created(?) by:
python-ldap python-cairo python-crypto kiki python-foomatic python-mysqldb python-logilab-common python-egenix-mxtools python-numarray python-pygresql python-imaging-sane python-imaging python-xml python-reportlab
Deleting /usr/lib/python2.3 (dpkg -S didn’t show any package relationship nor did I find something in /var/lib/dpkg/info/) and reinstalling the above mentioned packages did not recreate the files/symlinks. So it seems the directory can be safely removed. Maybe I missed some announcement or one (or more) packages need to be fixed. No time to examine it atm.
Update
This is known as Debian bug #409390. Thanks to Josselin Mouette for the information.
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.
Gestern hat das Bundesverfassungsgericht per Eilentscheidung die Vorratsdatenspeicherung zunächst einmal eingeschränkt. Dabei bescheinigten die Richter dieser Maßnahme einen “erheblichen Einschüchterungseffekt”. Der stellvertrendende Regierungssprecher Thomas Steg sagte dazu: “Im Kabinett jedenfalls ist die Entscheidung nicht lange diskutiert worden und sie ist mit großer Gelassenheit zur Kenntnis genommen worden.”. Wie bitte? Mir ist nicht ganz klar, wie sich die Einschüchterung der Bevölkerung mit der freiheitlich demokratischen Grundordnung vereinbaren lässt. Offenbar ist diese Regierung an letzterem nicht länger interessiert, sonst hätte man die Aussage der roten Roben nicht mit großer Gelassenheit zur Kenntnis genommen.
Es bleibt nur zu hoffen, dass das Bundesverfassungsgericht die Zugriffsmöglichkeiten und die Speicherfristen in seiner endgültigen Entscheidung weiter beschränken wird. Nach bisherigem Vernehmen wird das Gesetz selber wohl nicht gekippt werden (AFAIK und IANAL).
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 :)