Re: From gnunet-bcd to configure.ac

[Alessio Vanni]

Hello,

I've merged the branch and pushed to the remote.

In addition to the changes originally summarized by the mail I'm
replying to, I've fixed the check for uncrustify and added a new macro
called CHECK_LATEX_PACKAGE with which it should be possible to check for
LaTeX packages.

Right now the building of gnunet-bcd is still conditioned only by the
presence for pdflatex and not by the packages because it's unclear if
that macro works under different installations (I can't really test on
too many systems, especially any "esoteric" one targeted by GNUnet), but
I wanted to push these changes fast as I'm being a bit busy these days
and doing it like this means people can still get gnunet-bcd even with a
buggy macro.

Adding the package checks to AM_CONDITIONAL is trivial, so if people can
test it out in the meantime, I can then finalize it for good.

Thanks,
A.V.

Alessio Vanni <vannilla@firemail.cc> writes:

> Hello,
>
> these past few weeks I've been working on a few things summarized by the
> subject of this mail.
>
> Initially I simply wanted to replace a vector image, but I ended up
> changing a lot more stuff, including doing some major work on the
> configure.ac file.
>
> It all started when I thought I'd try bringing the cards generated by
> gnunet-bcd more up-to-date with current GNUnet, by changing the old "gnu
> in front of a spiderweb" logo with the new "gnu made by interconnected
> points" logo.
>
> Before I had started working on that, I had run a test to see how the
> old cards looked like, but I discovered that pdflatex would always abort
> the document generation with some rather obscure errors.  Eventually, I
> discovered that those errors were caused by an incompatibility between
> TikZ 3 and pstricks which, from what I could gather, can't be worked
> around using the methods outlined in the pstricks web page.
>
> Due to that, other than working on adding the new logo I also had to
> rewrite the TeX files to not depend on pstricks.  Other than generating
> the old logo, it was used to create the QR code with the given GNS URI,
> so I had to search for another package for that task.  It seems the
> "qrcode" package is normally available in a "full" installation of TeX
> as distributed by major GNU/Linux distribution.
>
> The full details will be listed later in this mail, but eventually I
> managed to rewrite the card-generating TeX file to compile with current
> TikZ and to also have the new logo.
>
> Since I had changed the whole TeX file, I thought I might as well do the
> rest of gnunet-bcd, in a similar fashion to what I did for the FCFS
> service.
>
> This resulted in a fairly complete overhaul of gnunet-bcd, which also
> brought a new feature to create a PNG picture of just the QR code, with
> the purpose of letting people easily embed it in other media, instead of
> having to deal with a full-fledged PDF (for example, it can be displayed
> in-line in an e-mail signature.)  Right now it provides only the QR
> code, but since it's a program that come with GNUnet and that can
> connect with GNUnet's services, it can add to the generated PNG as many
> informations as needed.
>
> Since I had added this feature to generate a PNG, I thought it would be
> nice if gnunet-qr could read the images generated by gnunet-bcd through
> this new feature.  After a bit of work, if GNUnet's configure script
> detects that libpng is available, gnunet-qr will have a new '-f' flag
> which allows the tool to natively read a PNG file and import the scanned
> QR code, if any.
>
> Incidentally, these changes to gnunet-qr made me discover a bug with
> gnunet-namestore, explained later.
>
> Lastly, because I had to change configure.ac and since during a system
> update I ended up with Autoconf 2.71 installed, which generated a number
> of warnings when recompiling the configure script, I started working on
> the whole file to not only bring it up to date with the new Autoconf,
> but also to simplify it when possible and correct a few things I have
> always found strange.
>
> Shortly after writing this mail (it's quite long!), I'm going to push a
> new branch with the following changes:
>
> - gnunet-bcd
> The new GNUnet logo is now used. This logo is generated through a TikZ
> picture defined in the file itself.
>
> gnunet-bcd can now generate three different files: the first is simply a
> rework of the file that is already generated; the second is a simplified
> version of that file, in which only the most basic informations, like
> the full name and a few contact addresses, are requested.  The purpose
> of this simplified version is to allow people to generate a "GNUnet
> business card" even when they can't fill most of the fields requested by
> the "full" version.  The last type of file is a PNG-encoded picture of
> the QR code for embedding.
>
> The web UI has been reworked. It doesn't include the entire Bootstrap 4
> CSS, but contains only the necessary directives, adapted from Boostrap
> 5, to style the used elements (mostly input text boxes and labels.)  The
> main reason for this choice is that editing the previous HTML was fairly
> laborious, as you either deal with a file with a single line of minified
> CSS, something that can kill certain editors, or you use XLSL to
> generate the HTML from an XML specification, which is really an
> unnecessary step, in my opinion.  The maintenance burden is more or less
> the same as before, because unless there's a need to rework the whole
> interface, there's no need to touch the CSS at all.
>
> It also uses files with similar stylesheets to provide somewhat more
> detailed error pages, instead of giving a very barebones HTML.  This
> last change is really just for consistency with the visuals, as it
> doesn't otherwise bring anything.  Unfortunately to keep things inside
> gnunet-bcd itself simple, most of the CSS had to be duplicated inside
> each file, instead of having them share a single common file, but it
> shouldn't be too much of an issue. In the worst case, the service can be
> made smarter in exchange of more lines of C code.
>
> Finally, the program itself is not built/installed unless the pdflatex
> tool is available.
>
> - gnunet-qr
> When libpng is detected by configure, a new option '-f' ('--file') is
> made available, to read a QR code from a PNG-encoded picture.  The
> choice of PNG is really arbitrary, because I believe it's one of the
> best formats for this kind of content, not to mention it's usually
> available everywhere, as sometimes libpng comes already installed when
> installing a GNU/Linux distribution.
>
> - gnunet-namestore
> The '-u' option was broken. I forgot in which version this change was
> made, but now public keys for egos are "stringified" by prepending a
> readable representation of the string length before the actual key.
> gnunet-namestore was trying to read the old format, which is six
> characters shorter.
>
> - configure.ac
> For the most part, many macros being used either by the file itself or
> by external files providing macros used by it, were brought up to date.
> For example, iconv.m4 was updated from serial 18 to serial 21 and
> libgcrypt.m4 is now the one released in 2020.
>
> Some macros were simplified while others were created to reduce the
> amount of repeated code.  This is most notable for checks regarding
> external libraries like libzbar or libmicrohttpd: instead of explicitly
> writing AC_ARG_WITH and do the various checks manually, a new macro
> CHECK_WITH_LIB takes care of that.
>
> Not every check could be simplified like that, but the amount of code to
> deal with still has been reduced by a decent amount.
>
> Unfortunately, a few checks had to be made "less simple", due to the
> subject of the checks.  A notable example is 'struct in6_ifreq' which is
> being dealt with through a series of nested AS_IF.  Since the checks are
> meant to provide the proper path to the if_tun.h header (<if_tun.h>
> instead of <net/if_tun.h>, etc.), I couldn't think of a better way.
>
> Some checks were removed to start transitioning towards Autoconf 2.71.
> Actually, as it is, it's already compatible with 2.71, but I'm not sure
> if it's already fully updated or if Autoconf is being lenient in some
> cases.  I kept 2.69 inside AC_PREREQ just in case.
>
> The summary printed to screen at the end of the script execution has
> been improved a little, mainly by reordering the entries.
>
> There are also probably some other things I'm forgetting right now and
> I'm not really going to read the whole git diff.
>
> This should be everything, so please report any strange behaviour you
> might find.
>
> Thanks,
> A.V.