Your message dated Tue, 6 Jan 2026 17:45:38 -0500
with message-id
<CAAajCMaKYi3dMx6N=+glsbzwvetprmggjv+um2zib+vqt8y...@mail.gmail.com>
and subject line Re: Bug#802528: [Reproducible-builds] Bug#802528: valac: make
the generated C files reproducible
has caused the Debian Bug report #802528,
regarding valac: make the generated C files reproducible
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.)
--
802528: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802528
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: valac
Version: 0.30.0-2
Severity: wishlist
Tags: patch
User: [email protected]
Usertags: toolchain randomness
X-Debbugs-Cc: [email protected]
While working on the "reproducible builds" effort [1], we have noticed
that the gnome-clocks package doesn't build reproducibly because the
C files generated by valac vary between builds. A sample diff is
--- a/src/timer.c
+++ b/src/timer.c
@@ -1277,8 +1277,8 @@ static void
clocks_timer_face_clocks_clock_interface_init (ClocksClockIface * if
static void clocks_timer_face_instance_init (ClocksTimerFace * self) {
self->priv = CLOCKS_TIMER_FACE_GET_PRIVATE (self);
self->priv->_state = CLOCKS_TIMER_FACE_STATE_STOPPED;
- g_type_ensure (CLOCKS_TYPE_ANALOG_FRAME);
g_type_ensure (CLOCKS_TIMER_TYPE_COUNTDOWN_FRAME);
+ g_type_ensure (CLOCKS_TYPE_ANALOG_FRAME);
gtk_widget_init_template (GTK_WIDGET (self));
}
The order of the two g_type_ensure() calls varies more or less randomly.
I've tracked this down to a HashSet data structure in Vala.GtkModule
that holds these classes in the C code generation phase. Changing that
to an ordered List type instead fixes the issue. Please consider the
attached patch.
While gnome-clocks seems to be the only affected package, I'm also seeing
this with gnome-contacts when I force regeneration of the C files there.
They are currently not rebuilt from their vala sources during the package
build (#802520).
I'm also attaching a minified test case for your convenience. The generated
t.c varies for me between the compilations with the current valac in sid
but not with a patched one.
[1] https://wiki.debian.org/ReproducibleBuilds
--
Niko Tyni [email protected]
>From 901ec8b07fefb81938f54414e57974ffd095eed3 Mon Sep 17 00:00:00 2001
From: Niko Tyni <[email protected]>
Date: Mon, 19 Oct 2015 23:56:36 +0300
Subject: [PATCH] Preserve order of current_required_app_classes for
reproducibility
The elements of current_required_app_classes end up in the generated
code in g_type_ensure() statements. The order of these can vary
between builds when using a HashSet, breaking reproducibilty.
See https://wiki.debian.org/ReproducibleBuilds
---
codegen/valagtkmodule.vala | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/codegen/valagtkmodule.vala b/codegen/valagtkmodule.vala
index ecc709f..c0f439a 100644
--- a/codegen/valagtkmodule.vala
+++ b/codegen/valagtkmodule.vala
@@ -32,7 +32,7 @@ public class Vala.GtkModule : GSignalModule {
/* GtkBuilder xml child to Vala class mapping */
private HashMap<string, Class> current_child_to_class_map = new HashMap<string, Class>(str_hash, str_equal);
/* Required custom application-specific gtype classes to be ref'd before initializing the template */
- private HashSet<Class> current_required_app_classes = new HashSet<Class>();
+ private List<Class> current_required_app_classes = new ArrayList<Class>();
private void ensure_cclass_to_vala_map () {
// map C name of gtypeinstance classes to Vala classes
--
2.5.1
valac-reproducibility.tar.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Version: 0.38.7-1
On Mon, Jan 6, 2020 at 10:12 AM James Clarke <[email protected]> wrote:
>
> On Tue, Oct 20, 2015 at 11:28:21PM +0300, Niko Tyni wrote:
> > Control: tag -1 - patch
> >
> > On Tue, Oct 20, 2015 at 04:09:16PM -0400, Daniel Kahn Gillmor wrote:
> >
> > > But doesn't the change from HashSet to List end up changing the behavior
> > > with regard to multiple children of the same class?
> > >
> > > That is, if it's a List, then the same class can appear multiple times,
> > > whereas if it's a set, i think it just gets added once.
> >
> > Yes, I think you're right. Thanks for catching that! I suspect it doesn't
> > really matter here, but I'm not quite sure, and it certainly isn't safe
> > as a general fix.
> >
> > > The usual approach would be to sort the output where it's produced from
> > > the HashedSet, and not to change the data structure itself to allow
> > > duplicates.
> >
> > Sure, this just seemed such a nice solution :)
> >
> > Anyway, removing the 'patch' tag for now.
>
> The type you want to use is a TreeSet, which implements SortedSet. I
> also notice this patch was committed to the repository 2 years ago[1],
> ignoring the discussion here about the behaviour being potentially
> incorrect, and not actually closing this bug in the upload.
>
> James
>
> [1]
> https://salsa.debian.org/gnome-team/vala/commit/0056ea4e8d0e25dba13a856fc0aa18646217e4c6
Yes, the change was committed upstream and it would have required the
person doing the Debian upload to have noticed and closed this bug
manually. That change is now 8 years old so I guess things are ok. I'm
closing the Debian bug now.
Thank you,
Jeremy Bícha
--- End Message ---
