I'm trying to install Debian GNU/linux on my new ASUS G752VM-GC006T

So what I've discovered:

• It's F2 to have the bios, and in the last bios section, you can directly boot on any device.
• It boot on the netinst DVD
• netinst can't see the SSD disk
• the trackpad doesn't work
• after successful install, booting on the fresh install failed. I had to use the recovery tools to install nvidia non-free package to have debian successfully boot.
• I mostly use sid on my computer (mostly to test problem, and report them). It was a bad idea: Debian stopped to find its own disk. adding pci=nomsi to the kernel option fix this.

So I've a working linux. My problem are:

• I still can't see the SSD disk from linux
• I cannot easily dualboot:
  • linux can't see the SSD where windows is,
  • windows boot loader don't want to start Debian, because it doesn't want to,
  • at least, the bios can boot both of them, but there is no "pretty" menu
• the trackpad is not working.
• 0.5 To feel small today...

And the question is: where to report those bug.

First edit: rEFInd seem to find windows and Debian, thanks to blackcat77

A Git annex hook for Hubic

I've just finished the git annex hook I was writing. It create a special remote that will use Hubic as a storage for git annex's objects.

To use it, you will have to download it from github. It depend on

• ruby (the ruby debian package will do)
• mechanize (the ruby-mechanize debian package, you can also use gems)
• dbus (the ruby-dbus package)

To use it, you first need to initialize your account.

You need an hubic account, but also a client_id and client_secret, that you can generate in My account then Developer. For my hook to work, you need to use http://localhost:4090/ as the Redirect URI (Domaine de redirection in french)

Credential will be stored in dbus's org.freedesktop.secrets service, both gnome and kde will give you one. So run hubic-git-annex-hook --init, it will ask for your hubic username, password, your client id and your client secret that you just generate, and store them in the org.freedesktop.secrets service.

Then configure git-annex to use it :

git config annex.hubic-hook /full/path/to/hubic-git-annex-hook $HUBIC_USERNAME $CONTAINER

the CONTAINER is openstack concept, that contain the files. Hubic use the container default for its synchronization application, you should probably use another. If the CONTAINER do not exist, the hook will create it.

You finally need to create the special remote :

git annex initremote hubic type=hook hooktype=hubic encryption=none

(you could chose any other name than hubic), you can then git annex copy --to=hubic

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.

The debconf BoF about gitify all things make we to want to report some of my git-annex use cases.

The problem

Calibre is a ebook manager that is available in debian. I use it to maintain my library, but also to dowload every day an epub version of a French newspaper and then put it on my kobo.

Configuring git annex for this

I wanted to use git-annex, so

    $ git init
    $ git annex init "some useful name"

But I don't want every thing in annex, because Calibre use some text file to save some metadata, so I used:

    $ git config annex.largefiles "include=* exclude=*.opf exclude=*.json"

then lets add everything

    $ git annex add *
    $ git add *
    $ git commit -m "first commit"

Calibre need read and write access on the its database, so let unlock it:

    $ git annex unlock metadata.db

On my other computer I only need to do

    $ git clone $user@$host:Calibre\ library
    $ cd Calibre\ library
    $ git annex init "another useful name"
    $ git annex get .
    $ git annex unlock metadata.db

The problem is that every time you will git annex sync, git annex will lock again the metadata.db, so lets unlock it automatically. I use git hooks, in .git/hooks/post-commit I have

    #!/bin/bash

    git annex edit metadata.db

don't forget to make this file executable

    $ chmod a+x .git/hooks/post-commit

Day to day operation

    $ git annex add .

Will put new file into the annex

    $ git add .

Will take care of the files that should no go into annex

    $ git annex sync

Will make the repositories exchange informations about all this, and make remote change local

    $ git annex get .

Will make remote book locally available

Merge conflict

You should not run calibre on the two computer simultaneously, or without syncing before it. If you do, you will have a conflict that git-annex will automatically solve by rename both of the file.

You can then either:

• Choose one. If no books have been changed or added on one of the computer, to use the other metadata.db will not make you loose any information
• rebuild it. calibredb restore_database won't do it, but will tell you how to do it.

Checking the library

You can use calibredb check_library to check you library is correct. If you use git for it, it will always tell you that it is not correct: there is this author ".git" it doesn't know about. Just don't care about it.

Maybe this can be solved by using vcsh but apparently vcsh+git annex it not well tested yet.

Automatic stuff

I use mr to automatically run all this, but some config could be done (I believe) to have git annex copy --auto do what it should.

There are also the git annex assistant for this kind of automatic synchronizations of contents, but I don't know if my automatic unlocking of one file will break this.

It might be interesting to find someway to unlock and lock the library only when running calibre, a simple script to launch calibre will do that. Note that each time you will lock and unlock, you will have a new commit in git.

The same In full resolution

I'm going to debconf13. After been in debian for quite a long time, I finally will see in person some of those mail address I see for so long.

Xorg and special keys: one solution for keycode>255

An historic

I've buy an IR receiver, and an universal controller to control my multimedia computer, my TV, my ADSL box and my 2.1 Home cinema.

I've been pleased to see that my universal controller do now more control than the remote that was sold with my IR receiver. But a lot of those control didn't work with Xorg, so I had to find someway to use them.

At first, my logs where spamed with line like:

imon 4-4:1.0: imon_incoming_packet: unknown keypress, code 0x100000e

(imon is the real builder of the IR receiver).

I looked for this on the internet and found

• the problem was known
• the fix was in the Linus kernel git repository
• but not in any released kernel

So I waited, and Linux 3.10 was released, and the Debian Kernel Team did include it in debian sid, so I could easily use it.

But some command was still unrecognized as key by Xorg, so I had to find how to let X know them.

Reading documentation on internet, and trying some command lead nowhere: the kernel did in fact understood very well the command, but X did ignore them. After two day of trying to understood XKB, I found this bug: those key was unavailable to X and XKB because their keycode was bigger than 255.

The first solution to this problem is this patch, but I prefer to use standard tool. I finally found that udev can remap key, hence my solution:

The Solution

To use key that have keycode bigger than 255, you need to have keycode smaller than 255. keycode are determined by a map in the kernel, that udev can set when the receiver is plugged.

You need a keymap. input-kbd from the input-utils package will list the available scancode, and their current keycode (to know the number of your input device, use lsinput):

% sudo input-kbd 6
0x100007f = 106  # KEY_RIGHT
0x1000080 = 105  # KEY_LEFT
0x1007f00 = 108  # KEY_DOWN
0x1008000 = 103  # KEY_UP
0x1010000 = 272  # BTN_LEFT
0x1010080 = 272  # BTN_LEFT
0x1020000 = 273  # BTN_RIGHT
0x1020080 = 273  # BTN_RIGHT
0x200001e = 513  # KEY_NUMERIC_1
0x200001f = 514  # KEY_NUMERIC_2

(There is more, I just cut it there).

Putting this in some file (say keymap), editing it, and running sudo input-kbd -f keymap 6 should change the kernel mapping. But it don't.

It's not a problem, because the best solution is to use udev.

Wrote a keyboard mapping in say /etc/udev/imon:

0x200001e  KP1
0x200001f  KP2
0x2000020  KP3
0x2000021  KP4
0x2000022  KP5
0x2000023  KP6
0x2000024  KP7
0x2000025  KP8
0x2000026  KP9
0x2000027  KP0
0x2800000  MENU
0x288795b7 PAGEDOWN
0x289395b7 PAGEUP

• You don't need to put there the scancode and keycode you don't divert,
• the interesting scancode are found by input-kbd
• you can also use input-events to find which scancode correspond to one key
• the interesting keycode are in /usr/include/linux/input.h, note that this is not the same thing than X keycode...

You then need to tell udev to load this mapping, with /etc/udev/rules.d/96-local-keymap.rules:

ACTION=="remove", GOTO="mykeyboard_end"
KERNEL!="event*", GOTO="mykeyboard_end"
ENV{ID_INPUT_KEY}=="", GOTO="mykeyboard_end"
SUBSYSTEMS=="bluetooth", GOTO="mykeyboard_end"

SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"

ENV{ID_VENDOR}=="15c2", ENV{ID_MODEL_ID}=="0042", RUN+="keymap $name /etc/udev/imon"

LABEL="mykeyboard_end"

You will need to adapt 15c2 and 0042 to you own remote. I've found those using lsusb

Bus 004 Device 014: ID 15c2:0042 SoundGraph Inc.

I could now use xkb to further refine the way those key are used by xorg...

I've just buy a new printer/scanner, and as the documentation found on the web on how to setup the printer falsely instruct me to download some third-party driver, I will explain here how to set it up:

• for the printing part, plug the printer, ask cups to look for new printer, and add it to cups. It just work.

• for the scanner, it doesn't work as easily. After having installed xsane, go to /etc/sane.d/xerox_mfp.conf, and add:

   # Samsung SCX-3400
   usb 0x04e8 0x344f
    

  somewhere in the file.

  then copy /lib/udev/rules.d/60-libsane.rules to /etc/udev/rules.d/60-libsane.rules, and add:

   # Samsung SCX-3400
   ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="344f", ENV{libsane_matched}="yes"
    

  You don't need to download samsung unified Linux driver for it to work.

By the way, Dear lazy web, I was wondering. In gimp, when I ask it to create a new image using Xsane, the menu give me the choice between the "Device Dialog" or my webcam. Is there any way to have my scanner there?

I've a weird bug on Debian unstable.

Some time, in some apps, text is unreadable. Look at this for example:

[[!img Error: Image::Magick is not installed]]

This will go away by itself, some time right away, some time after a forced redraw. What is weird is that all apps are not concerned: affected application are:

• gnome-terminal
• iceweasel
• the awesome wm

immune application are:

• Emacs (thanks to the church of Emacs)
• Calibre and its ebook-reader
• xterm? (I didn't test it for so long as other apps, but it seem to not be affected)
• gedit (I once believe that the problem was somewhat gnome related, but if gedit is unaffected, this is not anymore gnome related, that said I didn't test it a lot too)

I don't even know where to report my bug...

Thanks to Bruce Schneier security blog, I come across an interesting article about liability and software. The problem is well known

• if you impose liability on any software producer, then it's a dead sentence for free software
• but the current situation enable software dealer to sell faulty software with I can't audit, with liability for them if their software fail on a large scale.

Of course for better security, the solution could be to not use proprietary software, still a law as proposed on ACM could be useful to protect madam Michu.