Bug#751550: RFS: aclock.app/0.4.0-1 [ITA]

[Yavor Doganov <yavor@gnu.org>]

Paul Gevers wrote:
> On 06-08-14 13:57, Yavor Doganov wrote:
> > That's news to me.
> 
> Is it? I thought I saw you doing the same thing with the some xpm
> files in multiple GNUstep packages.

Only because they don't exist.  It would never occur to me to
regenerate an image file that is already in the tarball.  I don't see
the point; it seems unnecessary complication to me.

> Well, I do it in multiple of my packages, e.g. in Winff to create the
> pdfs from Libre Office files.

Maybe it has some merit in this case -- what you do ensures that the
PDF files are always current (in the case where upstream has modified
the LibreOffice files but forgotten to regenerate the PDFs).

(I wouldn't do it for my packages because libreoffice is not available
on about half of the architectures.  It doesn't do any harm to winff,
though.)

> An alternative would be to create a target in the rules file that
> can be used once in a while to check it is possible.

I could try to do that, if I'm convinced there is a compelling
reason...

> > A far more serious concern is whether the .gorm files will be
> > loadable with future gnustep-gui releases or editable with future
> > gorm.app versions.
> 
> Can you help me a bit, how does this work? Are the .gorm files in the
> packages created by the maintainer? Are they the source files, or
> created during building?

The .gorm files are created by the upstream developers, with Gorm.
They are the source and the "executable", no building is required.
During building, they are simply copied into the resource bundle.

A .gorm file is loaded dynamically at runtime.  The file is first
unarchived, then all objects are decoded, allocated and initialized.
.gorm files do not only describe the UI (like .ui or .glade files in
the GTK+/GNOME world), they have the object connections/relationship
and whole classes encoded so they may form a considerable part of the
program.

As the format has changed a few times in the past, a file created with
a newer version of Gorm (or the corresponding proprietary tool on
MuckOS X) is not always guaranteed to be loaded by an older GNUstep
installation.  In rare cases, a .gorm file may not be loaded
successfully by some random versions of gnustep-gui, typically when it
was created by a very old or buggy Gorm version (we had one case like
this in Debian -- I don't remember if we patched it with uuencode or
just removed the package, most probably the latter).

Upstream strives very hard to preserve compatibility, but as usual
there is no guarantee.  AClock with a broken .gorm file will be
completely useless, while the outdated cuckoo will work just fine.

> Well, it comes from me as I had to ask you during the reviewing how
> this all works. If it is documented, you don't need to do the same
> next time

If there was no .blend file in the tarball and we were unaware of its
existence, would it be a DFSG violation?  PNG files are editable, and
it could be possible, in theory and in practice, that this cuckoo
animation is created/maintained in a manual fashion (I'm not familar
with graphics design practices, so I may be wrong here).

I anticipate there are hundreds of thousands of images in the archive,
and most probably some of them do not have the corresponding source
(or perhaps more accurately said, preferred form of modification).
Most definitely, those that have the source available are not using it
to regenerate the image files, or else there ought to be a lot of
inkscape/gimp/blender build-deps.