These instructions are for qotom devices Q515P and Q1075GE. You can order one from Amazon or directly from Cherry Ni <export03@qotom.com>. Instructions are for those coming from Windows. Prerequisites:

• A USB keyboard and mouse
• A powered HDMI monitor and an HDMI cable
• A copy of the Proxmox VE Installer ISO
• A USB disk from which to boot the installer
• Software and instructions to burn the raw image to USB
• The details of your wireless network including wireless network ID (SSID), WPA password, gateway address and network prefix length

To find your windows network details, run the following command at the command prompt:

netsh interface ip show addresses

Here s my output:

PS C:\Users\cjcol> netsh interface ip show addresses "Wi-Fi"
Configuration for interface "Wi-Fi"
    DHCP enabled:                         Yes
    IP Address:                           172.16.79.53
    Subnet Prefix:                        172.16.79.0/24 (mask 255.255.255.0)
    Default Gateway:                      172.16.79.1
    Gateway Metric:                       0
    InterfaceMetric:                      50

Did you follow the instructions linked above in the prerequisites section? If not, take a moment to do so now.
Open Rufus and select the proxmox iso which you downloaded. You may be warned that Rufus will be acting as dd.
Don t forget to select the USB drive that you want to write the image to. In my example, the device is creatively called NO_LABEL .
You may be warned that re-imaging the USB disk will result in the previous data on the USB disk being lost.
Once the process is complete, the application will indicate that it is complete.
You should now have a USB disk with the Proxmox installer image on it. Place the USB disk into one of the blue, USB-3.0, USB-A slots on the Qotom device so that the system can read the installer image from it at full speed. The Proxmox installer requires a keyboard, video and mouse. Please attach these to the device along with inserting the USB disk you just created. Press the power button on the Qotom device. Press the F11 key repeatedly until you see the AMI BIOS menu. Press F11 a couple more times. You ll be presented with a boot menu. One of the options will launch the Proxmox installer. By trial and error, I found that the correct boot menu option was UEFI OS Once you select the correct option, you will be presented with a menu that looks like this. Select the default option and install. During the install, you will be presented with an option of the block device to install to. I think there s only a single block device in this celeron, but if there are more than one, I prefer the smaller one for the ProxMox OS. I also make a point to limit the size of the root filesystem to 16G. I think it will take up the entire volume group if you don t set a limit. Okay, I ll do another install and select the correct filesystem. If you read this far and want me to add some more screenshots and better instructions, leave a comment.

The purpose of this post is to demonstrate a first approach to the analysis of multiwavelength kinetic data, like those obtained using stopped-flow data. To practice, we will use data that were acquired during the stopped flow practicals of the MetBio summer school from the FrenchBIC. During the practicals, the student monitored the reaction of myoglobin (in its Fe(III) state) with azide, which yields a fast and strong change in the absorbance spectrum of the protein, which was monitored using a diode array. The data is publicly available on zenodo. Aims of this tutorial The purpose of this tutorial is to teach you to use the free softwareQSoas to run a simple, multiwavelength exponential fit on the data, and to look at the results. This is not a kinetics lecture, so that it will not go in depth about the use of the exponential fit and its meaning. Getting started: loading the file First, make sure you have a working version of QSoas, you can download them (for free) there. Then download the data files from zenodo. We will work only on the data file Azide-1.25mm_001.dat, but of course, the purpose of this tutorial is to enable you to work on all of them. The data files contain the time evolution of the absorbance for all wavelengths, in a matrix format, in which each row correpond to a time point and each column to a wavelength. Start QSoas, and launch the command:

QSoas> load /comments='"'

Then, choose the Azide-1.25mm_001.dat data file. This should bring up a horizontal red line at the bottom of the data display, with X values between about 0 and 2.5. If you zoom on the red line with the mouse wheel, you'll realize it is data. The /comments='"' part is very important since it allows the extraction of the wavelength from the data. We will look at what it means another day. At this stage, you can look at the loaded data using the command:

QSoas> edit

You should have a window looking like this: The rows each correspond to a data point displayed on the window below. The first column correspond to the X values, the second the Y values, and all the other ones to extra Y columns (they are not displayed by default). What is especially interesting is the first row, which contains a nan as the X value and what is obviously the wavelength for all the Y values. To tell that QSoas should take this line as the wavelength (which will be the perpendicular coordinate, the coordinate of the other direction of the matrix), first close the edit window and run:

QSoas> set-perp /from-row=0

Splitting and fitting Now, we have a single dataset containing a lot of Y columns. We want to fit all of them simultaneously with a (mono) exponential fit. For that, we first need to split the big matrix into a series of X,Y datasets (because fitting only works on the first Y). This is possible by running:

QSoas> expand /style=red-to-blue /flags=kinetics

Your screen should now look like this: You're looking at the kinetics at all wavelengths at the same time (this may take some time to display on your computer, it is after all a rather large number of data points). The /style=red-to-blue is not strictly necessary, but it gives the red to blue color gradient which makes things easier to look at (and cooler !). The /flags=kinetics is there to attach a label (a flag) to the newly created datasets so we can easily manipulate all of them at the same time. Then it's time to fit, with the following command:

QSoas> mfit-exponential-decay flagged:kinetics

This should bring up a new window. After resizing it, you should have something that looks like this: The bottom of the fit window is taken by the parameters, each with two checkboxes on the right to set them fixed (i.e. not determined by the fitting mechanism) and/or global (i.e. with a single value for all the datasets, here all the wavelengths). The top shows the current dataset along with the corresponding fit (in green), and, below, the residuals. You can change the dataset by clicking on the horizontal arrows or using Ctrl+PgUp or Ctrl+PgDown (keep holding it to scan fast). See the Z = 728.15 showing that QSoas has recognized that the currently displayed dataset corresponds to the wavelength 728.15. The equation fitted to the data is: $$y(x) = A_\infty + A_1 \times \exp -(x - x_0)/\tau_1$$ In this case, while the \(A_1\) and \(A_\infty\) parameters clearly depend on the wavelength, the time constant of evolution should be independent of wavelength (the process happens at a certain rate regardless of the wavelength we're analyzing), so that the \(\tau_1\) parameter should be common for all the datasets/wavelengths. Just click on the global checkbox at the right of the tau_1 parameter, make sure it is checked, and hit the Fit button... The fit should not take long (less than a minute), and then you end up with the results of the fits: all the parameters. The best way to look at the non global parameters like \(A_1\) and \(A_\infty\) is to use the Show Parameters item from the Parameters menu. Using it and clicking on A_inf too should give you a display like this one: The A_inf parameter corresponds to the spectum at infinite time (of azide-bound heme), while the A_1 parameter corresponds to the difference spectrum between the initial (azide-free) and final (azide-bound) states. Now, the fit is finished, you can save the parameters if you want to reload them in a later fit by using the Parameters/Save menu item or export them in a form more suitable for plotting using Parameters/Export (although QSoas can also display and the parameters saved using Save). This concludes this first approach to fitting the data. What you can do is

• look at the depence of the tau_1 parameter as a function of the azide concentration;
• try fitting more than one exponential, using for instance:

  QSoas> mfit-exponential-decay /exponentials=2 flagged:kinetics
  

How to read the code above All the lines starting by QSoas> in the code areas above are meant to be typed into the QSoas command line (at the bottom of the window), and started by pressing enter at the end. You must remove the QSoas> bit. The other lines (when applicable) show you the response of QSoas, in the terminal just above the command-line. You may want to play with the QSoas tutorial to learn more about how to interact with QSoas. About QSoas QSoas is a powerful open source data analysis program that focuses on flexibility and powerful fitting capacities. It is released under the GNU General Public License. It is described in Fourmond, Anal. Chem., 2016, 88 (10), pp 5050 5052. Current version is 3.1. You can freely (and at no cost) download its source code or precompiled versions for MacOS and Windows there. Alternatively, you can clone from the GitHub repository.
Contact: find my email address there, or contact me on LinkedIn.

Focus This month I didn't have any particular focus. I just worked on issues in my info bubble.

Changes

• duck: add phrases indicating moved and inactive projects
• lintian: bump tag severity
• apt-listchanges: add missing import
• spelling dictionaries: codespell, lintian (1 2)
• Debian website: revert vertical space introduction
• Debian wiki service: update URL
• Debian screenshots: remove wxglade (Windows)
• Debian package uploads: ddccontrol
• Debian wiki pages: ath9k_htc/open_firmware, BCMHybridBTFirmware (1 2), BSP/2020/12/cn/Beijing, CategoryNotNative, DebianInstall, Derivatives/Census/Zevenet, FreedomBox/Manual/SecureShell, LowThresholdAdoption, LowThresholdNmu, MemberBenefits, Mobile, PortTemplate, QemuUserEmulation, RISC-V, Teams/DebianProFTPD, Teams/Dpkg/Spec/BundledBuildinfo, UpstreamGuide, Wine, XTaran/DistUpgradeWorkFlow
• FOSSjobs wiki pages: Resources
• open-ath9k-htc-firmware wiki pages: Troubleshooting-and-bug-reporting

Issues

• Crashes in gnome-shell-extension-hamster, libvdpau-va-gl
• Invasive signup process on SourceForge
• Missing upstream in webext-umatrix
• Features in lintian (1 2), webext-debianbuttons, cruft-ng, gparted, reportbug
• Regressions in evolution (1 2 3)
• Conffile handling in speech-dispatcher
• Misuse of /var in smartmontools
• Broken symlinks in gtk-doc-tools, plymouth-themes
• Cruft in qemu-user-static
• Typos in qml-module-org-kde-prison, libuhd4.0.0-dpdk-tests
• Broken apt sources in mariadb-10.5
• Code copies in ThermalMonitor
• New release needed for ddccontrol

Review

• Spam: reported 1 Debian bug reports and 144 Debian mailing list posts
• Debian packages: sponsored opentype-sanitiser, gtranscribe, open-ath9k-htc-firmware
• Debian wiki: RecentChanges for the month
• Debian screenshots:
  • approved fonts-jetbrains-mono geda-gschem gnome-maps gnome-shell-extension-dashtodock gnome-todo paper-icon-theme plan remmina sayonara sway wxglade
  • rejected ghostscript (wrong package), emacs-goodies-el (unrelated web browser), csv2latex (help output, bad quality), dwarf-fortress (non-free)
  • approved deletion of sdcc (another package)
  • rejected deletion of hashcat/olive-editor (spam)

Administration

• Debian: restart bacula director, ping some people about disk usage
• Debian wiki: unblock IP addresses, approve accounts, update email for accounts with bouncing email

Communication

• Respond to queries from Debian users and contributors on the mailing lists and IRC

Sponsors All work was done on a volunteer basis.

This is the first post of a series in which we will provide the readers with simple tutorial approaches to reproduce the data analysis of some of our published papers. All our data analysis is performed using QSoas. Today, we will show you how to analyze the experiments we used to characterize the behaviour of an enzyme, the Nickel-Iron CO dehydrogenase IV from Carboxytothermus hydrogenoformans. The experiments we analyze here are described in much more details in the original publication, Domnik et al, Angewandte Chemie, 2017. The only things you need to know for now are the following:

• the data is the evolution of the current over time given by the absorbed enzyme;
• at a given point, a certain amount of CO (50 M) is injected, and its concentration decreases exponentially over time;
• the enzyme has a Michaelis-Menten behaviour with respect to CO.

This means that we expect a response of the type: $$i(t) = \frac i_m 1 + \frac K_m [\mathrm CO ](t) $$ in which $$[\mathrm CO ](t) = \begin cases 0, & \text for t < t_0 \\ C_0 \exp \frac t_0 - t \tau , & \text for t\geq t_0 %> \end cases $$ To begin this tutorial, first download the files from the github repository (direct links: data, parameter file and ruby script). Start QSoas, go to the directory where you saved the files, load the data file, and remove spikes in the data using the following commands:

QSoas> cd
QSoas> l Km-CODH-IV.dat
QSoas> R

First fitThen, to fit the above equation to the data, the simplest is to take advantage of the time-dependent parameters features of QSoas. Run simply:

QSoas> fit-arb im/(1+km/s) /with=s:1,exp

This simply launches the fit interface to fit the exact equations above. The im/(1+km/s) is simply the translation of the Michaelis-Menten equation above, and the /with=s:1,exp specifies that s is the result of the sum of 1 exponential like for the definition of above. Then, load the Km-CODH-IV.params parameter files (using the "Parameters.../Load from file" action at the bottom, or the Ctrl+L keyboard shortcut). Your window should now look like this: To fit the data, just hit the "Fit" button ! (or Ctrl+F). Including an offset The fit is not bad, but not perfect. In particular, it is easy to see why: the current predicted by the fit goes to 0 at large times, but the actual current is below 0. We need therefore to include an offset to take this into consideration. Close the fit window, and re-run a fit, but now with this command:

QSoas> fit-arb im/(1+km/s)+io /with=s:1,exp

Notice the +io bit that corresponds to the addition of an offset current. Load again the base parameters, run the fit again... Your fit window show now look like: See how the offset current is now much better taken into account. Let's talk a bit more about the parameters:

• im is \(i_m\), the maximal current, around 120 nA (which matches the magnitude of the original current).
• io is the offset current, around -3nA.
• km is the \(K_m\), expressed in the same units as s_1, the first "injected" value of s (we used 50 because the injection is 50 M CO). That means the value of \(K_m\) determined by this fit is around 9 nM ! (but see below).
• s_t_1 is the time of the injection of CO (it was in the parameter files you loaded).
• Finally, s_tau_1 is the time constant of departure of CO, noted \(\tau\) in the equations above.

Taking into account mass-transport limitations However, the fit is still unsatisfactory: the predicted curve fails to reproduce the curvature at the beginning and at the end of the decrease. This is due to issues linked to mass-transport limitations, which are discussed in details in Merrouch et al, Electrochimica Acta, 2017. In short, what you need to do is to close the fit window again, load the transport.rb Ruby file that contains the definition of the itrpt function, and re-launch the fit window using:

QSoas> ruby-run transport.rb
QSoas> fit-arb itrprt(s,km,nFAm,nFAmu)+io /with=s:1,exp

Load again the parameter file... but this time you'll have to play a bit more with the starting parameters for QSoas to find the right values when you fit. Here are some tips:

• the curve predicted with the current parameters (use "Update" to update the display) should "look like" the data;
• apart from io, no parameter should be negative;
• there may be hints about the correct values in the papers...

A successful fit should look like this: Here you are ! I hope you enjoyed analyzing our data, and that it will help you analyze yours ! Feel free to comment and ask for clarifications.

About QSoasQSoas is a powerful open source data analysis program that focuses on flexibility and powerful fitting capacities. It is released under the GNU General Public License. It is described in Fourmond, Anal. Chem., 2016, 88 (10), pp 5050 5052. Current version is 2.2. You can download its source code or buy precompiled versions for MacOS and Windows there.

I installed Debian 9.0 Stretch on my Lenovo X201 laptop today. Installation went smooth, as usual. GnuPG/SSH with an OpenPGP smartcard I use a YubiKey NEO does not work out of the box with GNOME though. I wrote about how to fix OpenPGP smartcards under GNOME with Debian 8.0 Jessie earlier, and I thought I d do a similar blog post for Debian 9.0 Stretch . The situation is slightly different than before (e.g., GnuPG works better but SSH doesn t) so there is some progress. May I hope that Debian 10.0 Buster gets this right? Pointers to which package in Debian should have a bug report tracking this issue is welcome (or a pointer to an existing bug report). After first login, I attempt to use gpg --card-status to check if GnuPG can talk to the smartcard.

jas@latte:~$ gpg --card-status
gpg: error getting version from 'scdaemon': No SmartCard daemon
gpg: OpenPGP card not available: No SmartCard daemon
jas@latte:~$ 

This fails because scdaemon is not installed. Isn t a smartcard common enough so that this should be installed by default on a GNOME Desktop Debian installation? Anyway, install it as follows.

root@latte:~# apt-get install scdaemon

Then try again.

jas@latte:~$ gpg --card-status
gpg: selecting openpgp failed: No such device
gpg: OpenPGP card not available: No such device
jas@latte:~$ 

I believe scdaemon here attempts to use its internal CCID implementation, and I do not know why it does not work. At this point I often recall that want pcscd installed since I work with smartcards in general.

root@latte:~# apt-get install pcscd

Now gpg --card-status works!

jas@latte:~$ gpg --card-status
Reader ...........: Yubico Yubikey NEO CCID 00 00
Application ID ...: D2760001240102000006017403230000
Version ..........: 2.0
Manufacturer .....: Yubico
Serial number ....: 01740323
Name of cardholder: Simon Josefsson
Language prefs ...: sv
Sex ..............: male
URL of public key : https://josefsson.org/54265e8c.txt
Login data .......: jas
Signature PIN ....: not forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 8358
Signature key ....: 9941 5CE1 905D 0E55 A9F8  8026 860B 7FBB 32F8 119D
      created ....: 2014-06-22 19:19:04
Encryption key....: DC9F 9B7D 8831 692A A852  D95B 9535 162A 78EC D86B
      created ....: 2014-06-22 19:19:20
Authentication key: 2E08 856F 4B22 2148 A40A  3E45 AF66 08D7 36BA 8F9B
      created ....: 2014-06-22 19:19:41
General key info..: sub  rsa2048/860B7FBB32F8119D 2014-06-22 Simon Josefsson 
sec#  rsa3744/0664A76954265E8C  created: 2014-06-22  expires: 2017-09-04
ssb>  rsa2048/860B7FBB32F8119D  created: 2014-06-22  expires: 2017-09-04
                                card-no: 0006 01740323
ssb>  rsa2048/9535162A78ECD86B  created: 2014-06-22  expires: 2017-09-04
                                card-no: 0006 01740323
ssb>  rsa2048/AF6608D736BA8F9B  created: 2014-06-22  expires: 2017-09-04
                                card-no: 0006 01740323
jas@latte:~$ 

Using the key will not work though.

jas@latte:~$ echo foo gpg -a --sign
gpg: no default secret key: No secret key
gpg: signing failed: No secret key
jas@latte:~$ 

This is because the public key and the secret key stub are not available.

jas@latte:~$ gpg --list-keys
jas@latte:~$ gpg --list-secret-keys
jas@latte:~$ 

You need to import the key for this to work. I have some vague memory that gpg --card-status was supposed to do this, but I may be wrong.

jas@latte:~$ gpg --recv-keys 9AA9BDB11BB1B99A21285A330664A76954265E8C
gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or directory
gpg: connecting dirmngr at '/run/user/1000/gnupg/S.dirmngr' failed: No such file or directory
gpg: keyserver receive failed: No dirmngr
jas@latte:~$ 

Surprisingly, dirmngr is also not shipped by default so it has to be installed manually.

root@latte:~# apt-get install dirmngr

Below I proceed to trust the clouds to find my key.

jas@latte:~$ gpg --recv-keys 9AA9BDB11BB1B99A21285A330664A76954265E8C
gpg: key 0664A76954265E8C: public key "Simon Josefsson " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1
jas@latte:~$ 

Now the public key and the secret key stub are available locally.

jas@latte:~$ gpg --list-keys
/home/jas/.gnupg/pubring.kbx
----------------------------
pub   rsa3744 2014-06-22 [SC] [expires: 2017-09-04]
      9AA9BDB11BB1B99A21285A330664A76954265E8C
uid           [ unknown] Simon Josefsson 
uid           [ unknown] Simon Josefsson 
sub   rsa2048 2014-06-22 [S] [expires: 2017-09-04]
sub   rsa2048 2014-06-22 [E] [expires: 2017-09-04]
sub   rsa2048 2014-06-22 [A] [expires: 2017-09-04]
jas@latte:~$ gpg --list-secret-keys
/home/jas/.gnupg/pubring.kbx
----------------------------
sec#  rsa3744 2014-06-22 [SC] [expires: 2017-09-04]
      9AA9BDB11BB1B99A21285A330664A76954265E8C
uid           [ unknown] Simon Josefsson 
uid           [ unknown] Simon Josefsson 
ssb>  rsa2048 2014-06-22 [S] [expires: 2017-09-04]
ssb>  rsa2048 2014-06-22 [E] [expires: 2017-09-04]
ssb>  rsa2048 2014-06-22 [A] [expires: 2017-09-04]
jas@latte:~$ 

I am now able to sign data with the smartcard, yay!

jas@latte:~$ echo foo gpg -a --sign
-----BEGIN PGP MESSAGE-----
owGbwMvMwMHYxl2/2+iH4FzG01xJDJFu3+XT8vO5OhmNWRgYORhkxRRZZjrGPJwQ
yxe68keDGkwxKxNIJQMXpwBMRJGd/a98NMPJQt6jaoyO9yUVlmS7s7qm+Kjwr53G
uq9wQ+z+/kOdk9w4Q39+SMvc+mEV72kuH9WaW9bVqj80jN77hUbfTn5mffu2/aVL
h/IneTfaOQaukHij/P8A0//Phg/maWbONUjjySrl+a3tP8ll6/oeCd8g/aeTlH79
i0naanjW4bjv9wnvGuN+LPHLmhUc2zvZdyK3xttN/roHvsdX3f53yTAxeInvXZmd
x7W0/hVPX33Y4nT877T/ak4L057IBSavaPVcf4yhglVI8XuGgaTP666Wuslbliy4
5W5eLasbd33Xd/W0hTINznuz0kJ4r1bLHZW9fvjLduMPq5rS2co9tvW8nX9rhZ/D
zycu/QA=
=I8rt
-----END PGP MESSAGE-----
jas@latte:~$ 

Encrypting to myself will not work smoothly though.

jas@latte:~$ echo foo gpg -a --encrypt -r simon@josefsson.org
gpg: 9535162A78ECD86B: There is no assurance this key belongs to the named user
sub  rsa2048/9535162A78ECD86B 2014-06-22 Simon Josefsson 
 Primary key fingerprint: 9AA9 BDB1 1BB1 B99A 2128  5A33 0664 A769 5426 5E8C
      Subkey fingerprint: DC9F 9B7D 8831 692A A852  D95B 9535 162A 78EC D86B
It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N) 
gpg: signal Interrupt caught ... exiting
jas@latte:~$ 

The reason is that the newly imported key has unknown trust settings. I update the trust settings on my key to fix this, and encrypting now works without a prompt.

jas@latte:~$ gpg --edit-key 9AA9BDB11BB1B99A21285A330664A76954265E8C
gpg (GnuPG) 2.1.18; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub  rsa3744/0664A76954265E8C
     created: 2014-06-22  expires: 2017-09-04  usage: SC  
     trust: unknown       validity: unknown
ssb  rsa2048/860B7FBB32F8119D
     created: 2014-06-22  expires: 2017-09-04  usage: S   
     card-no: 0006 01740323
ssb  rsa2048/9535162A78ECD86B
     created: 2014-06-22  expires: 2017-09-04  usage: E   
     card-no: 0006 01740323
ssb  rsa2048/AF6608D736BA8F9B
     created: 2014-06-22  expires: 2017-09-04  usage: A   
     card-no: 0006 01740323
[ unknown] (1). Simon Josefsson 
[ unknown] (2)  Simon Josefsson 
gpg> trust
pub  rsa3744/0664A76954265E8C
     created: 2014-06-22  expires: 2017-09-04  usage: SC  
     trust: unknown       validity: unknown
ssb  rsa2048/860B7FBB32F8119D
     created: 2014-06-22  expires: 2017-09-04  usage: S   
     card-no: 0006 01740323
ssb  rsa2048/9535162A78ECD86B
     created: 2014-06-22  expires: 2017-09-04  usage: E   
     card-no: 0006 01740323
ssb  rsa2048/AF6608D736BA8F9B
     created: 2014-06-22  expires: 2017-09-04  usage: A   
     card-no: 0006 01740323
[ unknown] (1). Simon Josefsson 
[ unknown] (2)  Simon Josefsson 
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
pub  rsa3744/0664A76954265E8C
     created: 2014-06-22  expires: 2017-09-04  usage: SC  
     trust: ultimate      validity: unknown
ssb  rsa2048/860B7FBB32F8119D
     created: 2014-06-22  expires: 2017-09-04  usage: S   
     card-no: 0006 01740323
ssb  rsa2048/9535162A78ECD86B
     created: 2014-06-22  expires: 2017-09-04  usage: E   
     card-no: 0006 01740323
ssb  rsa2048/AF6608D736BA8F9B
     created: 2014-06-22  expires: 2017-09-04  usage: A   
     card-no: 0006 01740323
[ unknown] (1). Simon Josefsson 
[ unknown] (2)  Simon Josefsson 
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg> quit
jas@latte:~$ echo foo gpg -a --encrypt -r simon@josefsson.org
-----BEGIN PGP MESSAGE-----
hQEMA5U1Fip47NhrAQgArTvAykj/YRhWVuXb6nzeEigtlvKFSmGHmbNkJgF5+r1/
/hWENR72wsb1L0ROaLIjM3iIwNmyBURMiG+xV8ZE03VNbJdORW+S0fO6Ck4FaIj8
iL2/CXyp1obq1xCeYjdPf2nrz/P2Evu69s1K2/0i9y2KOK+0+u9fEGdAge8Gup6y
PWFDFkNj2YiVa383BqJ+kV51tfquw+T4y5MfVWBoHlhm46GgwjIxXiI+uBa655IM
EgwrONcZTbAWSV4/ShhR9ug9AzGIJgpu9x8k2i+yKcBsgAh/+d8v7joUaPRZlGIr
kim217hpA3/VLIFxTTkkm/BO1KWBlblxvVaL3RZDDNI5AVp0SASswqBqT3W5ew+K
nKdQ6UTMhEFe8xddsLjkI9+AzHfiuDCDxnxNgI1haI6obp9eeouGXUKG
=s6kt
-----END PGP MESSAGE-----
jas@latte:~$ 

So everything is fine, isn t it? Alas, not quite.

jas@latte:~$ ssh-add -L
The agent has no identities.
jas@latte:~$ 

Tracking this down, I now realize that GNOME s keyring is used for SSH but GnuPG s gpg-agent is used for GnuPG. GnuPG uses the environment variable GPG_AGENT_INFO to connect to an agent, and SSH uses the SSH_AUTH_SOCK environment variable to find its agent. The filenames used below leak the knowledge that gpg-agent is used for GnuPG but GNOME keyring is used for SSH.

jas@latte:~$ echo $GPG_AGENT_INFO 
/run/user/1000/gnupg/S.gpg-agent:0:1
jas@latte:~$ echo $SSH_AUTH_SOCK 
/run/user/1000/keyring/ssh
jas@latte:~$ 

Here the same recipe as in my previous blog post works. This time GNOME keyring only has to be disabled for SSH. Disabling GNOME keyring is not sufficient, you also need gpg-agent to start with enable-ssh-support. The simplest way to achieve that is to add a line in ~/.gnupg/gpg-agent.conf as follows. When you login, the script /etc/X11/Xsession.d/90gpg-agent will set the environment variables GPG_AGENT_INFO and SSH_AUTH_SOCK. The latter variable is only set if enable-ssh-support is mentioned in the gpg-agent configuration.

jas@latte:~$ mkdir ~/.config/autostart
jas@latte:~$ cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/
jas@latte:~$ echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-ssh.desktop 
jas@latte:~$ echo enable-ssh-support >> ~/.gnupg/gpg-agent.conf 
jas@latte:~$ 

Log out from GNOME and log in again. Now you should see ssh-add -L working.

jas@latte:~$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDFP+UOTZJ+OXydpmbKmdGOVoJJz8se7lMs139T+TNLryk3EEWF+GqbB4VgzxzrGjwAMSjeQkAMb7Sbn+VpbJf1JDPFBHoYJQmg6CX4kFRaGZT6DHbYjgia59WkdkEYTtB7KPkbFWleo/RZT2u3f8eTedrP7dhSX0azN0lDuu/wBrwedzSV+AiPr10rQaCTp1V8sKbhz5ryOXHQW0Gcps6JraRzMW+ooKFX3lPq0pZa7qL9F6sE4sDFvtOdbRJoZS1b88aZrENGx8KSrcMzARq9UBn1plsEG4/3BRv/BgHHaF+d97by52R0VVyIXpLlkdp1Uk4D9cQptgaH4UAyI1vr cardno:000601740323
jas@latte:~$ 

Topics for further discussion or research include 1) whether scdaemon, dirmngr and/or pcscd should be pre-installed on Debian desktop systems; 2) whether gpg --card-status should attempt to import the public key and secret key stub automatically; 3) why GNOME keyring is used by default for SSH rather than gpg-agent; 4) whether GNOME keyring should support smartcards, or if it is better to always use gpg-agent for GnuPG/SSH, 5) if something could/should be done to automatically infer the trust setting for a secret key. Enjoy!

I'm replacing my OTR key for XMPP because of heartbleed (see below). If the plain ASCII text below is mangled beyond verification, you can retrieve a copy of it from my web site that should be able to be verified.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
OTR Key Replacement for XMPP dkg@jabber.org
===========================================
Date: 2014-04-14
My main XMPP account is dkg@jabber.org.
I prefer OTR [0] conversations when using XMPP for private
discussions.
I was using irssi to connect to XMPP servers, and irssi relies on
OpenSSL for the TLS connections.  I was using it with versions of
OpenSSL that were vulnerable to the "Heartbleed" attack [1].  It's
possible that my OTR long-term secret key was leaked via this attack.
As a result, I'm changing my OTR key for this account.
The new, correct OTR fingerprint for the XMPP account at dkg@jabber.org is:
  F8953C5D 48ABABA2 F48EE99C D6550A78 A91EF63D
Thanks for taking the time to verify your peers' fingerprints.  Secure
communication is important not only to protect yourself, but also to
protect your friends, their friends and so on.
Happy Hacking,
  --dkg  (Daniel Kahn Gillmor)
Notes:
[0] OTR: https://otr.cypherpunks.ca/
[1] Heartbleed: http://heartbleed.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQJ8BAEBCgBmBQJTTBF+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcYwkQAKLzEnTV1lrK6YrhdvRnuYnh
Bh9Ad2ZY44RQmN+STMEnCJ4OWbn5qx/NrziNVUZN6JddrEvYUOxME6K0mGHdY2KR
yjLYudsBuSMZQ+5crZkE8rjBL8vDj8Dbn3mHyT8bAbB9cmASESeQMu96vni15ePd
2sB7iBofee9YAoiewI+xRvjo2aRX8nbFSykoIusgnYG2qwo2qPaBVOjmoBPB5YRI
PkN0/hAh11Ky0qQ/GUROytp/BMJXZx2rea2xHs0mplZLqJrX400u1Bawllgz3gfV
qQKKNc3st6iHf3F6p6Z0db9NRq+AJ24fTJNcQ+t07vMZHCWM+hTelofvDyBhqG/r
l8e4gdSh/zWTR/7TR3ZYLCiZzU0uYNd0rE3CcxDbnGTUS1ZxooykWBNIPJMl1DUE
zzcrQleLS5tna1b9la3rJWtFIATyO4dvUXXa9wU3c3+Wr60cSXbsK5OCct2KmiWY
fJme0bpM5m1j7B8QwLzKqy/+YgOOJ05QDVbBZwJn1B7rvUYmb968yLQUqO5Q87L4
GvPB1yY+2bLLF2oFMJJzFmhKuAflslRXyKcAhTmtKZY+hUpxoWuVa1qLU3bQCUSE
MlC4Hv6vaq14BEYLeopoSb7THsIcUdRjho+WEKPkryj6aVZM5WnIGIS/4QtYvWpk
3UsXFdVZGfE9rfCOLf0F
=BGa1
-----END PGP SIGNATURE-----

A recent discussion on debian-project remind me I have to do this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA256
Hello,
I am transitioning GPG keys from an old 1024-bit DSA key to a new
4096-bit RSA key.  The old key will continue to be valid for some
time, but I prefer all new correspondance to be encrypted in the new
key, and will be making all signatures going forward with the new key.
This transition document is signed with both keys to validate the
transition.
If you have signed my old key, I would appreciate signatures on my new
key as well, provided that your signing policy permits that without
reauthenticating me.
The old key, which I am transitional away from, is:
   pub   1024D/9057B5D3 2002-02-07
         Key fingerprint = 7AA1 9755 336C 6D0B 8757  E393 B0E1 98D7 9057 B5D3
The new key, to which I am transitioning, is:
   pub   4096R/31ED8AEF 2009-05-08
         Key fingerprint = DE8F 92CD 16FA 1E5B A16E  E95E D265 C085 31ED 8AEF
To fetch the full new key from a public key server using GnuPG, run:
  gpg --keyserver keys.gnupg.net --recv-key D265C08531ED8AEF
If you have already validated my old key, you can then validate that
the new key is signed by my old key:
  gpg --check-sigs D265C08531ED8AEF
If you then want to sign my new key, a simple and safe way to do that
is by using caff (shipped in Debian as part of the "signing-party"
package) as follows:
  caff D265C08531ED8AEF
Please contact me via e-mail at <vanicat@debian.org> if you have any
questions about this document or this transition.
  Remi vanicat
  vanicat@debian.org
  remi.vanicat@gmail.com
  remi.vanicat@ens-lyon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iD8DBQFST8iPsOGY15BXtdMRAggfAJ4z5wEpUy8Bcicv9KTGOjsUAZF2xACfYKv9
GWXh8iT1N2Qqjhwtpvx9B3aJAhUDBQFST8iP0mXAhTHtiu8BCPldEADYM9e/22yu
En8lcZ5UUI/eQ5jFgZaxTZ90ShS0vPD/Mgn6xyKoeigA0Bk4ltTjDXA7vEWXLjOK
gbGv3SvffPJIsR1WJmhYtVyNquJXXjyElEBsbxvCJ/awYdU9BFXPqtLlLVCObvSc
bE9xlJhoLdk3bDqSSTO3nqoDa0qgPnJvwKNYIMBrNavGyIW3QT0BRUCKyBssqh+u
P4x8VhpHiR2Ee4LHfRVeJk+5ncvSXYluAohOXka5AnV2GgFQoVYfFqxn2Gh3BMWC
sqf/NUPnFOCSRw++oNP3mBv3jn/jZuo8BcVOECKL+/dO6/3otgO6a/5tUspfnAJA
m/UxBdc2vs7LkZ0wUipIHg10x4154f+hZfx4WuCJ05X0dqcKeh4eJ0zFBvxMyh+A
o2TfifT9WJlyb+Hah/w1MFAXI8cAj5RvwdVgTzcodXpggtpBpdLDvv3G1KYFm/TG
Zev480N6bGrBb3JKgUtAMuTls8+FngYtYg9YKBiajEDM3MVC+H4MiOzVNKV++y/n
YW3z59Oc04ZMi9hV+uR3kwq8D7aUJmc0QFeOGmq7W9LOjvVO+lTf87l3jh2ahxx/
FgiinSZr1YzE+9OtNj8CTsmAmApIxsTJUCR6h554z+lyrTwc0pdeUwzSWqV84k7G
V6HBmTiw9IGs22+W15pRzq/mCVYdrYT7zQ==
=c5fJ
-----END PGP SIGNATURE-----

Here is the link to the .txt version for easier checking of signature.

Already chilled by Wheezy freeze? It s been a long ride since the release of Squeeze, and your beloved FTP Team tried to assist our tireless developers and contributors at its best. Here are some hot stats to give you a figure about what happened behind the scenes. Since the release of Squeeze, 7462 .changes files with NEW components were processed by dak, with an average of 14.660 NEW packages per day. On the FTP Team side, we had 6877 accepts (13.511 per day), 641 rejects (1.259 per day) and 280 comments to maintainers (0.550 per day). This table represents the activity by single team member:

Login	Accepts	Rejects	Comments
ansgar	407 accepts (0.800 per day)	71 rejects (0.139 per day)	53 comments (0.104 per day)
dak	12 accepts (0.024 per day)	1 rejects (0.002 per day)	0 comments (0.000 per day)
dktrkranz	4319 accepts (8.485 per day)	381 rejects (0.749 per day)	104 comments (0.204 per day)
joerg	100 accepts (0.196 per day)	12 rejects (0.024 per day)	1 comments (0.002 per day)
mhy	214 accepts (0.420 per day)	14 rejects (0.028 per day)	5 comments (0.010 per day)
stew	67 accepts (0.132 per day)	16 rejects (0.031 per day)	7 comments (0.014 per day)
tolimar	1480 accepts (2.908 per day)	93 rejects (0.183 per day)	84 comments (0.165 per day)
twerner	278 accepts (0.546 per day)	53 rejects (0.104 per day)	26 comments (0.051 per day)

---

Who were the most prolific maintainers who got a NEW processing? Here is our special top ten:

1. Debian Perl Group (559 accepts)
2. Debian Haskell Group (491 accepts)
3. Debian Ruby Extras Maintainers (285 accepts)
4. Debian Java Maintainers (257 accepts)
5. Debian Med Packaging Team (164 accepts)
6. Debian Multimedia Maintainers (160 accepts)
7. Debian Fonts Task Force (156 accepts)
8. Debian Javascript Maintainers (137 accepts)
9. Debian Python Modules Team (129 accepts)
10. Debian Qt/KDE Maintainers (98 accepts)

That doesn t reflect the real developers, though. Here s our Changed-By top ten:

1. Clint Adams (216 accepts)
2. Jonas Smedegaard (208 accepts)
3. Ben Hutchings (203 accepts)
4. Joachim Breitner (153 accepts)
5. TANIGUCHI Takaki (112 accepts)
6. Alessio Treglia (101 accepts)
7. David Paleino (95 accepts)
8. Nicholas Bamber (76 accepts)
9. Mathieu Parent (68 accepts)
10. Jeff Breidenbach (63 accepts)

Clint rocks with tons of Haskell packages, followed by Jonas (mostly Perl packages), and Ben (kernel uploads). Italian cabal stands still, with Alessio and David respectively at 6th and 7th place

---

How long does a package stay in NEW? Some more, some less, but the average is 3 days, 15 minutes and 21 seconds. Now go and check your dak mails to see whether you had a fast processing or not liblog4ada 1.2-1 surely had, as it was accepted after 30 seconds! gsoap 2.7.17-1 was not so lucky, it took 103 days, 8 hours, 20 minutes and 43 seconds to clear NEW, but then made its way to the archive. Better late than never

---

FTP Team is not just accepting NEW packages, but also removing obsolete ones. Here are some details about this task:

• Source packages removed: 2159
• Binaries for architecture all: 8773
• Binaries for architecture alpha: 3646
• Binaries for architecture amd64: 14653
• Binaries for architecture arm: 3
• Binaries for architecture armel: 13283
• Binaries for architecture armhf: 3423
• Binaries for architecture hppa: 1418
• Binaries for architecture hurd-i386: 6923
• Binaries for architecture i386: 15655
• Binaries for architecture ia64: 12365
• Binaries for architecture kfreebsd-amd64: 10972
• Binaries for architecture kfreebsd-i386: 10998
• Binaries for architecture mips: 12478
• Binaries for architecture mipsel: 12479
• Binaries for architecture powerpc: 13945
• Binaries for architecture s390: 12374
• Binaries for architecture s390x: 3884
• Binaries for architecture sparc: 12295

---

FTP Team also took care of override changes:

• Number of priority changes: 853
• Number of section changes: 975

Multiarch has been coming RSN for an extremely lengthy meaning of the word "soon". I remember watching Tollef give a presentation about it at DebConf4 and I'm pretty sure it's been talked about at every DebConf since then as well. Deemed the "correct" answer to the issue of running i386 binaries on x86_64 machines, or old ARM ABI programs on more modern hardware, it's always seemed to be at least another Debian release away. Not so anymore. Through foolishness I ended up buying a Brother HL3040CN when I first moved to the US. It was a cheap networked laser printer and it touted Linux support. Quality wise it's been fine. I don't use it a lot, but unlike an inkjet I don't have to worry about not using it for a month and then needing to print something in a hurry and having to clean print heads etc. Where it falls down is that I failed to check that "Linux support" involved source. No. Instead it involves an i386 binary (at least packaged as a .deb, but in a horrible fashion). Up until now I've mostly been printing from my laptop, so all the drivers are installed there. I've got some guests this week and they needed to print their boarding passes, so I decided it was time to make the house server act as a print server too. It's an AMD64 box and before now I haven't had any need to run i386 code on it, so when I installed the driver deb it failed to work. Normally I'd just install ia32-libs, but this time I decided to try multiarch. So I did:

# dpkg --add-architecture i386
# apt-get update
# apt-get install libc6:i386

and magically I was now able to run the printer driver binary. I know there's a lot more work still to be done (I need to check if I can ditch ia32-libs on my laptop which runs a few more i386 only apps), but this is pretty cool - thanks to all those involved in making it happen! Update: I tried to install all the multiarch bits required for Skype on my laptop but hit an issue with libqtgui4:i386 which ends up pulling in liblcms1:i386 which isn't yet multiarch enabled. There was already a bug, #637732 filed by vorlon, and mhy did the appropriate NMU a week ago, so it should hopefully hit testing in the next week. Thanks guys.

Here we are, still writing code, still doing 16hour days, still keeping the archive cronjobs disabled, still having fun. Yesterday we enabled the rsyncable option for all the gzip contents we are creating in our dists/ directory, which will lead to nice bandwidth savings during the mirror push. Initial tests showed a size increase of about 2 til 4 percent but the transferred amount of data going down to 1/8th for Packages files, 1/4th for Contents files. We also started implementing an ACL system in DAK which basically will allow the sane implementation of the already mentioned buildd autosigning, decrufting the code handling DMs and later on easily allowing the throw away binaries feature, while still allowing for exceptions, like bootstrapping a new architecture. The majority of it is there and already working, just a few edges still have to be smoothened. Yesterday evening we started the last major work for this meeting, in terms of coding. We will end up with a completly different way of handling the lifecycle of a package in the archive, before it enters the public viewable pool/ directory. To wrap our heads around the problem we had to write down how the archive works currently, which you can see in the first picture. And then we had to go and define how it should look in the future, for which you can look at the second picture. As all of us here love the simple clarity of this drawing we went and declared it the one and official ftpmaster documentation of our archive queues. :) As you might miss enough Milk/IceTea/Coffee/Drugs to understand what the fuck we smoked when drawing it, lets try a short explanation, starting with the old red version:

• Packages get in as usual, via our queue daemon, which copies them into unchecked/
• From there packages either go to NEW/BYHAND, get rejected, end up in a policy-queue (which is what you knew by (o-)p-u-new in the past, but more generally implemented) or get accepted and end up in accepted/. accepted/ is what you see behind incoming.debian.org.
• From NEW/BYHAND or a policy-queue packages either go to rejected, should they be unwanted for the archive, for whatever reason. Or into newstage if they are accepted. Newstage will simply end up in the accepted/ queue the next time we process files and is a neat way to avoid a class of race conditions we had in the past.
• From the accepted queue packages are usually installed into the pool/. This is the real acceptance into the archive, after this they are considered public. Very seldomly there is a problem doing this and then we end up with an automated unaccept of them, but an unaccept there is usually never done by hand.
• When a package is removed from the archive it will end up in the morgue. The same happens for files out of the reject queue.
• Every now and then we have a huge shellscript running which we refer to as dinstall, which is triggering the installation of files into the pool, is responsible for the Packages/Sources files creation, pushing the mirrors, etc.

This is how the archive worked for the last years now, and while it works it has a few drawbacks. For example, files do have to be processed multiple times before they end up in their final location, which is just unneccessary. It also opens us to a kind of race condition between the unchecked and accepted queue, leading to automated unaccepts. And it duplicates some code and also checks we have to run, wasting time and resources. Thats not all of it, but a good start. So the idea is to get rid of the extra queue and switch over to install files directly into the pool when processed from the unchecked queue. And that is what the third picture shows in green, the changed handling. As you see we completly lose the complexity around accepted by moving directly into pool. So, as usual, saying it in two sentences doesn t mean the actual implementation is easy, even if it will make future handling easier for us. Of course this hasn t been all we worked on today. We are 6 persons here, there is much more done than I can condense into those few blog posts. Especially as I want to do my own share of work (shut up mhy :) ), and not just blog around. So, to still keep you informed I included our official meeting minutes in this blog post. Picture 3 is your friend. :) (Ok ok, just joking, but it contains a good overview of our various discussion about the various projects we work on). We are currently running a script that is importing data about all known changes files the archive ever has seen (since about 2002), together with the most important data from them. While this allows only a small function for us in the archive (have we seen this file already? Reject upload) using it (prior it used to look for file existance in a subdir), it might allow other people to do creative things with it. We also added a new Release file to our mirrors. They are called InRelease and are the same as the Release file, but they are signed inline (cleartext signature). Using those files it can no longer happen that one downloads a Release file, the mirror updates and one downloads a different Release.gpg. This will help reducing problems experienced there, even if it is only the first step towards the final solution. For the final solution we have to do something about the Packages files related to the Release files to, and allow multiple versions of them to exist and then let the Release file tell for which of them they are. We probably will end up with the Packages/Sources files of the last 2 or 3 runs and the Release file mentioning them all, but that won t be done during this meeting. Oh, and as you have all be so patient with us during the last days of reduced archive service: Our current plan is to come back to a mostly normal service during Saturday, so we have the rest of Saturday and the few hours on Sunday which we are here to monitor what it is doing. Thats it for today, but you can sure expect a more detailed report send to d-d-a sometime next week.

And here, yet another Argentina post before I have to do some work again (like the Entrance Controller needs some love). This time with pictures! :) You can have pretty nice desserts in BA, as this picture with Mark on it proves. I think he will really love me for this post. Really. (It wasn’t actually his dessert :) ).

---

Anyways, this morning we took the opportunity walking over to see the Atlantic Ocean. Damn long way, proven by the next picture (the building marked with that arrow is our Hotel, us standing right beside the beach). Fun thing - Mark was walking outside with a T-Shirt only, while all those Argentinian people use winter clothes. Got him quite a bit of weird looks from all of them. :) Right now we are back, sitting in the first prepared hacklab. Yes, those grey things below the tables are for cabling, so there is a lot of power outlets, should be enough for everybody to get power, without doing long daisy chains. Comments: 1

Despite all those talks about the Lufthansa strikes my flight down to Argentina worked pretty well. We have been delayed by about 20 minutes, and the service on board was less than usual, but still enough to not get a cannibal during the flight. :) But looking at what I hear from various sources people with later flights might have a little more trouble. Hopefully not too many, like cancelled flights. Right now we (Mark ‘mhy’ Hymers, Stephen ‘sgran’ Gran and myself) are sitting at Martin ‘Tincho’ Ferraris place, where we stayed the last night. Current plan seems to be “Go to BA, look around the City a bit (after we found a place to store our luggage there), in the evening meet with local people, then take the night bus to Mar del Plata, so we arrive there on Wednesday”. Comments: 0

Finally I was able to open the registration for DebConf8 and send the Call for Papers. For the full details please read the whole mail. We had a lot of work in the last few weeks to make this possible, as we set us the goal “We will keep all data entered last year, people won’t have to enter that again”. And we made it! It wasn’t all that easy to do, as we switched from the old 0.2.10 version of Pentabarf to the more recent, completly rewritten 0.3.9 release of it. Which had a completly new database schema, making the database upgrade a fun task, having had a lot of changes for our own data… After Mark and Stephen finished the database it was my task to get all the changes to the interface back which we had done. Which took about a week longer than I expected it, unfortunately delaying the CfP about 4 days. But hey, the new code is way better now. The actual difference between us and plain upstream is about 30% of that with 0.2.10. Which is nice. Of course we still miss a few things, but those aren’t important for the CfP and will be readded soon. Some of those features also will be sent (and most possibly merged) upstream. A big thanks go to Mark (mhy) Hymers and Stephen (sgran) Gran who did the database upgrade (keeping all our own data in it!) and to upstream who did help me out multiple times to get this running. (Yes, this stuff is also the reason why NEW got that huge again. No worries, I will fix that this weekend, shouldn’t take more than one or two “NEW-sessions”).

Yesterday I bought a laptop for a friend, who also asked me to install Linux on it. Since she's not computer-savvy at all, I opted for an Ubuntu. I provide here a short description of the hardware and what to expect regarding compatibility for anyone about to buy one of these. Hardware description

Model	HP 530
Part No.	GU322AA
CPU	Intel(R) Core(TM) Duo CPU T2300 @ 1.66GHz (stepping 12) - 2 MiB cache
CPU flags	fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor est tm2 xtpr
Screen	330 mm x 250 mm viewable area, "glossy" wide-screen. 1280x800 pixels.
Video	Intel Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller
Audio	Intel 82801G (ICH7 Family) HDA
USB	Intel 82801G (ICH7 Family) USB2 EHCI Controller
Ethernet	Intel 82562ET/EZ/GT/GZ - PRO/100 VE (LOM) Ethernet Controller Mobile
WiFi	Intel Corporation PRO/Wireless 3945ABG Network Connection
Optical media	Optiarc DVD RW AD-7560A
Hard disk	Fujitsu MHY2120BH, 112GiB, max UDMA/100

Problems The only problems I had with the hardware were related to the sound card and the lid. The sound card had exactly the same problem as my Dell Inspiron 6400: it won't turn off the internal speakers when you plug something in the audio output jack. This is easily solved adding the following to /etc/modprobe.d/options: options snd-hda-intel enable=yes model=laptop The problem with the lid is that the screen didn't turn off when the lid closed. Just one time it did work, and stopped doing so after a reboot. Looking with acpi_listen, it seems that the acpi event isn't even generated. I don't know if this is a hardware or software problem. Also, some not very nice things should be noted about it: it has no independent media buttons for volume, suspend, etc.; only the WiFi transmitter kill and the power button, the rest needed a key chord. It has only two USB ports, which nowadays is incredibly few. No LEDs for hard dist, scroll lock or num lock. The audio jacks are on the front, which makes them very unsuitable for any straight plug. Although seldom used, it is nice to have the ability to turn the screen 180 , but this one can't do it. Finally, the battery is tiny: only four cells amounting 2 Ah of capacity. The power consumption seems a little better than my Dell: running on batteries, with low brightness, an idle GNOME desktop gave a reading of 820mA. Watching a movie from optical media in full screen ranged from 1 A to 1.3 A depending on the spinning of the media and the codec. Burning a DVD at 2x took 1.15 A The good After installing a Ubuntu 7.10, almost everything Just Worked . Of course it warned me about the non-free ipw3945 driver, but in seconds network-manager had connected to my home WLAN. Network manager could be a little more smart and turn off the WiFi transmitter when it's disabled by the user, but I guess that's not only an Ubuntu problem :). Most media keys worked out of the box, the WiFi kill switch worked OK, as did suspend to ram and to disk. Video acceleration and obligatory eye candy worked automatically. No problems either with burning a DVD, listening to music, watching a movie or connecting to my home network. The external aspect is not bad, the screen looks good, and the touch pad is very nice: just a matrix of dots over a surface that doesn't show any other sign of being an input method. In conclusion, it shows that it is a very cheap machine, but the drawbacks seem very few comparing to the good price. Tags: Planet Lugfi, Planet Debian, Tecnolog a

I just setup a DNS entry for panama.mini.debconf.org, on request of David Moreno Garza. He also got a mailing-list for that upcoming mini Debian Conference. Which reminded me to blog about debconf.org resources again, so that more people know/remember that there is something they can use whenever they organize a Debian meeting. If you happen to organize a meeting of Debian Developers / interested Debian people you can chose to use any debconf.org resource you need for it. This currently means:

DNS	a name within .debconf.org. Either pointing to your host, if you have one, or see below for hosting.
	Current style seems to be $something.mini.debconf.org, but we also have some miniconfX.debconf.org entries, so are pretty open. And in case it doesn’t fit into .debconf.org - there is always .debconf.net without restrictions (as its not really used currently).
Mailing-List	Want a mailing-list?
Hosting	Don’t have an own server for it? .debconf.org possibly has space for you.
	You would manage the content via a svn repository.
CMS	Conference Management System - AKA pentabarf. Available in future, more info on that point when we finally switched to a version that let’s us easily give access to other people without giving out all personal data. :)
Gallery	Use our gallery. Actually - don’t bother asking, just use it, as long as you use it for Debian related event pictures.

Want more? We have a page listing most of our resources, maybe you find something you need. Want something? Mail admins@debconf.org and describe what you want, most possibly we will make it happen. Or try to get one of us admins on IRC, you are looking for one of the nicks Ganneff, mhy, sgran, gwolf or h01ger. No, we do not bite … usually. :)

I’m now already 9 days in Edinburgh (started writing this at day 5 already :) ), and all of them have been days of “get up at 8h, breakfast, goto Teviot, work until 23h, go back to Hostel”, with some short breaks in Teviots Bar and for Lunch/Dinner. Sounds stressful but actually was (mostly) a lot of fun, preparing the network, setting up all the core servers together with two other admins while at the same time getting a lot of request to change various parts of our Conference Management System Pentabarf to fit some peoples need at various places. The airline managed to get me to EDI, together with a few other Debian people on Friday, 8th June, around noon, where Mark (mhy) Hymers did wait already, so I didn’t need to take a bus to get into the town. On the way to Teviot I also remembered some of the places from back when we did the Venue visit for the DC7 decision. But not many, of course one forgets a lot over the time. At least I was able to remember some food places, which is always a good sign. :) At Teviot we met with Stephen (sgran) Gran to (unsorted list) have some food, unload the car, think about the way to get our uplink to our server room, check into the hostel - and whatever else we did at that day. Next day, officially called Setup day, we started to get two cables from our server room to the place our uplink is - you can see them if you go to the left site of Teviot. (The other two got there a bit later). After that we started with the setup of the network, which is pretty nice this year. We have a lot of sponsored machines that are doing various tasks, a nice network layout involving a lot of vlans to seperate stuff and a lot of (good) crack. What, you dont want to listen to boring details? Ok, here they come: - The main machine is, again, called Homer. Connected with a 2Gbit link to our master switch. It does those little things noone needs, like firewall, local mirror, dns, nagios, routing between various nets we have here, the schedule bot, etc. - There is also a Marge, who is the central point for the whole wireless network, running chillispot to have authentication for it. - Barney is used as a storage server for the video team, having some 1.5TB (raid5) space for the video data. It has 2 additional disks, 500G each, to copy data on and get them home to a video team after the conference. - Our streaming master machine at DC7 is called Lisa, and does not more than streaming for all the local clients and sending the stream out to our streaming master somewhere in the internet which then relays it to our streaming servers kindly offered by a lot of admins all over the world. - We also have Bart and Maggie, which serve as public build boxes for the attendees, where Maggie even runs a distcc open to the whole local network. - You can add the same amount of servers to this list which all do various tasks for the video team. This stuff is all glued together by a set of managed switches building our core backbone, running a number of vlans to seperate the different network segments. Which actually works quite nicely, as even at the time some expert managed to plug a cable into the same switch twice (yay, loop) - the only affected network part was that where he was in. The rest of the conference didn’t even notice it - until all of the admins jumped out of the admin room at once, looking for that fuckup. :) Sounds like crack? Probably is, but is a nice setup all together, and it was fun to set it all up together with Mark and Stephen, the two main admins for this conference who designed most of the whole structure and are the ones that really know it. I already “volunteered” them for the next DebConf to help as admins and really hope they decide to do it. Later on during DebCamp we also had Peter (weasel) Palfrader joining the local admin team. His main work here is related to the video team by hosting the geodns setup for the streaming and by running a local nagios to check the things we need to check. This enabled us to simply tell everyone Use streams.video.debconf.org:8000 wherever you are and you will get to the right server for you. Explaining this in a short way basically goes as “a monitoring tool keeps track of which servers are up and only enables them to resolve. Our geodns server then replies with the right server IPs, depending on in which region of the world you are.”. Which means streams.video.debconf.org will resolve to the local streaming server lisa while you are here, at the same time resolve to a number (those that are up) servers in Europe if you are in Europe or to those in the US if you are there. Nice. (And while I’m already blogging - I do hate my laptops suspend, err - I mean non-suspend mode. Somehow it got worse in the last days, sometimes needing multiple minutes (like 10) to decide to suspend to disk, and the suspend-to-ram still wont work. I should really get someone here that knows this stuff having a look at it. :) ).

I’m now already 9 days in Edinburgh (started writing this at day 5 already :) ), and all of them have been days of “get up at 8h, breakfast, goto Teviot, work until 23h, go back to Hostel”, with some short breaks in Teviots Bar and for Lunch/Dinner. Sounds stressful but actually was (mostly) a lot of fun, preparing the network, setting up all the core servers together with two other admins while at the same time getting a lot of request to change various parts of our Conference Management System Pentabarf to fit some peoples need at various places. The airline managed to get me to EDI, together with a few other Debian people on Friday, 8th June, around noon, where Mark (mhy) Hymers did wait already, so I didn’t need to take a bus to get into the town. On the way to Teviot I also remembered some of the places from back when we did the Venue visit for the DC7 decision. But not many, of course one forgets a lot over the time. At least I was able to remember some food places, which is always a good sign. :) At Teviot we met with Stephen (sgran) Gran to (unsorted list) have some food, unload the car, think about the way to get our uplink to our server room, check into the hostel - and whatever else we did at that day. Next day, officially called Setup day, we started to get two cables from our server room to the place our uplink is - you can see them if you go to the left site of Teviot. (The other two got there a bit later). After that we started with the setup of the network, which is pretty nice this year. We have a lot of sponsored machines that are doing various tasks, a nice network layout involving a lot of vlans to seperate stuff and a lot of (good) crack. What, you dont want to listen to boring details? Ok, here they come: - The main machine is, again, called Homer. Connected with a 2Gbit link to our master switch. It does those little things noone needs, like firewall, local mirror, dns, nagios, routing between various nets we have here, the schedule bot, etc. - There is also a Marge, who is the central point for the whole wireless network, running chillispot to have authentication for it. - Barney is used as a storage server for the video team, having some 1.5TB (raid5) space for the video data. It has 2 additional disks, 500G each, to copy data on and get them home to a video team after the conference. - Our streaming master machine at DC7 is called Lisa, and does not more than streaming for all the local clients and sending the stream out to our streaming master somewhere in the internet which then relays it to our streaming servers kindly offered by a lot of admins all over the world. - We also have Bart and Maggie, which serve as public build boxes for the attendees, where Maggie even runs a distcc open to the whole local network. - You can add the same amount of servers to this list which all do various tasks for the video team. This stuff is all glued together by a set of managed switches building our core backbone, running a number of vlans to seperate the different network segments. Which actually works quite nicely, as even at the time some expert managed to plug a cable into the same switch twice (yay, loop) - the only affected network part was that where he was in. The rest of the conference didn’t even notice it - until all of the admins jumped out of the admin room at once, looking for that fuckup. :) Sounds like crack? Probably is, but is a nice setup all together, and it was fun to set it all up together with Mark and Stephen, the two main admins for this conference who designed most of the whole structure and are the ones that really know it. I already “volunteered” them for the next DebConf to help as admins and really hope they decide to do it. Later on during DebCamp we also had Peter (weasel) Palfrader joining the local admin team. His main work here is related to the video team by hosting the geodns setup for the streaming and by running a local nagios to check the things we need to check. This enabled us to simply tell everyone Use streams.video.debconf.org:8000 wherever you are and you will get to the right server for you. Explaining this in a short way basically goes as “a monitoring tool keeps track of which servers are up and only enables them to resolve. Our geodns server then replies with the right server IPs, depending on in which region of the world you are.”. Which means streams.video.debconf.org will resolve to the local streaming server lisa while you are here, at the same time resolve to a number (those that are up) servers in Europe if you are in Europe or to those in the US if you are there. Nice. (And while I’m already blogging - I do hate my laptops suspend, err - I mean non-suspend mode. Somehow it got worse in the last days, sometimes needing multiple minutes (like 10) to decide to suspend to disk, and the suspend-to-ram still wont work. I should really get someone here that knows this stuff having a look at it. :) ).

We the undersigned petition the Prime Minister to promote the use of Open Document Format within the UK government.

Government documents must be available for tens if not hundreds of years. Currently much electronic documentation is stored in proprietary formats, such as Microsoft's .doc format. In order to allow future generations access to these documents it is imperative that they be in a fully documented standard. Open Document Format (ISO/IEC 26300:2006) is now the international document standard and as such should be supported by the Government.

The Weston Mercury - News: Council chief probe costs 34k

This happened in North Somerset and I remember something similar happening in West Norfolk. When will councillors stop using expensive lawyers to defend themselves at the taxpayers' expense?

opensource - epetition response

Ambivalent reply from the PM's office.

Town and parish councils

Kewstoke is used as a case study, but the link goes nowhere now...

The Irascible Professor-commentary of the day 02-08-07. Movie star teachers.

I've given up watching hero-teacher films. It's really not like that. I guess the oppressive bureaucracy of state education, with pressure from executive teachers to fiddle the student numbers, wouldn't make a good film.

The Irascible Professor-commentary of the day 03-06-07. Why I hope mhy children won't become educators.

Don't let your children grow up to become salesm^Wteachers.

NO2ID:newsletter 66

"Saturday, 10th March - King's Lynn street stall to advertise forthcoming public meeting, from 10am. Volunteers needed! Contact kings.lynn@no2id.net or text/call James on 07778 966395."

Tories want to free (software) Whitehall

The shadow chancellor gets all over the BBC as a result of his party's latest conversion.

Neighbourhood Fix-It

Another better-than-local-councils system from MySociety.

Concerto for blunt instrument: Ode to the No Longer Active

"We held a place for you // But you were busy // You've been so busy lately."