Why the software is crap

[Jay Sulzberger]

On Fri, 14 Nov 2014, NdK <ndk.clanbo at gmail.com> wrote:

> Il 14/11/2014 13:24, david at gbenet.com ha scritto:
>
>> I have cooled. You can export your private key - you can export your public 
> key. You can
>> import your private key you can import your public key. In 20 years I have 
> always had the
>> same problem - the same error message and have each time created a new set 
> of keys. I have
>> done this 4 times.
> If all four times you did the same wrong thing, then it's obvious that 
> you got the same wrong result.
>
> Just to prove it's your error, I copied my .gnupg from one system 
> (str957-142) to another (str957-004), with the most basic method I ould 
> think of. I'm not an expert (probably I transferred more than what was 
> needed!), but as you can see I succeeded at the first try!
>
> diego at str957-142:~$ gpg --list-secret-keys
> /home/diego/.gnupg/secring.gpg
> ------------------------------------------------
> sec   2048R/F9B9D307 2014-11-14
> uid                  Diego <test at example.com>
> ssb   2048R/3A4AD1C0 2014-11-14
>
> diego at str957-142:~$ tar cvfz GnuPG-backup.tar.gz --exclude random_seed 
> .gnupg
> diego at str957-142:~$ gpg --clearsign GnuPG-backup.tar.gz
>
> È necessaria una passphrase per sbloccare la chiave segreta
> dell'utente: "Diego <test at example.com>"
> 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14
>
> diego at str957-142:~$ ls GnuPG-backup.tar.gz*
> GnuPG-backup.tar.gz  GnuPG-backup.tar.gz.asc
> diego at str957-142:~$ scp GnuPG-backup.tar.gz diego at str957-004:/home/diego
>
> Then on the other PC:
>
> diego at str957-004:~$ tar xvfz GnuPG-backup.tar.gz
> .gnupg/
> .gnupg/gpg-agent-info
> .gnupg/pubring.kbx
> .gnupg/gpg.conf
> .gnupg/private-keys-v1.d/
> .gnupg/reader_0.status
> .gnupg/pubring.gpg~
> .gnupg/secring.gpg
> .gnupg/scdaemon.conf
> .gnupg/gpa.conf
> .gnupg/trustdb.gpg
> .gnupg/pubring.gpg
> diego at str957-004:~$ gpg --clearsign GnuPG-backup.tar.gz
>
> È necessaria una passphrase per sbloccare la chiave segreta
> dell'utente: "Diego <test at example.com>"
> 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14
>
> diego at str957-004:~$ gpg --verify GnuPG-backup.tar.gz.asc
> gpg: Firma eseguita in data ven 14 nov 2014 14:07:57 CET usando RSA, ID 
> chiave F9B9D307
> gpg: Firma valida da "Diego <test at example.com>"
>
>> I notice that no one on this list - for all the talk of "oh I've done it" 
> can offer no
>> practical information has to HOW. No one. No one. No one knows how to do 
> this simple task.
>> In all my 20 years I have never found out how. Perhaps things are different 
> under a Windows
>> O/S but on Linux there is NO SOLUTION.
> Done just now in Ubuntu. So there's an error on your side.
>
> BYtE,
>  Diego.

Thank you, Diego!

One failure of the culture of Usenet and many mailing lists is an
unreasonable reluctance to publish exact specific code, in answer
to a question about how to do something.  Often an answer of this
form is given:

   Ah, you just have to frobniculate the upper side parser, then
   reduce the dimension of the third homotopy group by killing all
   high pressure *reverse* constraints forced by the file which
   specifies the Lipschitz spectrum, at level 2.  Then just restart
   the daemon.  It may take a minute or two, if the network checks
   are fully enabled, but that is the only trouble I have ever
   had, doing it this way.  Some vora114 administrators recommend
   re-compiling all of the Lipschitz spectrum, some even suggest
   regenerating the Sobolev softmax pragmata, but I have never
   found that necessary.

which is correct, and easily understood by anyone who already
knows how to do the task, but difficult to understand, if you do
not already know how to do the task.  A more useful answer is:

   Become root on the machine.  Then do

   root at example:~# cd /etc/vora114
   root at example:~# cp -a lipschitz.conf lipschitz.conf.bak
   root at example:~# echo frob upper 2 safe >> side-parse.conf
   root at example:~# echo :l2 v.. greater-than > l2.l.rev.remove
   root at example:~# grep -v -f l2.l.rev.remove lipschitz.conf > lipschitz.conf.temp
   root at example:~# mv lipschitz.conf.temp lipschitz.conf
   root at example:~# /etc/init.d/vora114 force-reload

   You may, if vora114 checks all network connections, have to
   wait a few minutes for vora114 to fully start.  So wait five
   minutes and then do

   root at example:~# /etc/init.d/vora114 status

   and send us a copy of the first sixty lines of output.

oo--JS.