Debian Bug report logs - #802528
valac: make the generated C files reproducible

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Niko Tyni <ntyni@debian.org>

To: submit@bugs.debian.org

Subject: valac: make the generated C files reproducible

Date: Tue, 20 Oct 2015 22:53:43 +0300

[Message part 1 (text/plain, inline)]

Package: valac
Version: 0.30.0-2
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: toolchain randomness
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

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   ntyni@debian.org

[0001-Preserve-order-of-current_required_app_classes-for-r.patch (text/x-diff, attachment)]

[valac-reproducibility.tar.gz (application/gzip, attachment)]

Message #10 received at 802528@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Niko Tyni <ntyni@debian.org>, 802528@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>

Subject: Re: [Reproducible-builds] Bug#802528: valac: make the generated C files reproducible

Date: Tue, 20 Oct 2015 16:09:16 -0400

On Tue 2015-10-20 15:53:43 -0400, Niko Tyni wrote:
> Package: valac
> Version: 0.30.0-2
> Severity: wishlist
> Tags: patch
> User: reproducible-builds@lists.alioth.debian.org
> Usertags: toolchain randomness
> X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
>
> 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.

Thanks for catching this!  I'd looked into it before and hadn't been
able to track this down.

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.

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.

        --dkg

Message #15 received at 802528@bugs.debian.org (full text, mbox, reply):

From: Niko Tyni <ntyni@debian.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: 802528@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>

Subject: Re: [Reproducible-builds] Bug#802528: valac: make the generated C files reproducible

Date: Tue, 20 Oct 2015 23:28:21 +0300

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.
-- 
Niko Tyni   ntyni@debian.org

Message #22 received at 802528@bugs.debian.org (full text, mbox, reply):

From: Daniel Espinosa <esodan@gmail.com>

To: 802528@bugs.debian.org

Subject: Fixed if VALAC is not needed?

Date: Mon, 10 Oct 2016 14:50:14 -0500

[Message part 1 (text/plain, inline)]

For Vala projects, is possible to distribute C source code then is not
necessary to have installed Vala's compiler to create binaries versions.

Now, if a Vala project doesn't distribute its C, GIR and/or VAPI generated
files, then you need VALAC.

Then is the project distribute all its generated files and build process,
don't required to call VALAC at all, this bug can be dismissed and filed
one against the project's upstream.

Is this correct?


-- 
This electronic message may contain privileged and confidential information
intended only for the use of the addressees named above.  If you are not
the intended recipient of this email, we kindly ask you to delete this
message and any attachment. You are hereby notified that any use,
dissemination, distribution, reproduction of this email is prohibited.  If
you have received this email in error, please notify sender immediately.

Any document, image or any other form of electronic representation of any
work attached to this email, is suitable to be protected by copyright
enforcement by applicable law in your or sender's Country's and
International Legislation

Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.