debian repository for TWiki

I’ve set up a debian repository that you can help test the release package before it gets uploaded into debian proper.

To try it out, add the following to your /etc/apt/sources.list
deb experimental main contrib
deb-src experimental main contrib

and then run

gpg --keyserver --recv-keys 3C0C33BB442B5BE9
apt-key add /root/.gnupg/pubring.gpg
apt-get update
apt-get install apache2 twiki

I will be putting my ongoing work into the experimental distribution there, until they are ready for general use from my stable. From there I’ll be pushing them to my debian mentors.

This repository contains about 226 twiki-plugins – autoupdated nightly direct from THe packages have as many dependencies as I was able to coerce my build scripts to work out – but there is more work needed.

This article shows how simple it is to manage your own debian repository. The hard thing is making usable packages.

Sorry, you will get a gpg error on these packages, they are updated nightly direct from – and signing the repository requires personal intervention (as far as I can see).

Author: Sven Dowideit

You might remember me from tools like,,, Docker documentation, or

16 thoughts on “debian repository for TWiki”

  1. Here’s the issues that I’ve encountered so far:

    Issue 1.

    I’ve done the gpg and apt-key steps, but regardless, all the twiki packages still show up with a warning that they are from an untrusted source.
    An ‘apt-key list’ command shows your keys:

    pub 1024D/442B5BE9 2003-01-17
    uid Sven Dowideit
    uid Sven Dowideit (Sven Dowideit)
    uid Sven Dowideit
    uid Sven Dowideit
    uid Sven Dowideit
    uid Sven Dowideit
    sub 2048g/06966C47 2003-01-17

    So I have no idea why it’s not working.

    Issue 2.

    After upgrading the twiki package to v4.2.0 and then again to v4.2.1 each time in the Configuration web page in the ‘@INC library path’ section there is an error about DEPENDENCIES (sorry I don’t have the exact text of it anymore).
    To fix it, I’ve had to run the following commands:
    cd /usr/share/perl5
    ln -s ../twiki/DEPENDENCIES

    What is the correct fix for this? Because I’m guessing next time I upgrade twiki I’ll have to do it again.

    Issue 3.

    After a twiki upgrade most of it is broken (well from 4.1.2 to 4.2.0 it was anyway).
    To fix I need to do:

    cd /
    tar xzf twiki-data.tar.gz
    tar xzf twiki-pub.tar.gz

    To unpack new files for the TWiki.
    I’m not 100% sure if that is safe or not, but it seems to work.
    Is this the correct method?

  2. Ah I’ve done more research into Issue 1.
    It seems that for this to stop you’ll need to sign the Release file and put the signature in a Release.gpg file which apt-get/aptitude will automatically download.
    The approach is described in
    Section 7.4.4 of the following web page shows how to generate the Release.gpg file.
    But in a nutshell, after generating the Release file run the following command to create the Release.gpg file:
    gpg –sign -ba Release.gpg Release

    PS: Thanks for generating these TWiki packages for Debian.
    It makes life much easier than dealing with the source distribution.

    Another question… Are these packages planned to go to the official Debian repository one day?
    Or will this always be an external repository?

  3. oooer Jim, thanks for the feedback and issue reports! gpg key – aha, I did it once a while back, but over the year, something has gone wrong – I’ll read the links you gave me and re-run it (I hope it does not need to be run more than once, this repository is added to form a cron job while I’m sleeping 🙂 ) later: looks like it works, thanks!

    for future reference, the command I used was :find . -name Release -exec gpg -abs -o '{}'.gpg '{}' ;

    issue 2 – cool, should be an easy fix next update.
    issue 3 – yeah, upgrading topics has been scaring me for years – I wrote a topic upgrader years ago, but that was abandoned as unmaintained a few releases later. un-taring the new version of the topics and attachements will work, except it will lose you… your Main.TWikiAdminGroup and Main.TWikiPreferences topic changes.

    The TWiki 4.2.x package is the one that will eventually go into debian proper (ie, its hand built), whereas the plugins are build from a bruitish script – I’m not sure that they will ever get to debian acceptable standard, but if they do, yep.

  4. I’m something of a newb when it comes to this stuff, but after following the directions above; I’m still getting these errors:

    W: GPG error: experimental Release: The following signatures were invalid: BADSIG 3C0C33BB442B5BE9 Sven Dowideit
    W: Failed to fetch Unable to find expected entry main/binary-amd64/Packages in Meta-index file (malformed Release file?)

    I’ve read through the comments and the link to SecureApt, but I’m still coming up short. Any advice would be appreciated.

    So, I

  5. To further clarify, I did these two steps:

    gpg –keyserver –recv-keys 3C0C33BB442B5BE9
    apt-key add /root/.gnupg/pubring.gpg

    Which didn’t work. So, I followed the advice at Jim Barber’s post:

    gpg –sign -ba Release.gpg Release

    Which returns this error:

    gpg: no default secret key: secret key not available
    gpg: signing failed: secret key not available

    And with only the stable repos added, I’m stuck at this error after #sudo apt-get update

    W: GPG error: stable Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 3C0C33BB442B5BE9
    W: You may want to run apt-get update to correct these problems

    The previous error was on an amd64 system, and there obviously aren’t any 64 bit binaries, so I’m on a 32 bit system now with one less error message.

  6. Sorry guys, It turns out that because I rebuild the packages from every night while I sleep, and automatically add them to the debian repository, the signing thing isn’t going to work out in the short term – it requires me to type in my passkey – and so isn’t suitable for unattended use.

    wrt amd64 – thats a bit weird, as they are built on an amd64 machine, and I thought they were noarch. toss another stick on my todos :/

  7. Somecallmecheif.

    The gpgp instructions are for Sven to sign the Releases file with.
    It is up to the repository maintainer to do this, not the end user.
    All the end user needs to do is import the key using apt-key so that they trust the signatures.


    The passphrase thing is a pain. 🙁
    I had a quick hunt around but didn’t find any brilliant answers.
    Here are some dodgy ways that you could perhaps automate the passphrase entry but you’d want to really lock down the scripts and/or files (and/or system) involved. Storing your passphrase on the computer isn’t the best idea… But here we go anyway:

    1. Pass in the passphrase on stdin (file descriptor 0):

      echo “passphrase” | gpg –passphrase-fd 0 –sign -ba Release.gpg Release

    2. Store the passphrase in a file only readable by the user doing the signing and use that:

      gpg –passphrase-file /path/to/passphrase_file –sign -ba Release.gpg Release

    3. Pass the passphrase in as a command line parameter:

      gpg –passphrase passphrase –sign -ba Release.gpg Release

    4. Another possible option is to install and configure gnupg-agent and then use the –use-agent command line option of gpg when signing. But I’m not sure if you can get the gnupg-agent to indefinitely cache your passphrase or not, so it might not be a good option.

    I’m not sure if anyone else knows a better approach?

    Also I have a question.
    Do we still use:

    deb blah…

    Or should we convert over to the following?:

    deb blah…

  8. gosh I hope there is a better option – I’ll play with –use-agent some time.

    mind you – there is also the real security concern that any packages that are automatically built should be considered more suspect than a set that have had some ‘intentional’ work done on them – so there might be the other option – make a unsafe_may_burn@your gpg keyset with no passphrase and use that?

    wrt vs, doesn’t really matter for now – I’m likely to keep both because lots of my contributions out in the wild will have the ‘omg thats long’ domain on them.

  9. I’ve started a fresh new install using the repository as it stands now.
    I’ve noticed the following issues:

    Issue 1.

    Upon running the ‘configure’ script for the first time there are three warnings:

    Warning 1:

    In the “General Path Settings” section under the “WorkingDir” setting there is the following warning:

    Warning: You have an existing {RCS}{WorkAreaDir} (/tmp/twiki), so I have copied the contents of that directory into the new /var/lib/twiki/working/work_areas. You should delete the old /tmp/twiki when you are happy with the upgrade.

    It seems to be that in the /etc/twiki/LocalSite.cfg file, the default value for $TWiki::cfg{WorkingDir} is ‘/tmp/twiki’. But this has been changed to ‘/var/lib/twiki/working’ (which is fine). However there are also the variables $TWiki::cfg{RCS}{WorkAreaDir} and $TWiki::cfg{TempfileDir} that are still set to ‘/tmp/twiki’. Maybe these should be set to the following instead?

    $TWiki::cfg{RCS}{WorkAreaDir} = ‘/var/lib/twiki/working/work_areas’;
    $TWiki::cfg{TempfileDir} = ‘/var/lib/twiki/working/tmp’;

    Does that look right?

    Warning 2:

    Under the “Security setup” section under the “SafeEnvPath” setting I get the following warning:

    Warning: You should set a value for this path if there is any risk at all of your site being hacked.

    I’m not sure if the SafeEnvPath setting should be left blank or not? Maybe we should have something like the following?:

    $TWiki::cfg{SafeEnvPath} = ‘/usr/bin:/bin’;

    Warning 3:

    Under the “Mail and Proxies” section under the “WebMasterEmail” I get the following warning:

    Warning: Please make sure you enter the e-mail address of the webmaster. This is required for registration to work.

    The WebMasterEmail is blank, even though at install time I was asked to enter a value for this via debconf. Should the $TWiki::cfg{WebMasterEmail} variable be defined in the LocalSite.cfg file and set to what you specified at install time?

    Issue 2.

    When I go to save the changes in the configure script, I need to set a password first.

    It could be fine as it is…
    But should the $TWiki::cfg{Password} be set in the LocalSite.cfg file and set to the same password that you defined for the administrative user as asked by debconf?

    That’s it for now.

  10. Actually no it’s not.

    Issue 3:

    Upon saving the configuration screen it reports that the LoginManager has changed.
    The default setting as supplied is:

    $TWiki::cfg{LoginManager} = ‘TWiki::Client::ApacheLogin’;

    After the save it becomes:

    $TWiki::cfg{LoginManager} = ‘TWiki::LoginManager::ApacheLogin’;

    These appear to be the same thing, and the first one isn’t a choice in the drop down list in the configuration page. So I guess this variable should be changed in the default file that is supplied.

  11. Sven – can you update this page to show what we are supposed to do to import the key?

    Anyhow, according to

    If you just want to declare a repository as trusted just run:

    gpg –recv-key KEY_ID && gpg -a –export KEY_ID | apt-key add –

    where KEY_ID is a string after NO_PUBKEY.


    gpg –recv-key 3C0C33BB442B5BE9 && gpg -a –export 3C0C33BB442B5BE9 | apt-key add –

  12. So, that was all a waste of time…

    Use the experimental one. The main one is out of date and broken wrt amd-64.

    No workarounds needed for experimental.

    Except, perhaps, this is likely to be a nightly build. If so, its no use to users wanting a stable released version.

Leave a Reply