Author: Jani

  • How to open another shell (on another virtual terminal/console) in recovery mode

    There might be a better/simpler way, but I just applied this Stack Exchange answer by wurtel (edited by Stéphane Chazelas):

    setsid sh -c 'exec /bin/bash /dev/tty2 >&0 2>&1'

  • Cannot switch TTY with Ctrl + Alt + F1…Fn (Ubuntu)

    Just copying what Lswest wrote more than two years ago: if your TTY switching is not working, and you have a custom ~/.Xmodmap, make sure your mappings for the function keys in it are as follows:

    keycode  67 = F1 F1 F1 F1 F1 F1 XF86Switch_VT_1
    keycode  68 = F2 F2 F2 F2 F2 F2 XF86Switch_VT_2
    keycode  69 = F3 F3 F3 F3 F3 F3 XF86Switch_VT_3
    keycode  70 = F4 F4 F4 F4 F4 F4 XF86Switch_VT_4
    keycode  71 = F5 F5 F5 F5 F5 F5 XF86Switch_VT_5
    keycode  72 = F6 F6 F6 F6 F6 F6 XF86Switch_VT_6
    keycode  73 = F7 F7 F7 F7 F7 F7 XF86Switch_VT_7
    keycode  74 = F8 F8 F8 F8 F8 F8 XF86Switch_VT_8
    keycode  75 = F9 F9 F9 F9 F9 F9 XF86Switch_VT_9

    (And, in case Ctrl + Alt + Backspace also doesn’t work:

    keycode  22 = BackSpace Terminate_Server BackSpace Terminate_Server BackSpace

    but you’ll also need to have it enabled in Keyboard Layout Options, under “Key sequence to kill the X server”.)

  • [warn] http status 400 (“Fingerprint is marked rejected”) response from dirserver – Please correct.

    This error has been flooding my tor log probably since April, but I only picked it up now after reading about how few relays there are listed in the directory prompted me to check that mine was working.

    The standard fix for this is prevalent already: you need to delete your old keys (because they were created with a vulnerable version of OpenSSL). However, I fell into an elementary trap by doing this:

    $ sudo rm -f /var/lib/tor/keys/secret*

    That reported no errors… because the -f causes rm to “ignore nonexistent files and arguments”, and since stuff under /var/lib/tor/keys/ is private property of debian-tor, Bash has cannot expand secret* to what is actually there.

    I thought my old keys were now gone, but when I restarted tor it kept nagging about the fingerprint. Kept me confused for a while.

    So you have to have an actual root prompt for deleting those old keys with a wildcard:

    $ sudo -i
    # service tor stop
    * Stopping tor daemon...
    * ...
    * ...                                                                                    [ OK ] 
    # rm -f /var/lib/tor/keys/*
    # service tor start
    # exit
  • Cyanogenmod 11 (based on 4.4 KitKat) for the Motorola Defy+, using Linux

    This is not a how-to, just notes I’m putting down for myself, post-op. That’s why I also make note of the version numbers I used, and it could be not all of the steps were/are necessary (haven’t tried streamlining the process yet), but this is somewhat how it worked out for me; YMMV.

    First, a listing of everything to download.

    1. sbf_flash
    2. The SBF (System Binary File) of your existing system
    3. Framaroot
    4. 2nd Init
    5. TWRP Recovery for the Defy(+)
    6. update_recovery.zip
    7. CM11
    8. Gapps

    Full notes:

    1. Get sbf_flash and the SBF (System Binary File) of your existing system. For me this was “Android 2.3.6 Blur_Version.45.0.2310.MB526.NordicsRetail.en.EU”, got it from Droid Developers. This is not strictly speaking necessary, but they will save your ass if and when you screw up and have no other means of reflashing the phone available anymore.
    2. Get Framaroot (1.9.1) and install it. It’s the first rooting app that actually worked for me, so naturally I also donated.
    3. Use Framaroot to root the device and install su on it.
    4. Get 2nd Init (2.3) and install it.
    5. Use the 2nd Init app to install 2nd Init recovery.
    6. Get TWRP Recovery for the Defy(+) (2.6.3.0), update_recovery.zip, CM11 (11-20140325-NIGHTLY-mb526.zip), fixed Gapps zip (kk4.4.2-minimal-no_wizard) and put them on the SD card.
    7. Shut down the phone, then boot it up and during boot, when the led flashes blue, press volume down. This gets you into custom recovery.
    8. Flash TWRP Recovery zip onto the phone. (Factory wipe? Reboot into recovery?)
    9. (Probably superfluous) Flash update_recovery.zip onto the phone (Reboot into recovery?).
    10. Flash CM11 onto the phone. (Wipe Dalvik & Data?)
    11. Boot into shiny new OS. Play around.
    12. (Optional) Reboot into recovery, flash Gapps onto the phone.
    13. (Optional) If you screw up, ungzip the sbf file, put the phone into bootloader mode (power off, then power on + volume up), hook it up with your computer via usb and do a `sudo sbf_flash ungzipped_sbf_file`. When it’s finished (takes a while), get to stock recovery (power + volume down to boot), do a factory reset, then start over from the beginning. (sbf_flash needs to be chmod +x.)
  • Owncloud Kapsin siilolle (ja kotona Ubuntu 12.04 -työpöydälle)

    Kapsin UKK:ssa on ohjeet Owncloud-asennukselle. Niiden pitäisi periaatteessa päivittyä joukkoistetusti, ja sikäli tämä ohje tässä vanhenee todennäköisesti huonommaksi hyvin pian, mutta tässä kuitenkin (jälkikäteen muistinvaraisesti kirjoittamani) räpsy (snapshot) ohjeista sellaisina, kuin ne minulle tänään toimivat.

    Palvelimen asennus
    1. Loin siilooni Owncloudia varten datahakemiston (voi olla, että Owncloud osaisi tehdä tämän itsekin):
      mkdir ~/siilo/owncloud-data
    2. Menin secure-www-hakemistooni, koska halusin käyttää Owncloudia https:n läpi: 
      cd ~/sites/$USER.kapsi.fi/secure-www
    3. Latasin Owncloudin asennuspaketin. Sen tulee olla tar-paketti, joka löytyy Owncloud.orgin asennussivulla “Tar or Zip file” -namiskasta avautuvasta dialogista (“Unix”-linkki): 
      wget 'http://download.owncloud.org/community/owncloud-6.0.1.tar.bz2'
    4. Purin asennuspaketin: 
      tar xvf owncloud-6.0.1.tar.bz2
    5. Nimesin paketista tulleen “owncloud”-hakemiston vähän lyhyemmän nimiseksi mv-käskyllä (kutsun sitä tässä ohjeessa $POLKU-muuttujanimellä).
    6. Poistin asennuspaketin.
    7. Avasin juuri nimeämäni hakemiston webselaimella: https://$USER.kapsi.fi/$POLKU
    8. Syötin uuden pääkäyttäjätunnuksen ja (vahvan!) salanan niille varattuihin kenttiin ja avasin niiden alla olevan “Advanced”-osion. Syötin data folder -kohtaan siiloon osoittavan polun, /siilo/users/$USER/owncloud-data
    9. Vaihdoin oletuksena olleen SQLite-tietokannan tilalle MySQL:n (lähinnä siksi, että olen tottunut käyttämään MySQL:n hallintapaneelia enkä niinkään SQLitea). Syötin MySQL-käyttäjätunnukseni, -salasanani, -tietokantani nimen ja tietokantapalvelimeksi db1.kapsi.fi:n.
    10. “Finish setup”
    11. Ensitöikseni Owncloudin hallintapaneelissa loin itselleni toisen, pääkäyttäjäoikeudettoman käyttäjätunnuksen. Androidin näppiksellä syöttämistä silmälläpitäen valitsin hieman pääkäyttäjää heikomman, helpommin kirjoitettavan salasanan (toki siltikin pitkän ja vahvan).
    12. Lisäsin secure-www-juurihakemistoni .htaccess-tiedoston alkuun seuraavat rivit:
      <Limit>
         Order allow,deny
         Allow from all
      </Limit>

      (Ilman tätä työpöytäsovelluksen synkkaus epäonnistui.)

    Työpöytäsovelluksen asennus
    1. Latasin OpenSuSEn Owncloud-pakettivaraston ohjeiden mukaan pakettivaraston avaimen ja asensin sen:
      wget http://download.opensuse.org/repositories/isv:ownCloud:desktop/xUbuntu_12.04/Release.key
      sudo apt-key add - < Release.key
    2. Lisäsin pakettivaraston paikallisiin luetteloihin:
      sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/xUbuntu_12.04/ /' >> /etc/apt/sources.list.d/owncloud-client.list"
      sudo apt-get update
    3. Asensin työpöytäsovelluksen:
      sudo apt-get install owncloud-client
    4. Käynnistin työpöytäsovelluksen (Unityn kojelaudalla hakusanaksi owncloud).
    5. Syötin palvelimeni osoitteen: https://$USER.kapsi.fi/$POLKU
    6. Syötin pääkäyttöoikeudettoman käyttäjätunnukseni ja salasanani.
    7. Valmista tuli.
    Android-sovelluksen asennus
    Latasin Owncloudin Androidille F-Droid-kaupasta, missä se on ilmainen. En ole vielä käyttänyt sovellusta laajemmin, mutta jos havaitsen sen hyväksi, poistan sen ja asennan sen jälkeen Play-kaupasta, missä tekijät saavat siitä pienen kannatusmaksun. Ainakin heti käynnistyksestä ja tunnuksia syöttäessä se vaikutti toimivan ihan asiallisesti.
  • Purge

    sudo apt-get --purge remove unity-scope-audacious unity-scope-calculator unity-scope-chromiumbookmarks unity-scope-clementine unity-scope-colourlovers unity-scope-devhelp unity-scope-firefoxbookmarks unity-scope-gdrive unity-scope-gmusicbrowser unity-scope-gourmet unity-scope-guayadeque unity-scope-manpages unity-scope-musicstores unity-scope-openclipart unity-scope-texdoc unity-scope-tomboy unity-scope-video-remote unity-scope-virtualbox unity-scope-yelp unity-scope-zotero unity-lens-friends unity-lens-music unity-lens-photos unity-lens-video

  • Cannot find method (class)(class)getRange(number,number) nor getRange(number,number,number,number)

    Instead of just

      var sheet = SpreadsheetApp.getActiveSpreadsheet();

    do this

      var spread = SpreadsheetApp.getActiveSpreadsheet();
      var sheet = spread.getSheets()[0];

    ’nuff said.

  • How to prevent xscreensaver from starting in Lubuntu (or more precisely, how to kill it right away)

    LXSession has system-wide configuration in /usr/share/lxsession/<Profile name>/ and optional per-user configuration in ~/.config/lxsession/<Profile Name>/. Unfortunately for autostart, according to documentation, “If both files are present, all the entries in both files will be executed.” This means there’s no clean way to prevent autostarting applications defined system-wide from starting per-user; you have to change the system-wide configuration or resort to hacks.

    Here’s one example.

    jani@kingugidora:~$ mkdir -p ~/.config/lxsession/Lubuntu
    jani@kingugidora:~$ mkdir -p ~/bin
    jani@kingugidora:~$ cat > ~/bin/kill-xscreensaver
    #!/bin/sh
    killall xscreensaver
    jani@kingugidora:~$ cat > ~/.config/lxsession/Lubuntu/autostart
    @/home/jani/bin/kill-xscreensaver

    For now the order seems to work, in that the user-defined autostart lines are ran after system-wide ones.

  • avconv: Overlay one video next to another (parallel)

    Dare I say this is somewhat unintuitive?

    $ avconv -y -i input_video_A.mp4 -vf 'movie=input_video_B.mp4[inputB] ; [in]pad=1280:0,[inputB] overlay=640:0[out]' -c:v libx264 output_video.mp4

    This overlays one 640×480 video next to another one of the same size. You can stick a setpts=PTS-STARTPTS in there (between pad=… and [inputB], separated by commas) to have the videos “begin in the same zero timestamp”, but what that means in practice I have yet to figure out.

    Note that this doesn’t do any audio mixing. AFAICT avconv currently in Precise can’t do mixing, but newer versions have the amix filter for it.

    Edit: Once you’ve done mixing elsewhere, you can bring the mix in too:

    $ avconv -y -i input_audio.wav -i input_video_A.mp4 -vf 'movie=input_video_B.mp4[inputB] ; [in]pad=1280:0,[inputB] overlay=640:0[out]' -c:v libx264 -c:a libfaac output_video.mp4

    Scaling goes after overlay:

    overlay=640:0,scale=640:240' -c:v libx264...

    Edit: Something crazier still: place one video below the other and turn the whole thing sideways before scaling down (plus make it phone-compatible by using mpeg4 instead of libx264).

    $ avconv -y -i input_audio.wav -i input_video_A.mp4 -vf 'movie=input_video_B.mp4[inputB] ; [in]pad=0:960,[inputB] overlay=0:480,transpose=2,scale=640:424' -c:v mpeg4 -c:a libfaac output_video.mp4
  • Shotwell from Yorba’s daily PPA depends on libgee 0.8.2

    Shotwell from Yorba’s daily builds PPA cyrrently depends on “libgee-0.8-2 (>=0.8.3) but it is not installable” on Precise. Fundamentally, this is caused by Yorba (by decision) moving to libgee 0.8 but not packaging a 0.8-series libgee to go along with daily builds of Shotwell.

    But libgee 0.8 for Precise is available from the Vala Team PPA, so enabling that PPA allows for the daily shotwell build to install once more.

    Additionally, I’m using the PPA downprioritizing trick so that rest of the Vala PPA contents don’t override stuff from official repositories.:

    jani@saegusa:~$ cat /etc/apt/preferences.d/valappa-unprefer 
    Package:  *
    Pin: release o=LP-PPA-vala-team
    Pin-Priority: 400