Your message dated Sat, 23 May 2026 19:40:36 +0100
with message-id <[email protected]>
and subject line Re: Ships autogenerated files that can't be renegerated with
the code in Debian main
has caused the Debian Bug report #1017891,
regarding Ships autogenerated files that can't be renegerated with the code in
Debian main
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1017891: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017891
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: vala
Version: 0.56.2-1
Severity: serious
Tags: upstream
Hi,
See the discussion on the Debian Rust maintainers list for background:
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html
While that discussion is about Rust packages that were rejected, the same
situation also applies to Vala unfortunately. For more details how to solve
this in a way that makes ftp-masters happy, please refer to them.
The whole vapi subdirectory of the source package currently contains
autogenerated files for which the original source is not available in Debian.
Some examples for this are
- gstreamer-audio-1.0.vapi: This was generated from the gir file of the
corresponding library. While the library does exist in Debian and also the
gir file (libgstreamer-plugins-base1.0-dev), the same version does not
exist and regenerating it from the version in Debian will introduce
changes due to being older.
As of 0.56.2 the file was generated from an unspecified git snapshot after
the last GStreamer release, see
https://gitlab.gnome.org/GNOME/vala/-/commit/6d80e07996834ace2a8d0f994913bc9cc623ec9b
- gnet-2.0.vapi: The corresponding library does not even exist in Debian.
This is not a full list. You'll have to check one by one for all of these
autogenerated files and provide the original source in the correct version, or
ideally regenerate the files based on the source code in Debian on every
build.
>From my understanding, regenerating the files with whatever version is
available in Debian at build time is not an option if you don't want to lose
upstream support for any vapi-related bugs.
These files are also included in binary packages.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100,
'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
On Thu, 2 Apr 2026 15:40:38 +0100 Neil Williams <[email protected]>
wrote:
> On Mon, 22 Aug 2022 09:59:03 +0300 =?utf-8?q?Sebastian_Dr=C3=B6ge?=
> <[email protected]> wrote:
> > Source: vala
> > Version: 0.56.2-1
>
> .. and all other versions of the package currently in Debian ...
>
> > The whole vapi subdirectory of the source package currently contains
> > autogenerated files for which the original source is not available
> > in Debian.
> >
> > Some examples for this are
> >
> > - gnet-2.0.vapi: The corresponding library does not even exist in
> > Debian.
> >
> > From my understanding, regenerating the files with whatever version
> > is available in Debian at build time is not an option if you don't
> > want to lose upstream support for any vapi-related bugs.
> >
> > These files are also included in binary packages.
>
> These files may have been autogenerated at some time in the past, but
> upstream are making manual changes to these files quite regularly.
> e.g. The gnet file mentioned above appears to have been generated in
> 2008 but has been edited since.
>
> https://github.com/GNOME/vala/commits/main/vapi/gnet-2.0.vapi
>
> So maybe this bug isn't as clear as initially described. Filed in
> 2022, it hasn't stopped vala being included in 3 stable releases,
> with these files in place in all source and in each of the
> valac-<VER>-vapi binary packages.
>
> I'm not sure whether this bug should be downgraded (I only found it
> because it's listed as RC in UDD) or actually closed as a
> misinterpretation of the upstream vala source code and maintenance
> practices. What started out as generated files do appear to be being
> handled by upstream as typical source code.
Based on:
https://lists.debian.org/debian-devel/2026/05/msg00258.html
It's clear to me that the vapi files are being treated as source code
under the existing licence. What was probably auto-generated at some
point in the past is now being edited manually as source code. So there
is no issue to solve. Even if tools outside Debian did create old
versions of the files, there's no upstream tooling being used to
generate the files as released.
Closing the bug.
--
Neil Williams
=============
[email protected]
https://www.codehelp.co.uk/
--- End Message ---
