I cannot verify it as I do not have any Ubuntu machine any more so,
close freely if it seems fixed.
--
gtkdoc-fixxref broken by compressed documentation
https://bugs.launchpad.net/bugs/77138
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
> After all, these are not that hard to support from Perl
This way of thinking is the source of all the problems. Sure, it is not
hard to add compression support in a one particular case. But then then
is another case, then a couple of them, yet another, a few more, and it
never stops. The comp
>> The complexity of every simple private or one-shot script that reads these
>> files
>> is considerably increased.
> This is why we use wrappers, libraries, or whatever to handle input formats,
> instead of writing a parser for each program.
Many of these files are not in `formats'. They are
> This is because you don't wont to read the actual arguments people are making:
> saving space is still an issue for example in live CDs, embedded systems
> (where one still has to ship some files such as copyrights), or simply to
> email them;
> zipping still provides a speed advantage when the
What the...
Please forget bug report has been ever submitted. Thank you for your
time.
--
gtkdoc-fixxref broken by compressed documentation
https://bugs.launchpad.net/bugs/77138
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug contact for gtk-do
Public bug reported:
Binary package hint: gtk-doc-tools
One of the primary function of gtkdoc-fixxref is to point references to
standard GLib, Gtk+, etc. symbols (types, functions, macros, etc.) in
generated documentation to the system documentation if present. In
other words, if another library