Re: 01/01: gnu: totem: Enable parallel build.

Re: 01/01: gnu: totem: Enable parallel build.

[Mark H Weaver]

Hi,

kkebreau@posteo.net (Kei Kebreau) writes:

> kkebreau pushed a commit to branch master
> in repository guix.
>
> commit e5f748a6c0c774265f52c7246ee7b80bec6d3522
> Author: Kei Kebreau <kkebreau@posteo.net>
> Date:   Wed Nov 8 20:42:20 2017 -0500
>
>     gnu: totem: Enable parallel build.
>     
>     * gnu/packages/gnome.scm (totem)[arguments]: Set #:parallel-build? to #t
>     implicitly.

Your commit reverted the preceding commit made to our 'totem' package,
namely:

> commit a97bfa46cdb782f705204a50a10bca9fa98c56b2
> Author: Adam Van Ymeren <adam@vany.ca>
> Date:   Fri Oct 13 12:40:50 2017 -0400
> 
>     gnu: totem: Disable parallel build due to http://debbugs.gnu.org/28813
>     
>     Fixes <http://bugs.gnu.org/28813>.
>     
>     * gnu/packages/gnome.scm (totem)[arguments]: Add #:parallel-build?.
>     
>     Signed-off-by: Ludovic Courtès <ludo@gnu.org>

Unsurprisingly, this caused bug #28813 to re-appear.  Since reverting
this fix, one of the totem builds failed on Hydra with the same error
message described in <https://bugs.gnu.org/28813>:

  https://hydra.gnu.org/build/2352092

namely:

--8<---------------cut here---------------start------------->8---
[124/150] Compiling Vala source ../totem-3.26.0/src/plugins/sample-vala/totem-sample-vala-plugin.vala.
FAILED: src/plugins/sample-vala/sample-vala@sha/totem-sample-vala-plugin.c src/plugins/sample-vala/sample-vala.h src/plugins/sample-vala/sample-vala.vapi 
valac -C --pkg libpeas-1.0 --pkg gtk+-3.0 -d src/plugins/sample-vala/sample-vala@sha --library=sample-vala -H src/plugins/sample-vala/sample-vala.h --vapi ../sample-vala.vapi --girdir=/tmp/guix-build-totem-3.26.0.drv-0/build/src --pkg=Totem-1.0 ../totem-3.26.0/src/plugins/sample-vala/totem-sample-vala-plugin.vala
error: Package `Totem-1.0' not found in specified Vala API directories or GObject-Introspection GIR directories
Compilation failed: 1 error(s), 0 warning(s)
[125/150] Linking target src/plugins/ontop/libontop.so.
[126/150] Linking target src/totem.
[127/150] Generating Totem-1.0.gir with a custom command.
ninja: build stopped: subcommand failed.
phase `build' failed after 15.8 seconds
builder for `/gnu/store/l6pv9v3kvvbj4dfnmqj2irmqzwa9hw4c-totem-3.26.0.drv' failed with exit code 1
@ build-failed /gnu/store/l6pv9v3kvvbj4dfnmqj2irmqzwa9hw4c-totem-3.26.0.drv - 1 builder for `/gnu/store/l6pv9v3kvvbj4dfnmqj2irmqzwa9hw4c-totem-3.26.0.drv' failed with exit code 1
--8<---------------cut here---------------end--------------->8---

I'd like to understand what led you to believe that removing this fix
was appropriate.  In general, we don't add #:parallel-build? #f without
a good reason.  The code even included a comment referencing bug #28813.
I assume that you saw the comment, since you removed it.

So, what made you think that this fix was no longer needed?  Can you
help me understand how this happened?

      Mark

Re: 01/01: gnu: totem: Enable parallel build.

[Kei Kebreau]

[-- Attachment #1: Type: text/plain, Size: 3108 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> Hi,
>
> kkebreau@posteo.net (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit e5f748a6c0c774265f52c7246ee7b80bec6d3522
>> Author: Kei Kebreau <kkebreau@posteo.net>
>> Date:   Wed Nov 8 20:42:20 2017 -0500
>>
>>     gnu: totem: Enable parallel build.
>>     
>>     * gnu/packages/gnome.scm (totem)[arguments]: Set #:parallel-build? to #t
>>     implicitly.
>
> Your commit reverted the preceding commit made to our 'totem' package,
> namely:
>
>> commit a97bfa46cdb782f705204a50a10bca9fa98c56b2
>> Author: Adam Van Ymeren <adam@vany.ca>
>> Date:   Fri Oct 13 12:40:50 2017 -0400
>> 
>>     gnu: totem: Disable parallel build due to http://debbugs.gnu.org/28813
>>     
>>     Fixes <http://bugs.gnu.org/28813>.
>>     
>>     * gnu/packages/gnome.scm (totem)[arguments]: Add #:parallel-build?.
>>     
>>     Signed-off-by: Ludovic Courtès <ludo@gnu.org>
>
> Unsurprisingly, this caused bug #28813 to re-appear.  Since reverting
> this fix, one of the totem builds failed on Hydra with the same error
> message described in <https://bugs.gnu.org/28813>:
>
>   https://hydra.gnu.org/build/2352092
>
> namely:
>
> [124/150] Compiling Vala source ../totem-3.26.0/src/plugins/sample-vala/totem-sample-vala-plugin.vala.
> FAILED: src/plugins/sample-vala/sample-vala@sha/totem-sample-vala-plugin.c src/plugins/sample-vala/sample-vala.h src/plugins/sample-vala/sample-vala.vapi 
> valac -C --pkg libpeas-1.0 --pkg gtk+-3.0 -d src/plugins/sample-vala/sample-vala@sha --library=sample-vala -H src/plugins/sample-vala/sample-vala.h --vapi ../sample-vala.vapi --girdir=/tmp/guix-build-totem-3.26.0.drv-0/build/src --pkg=Totem-1.0 ../totem-3.26.0/src/plugins/sample-vala/totem-sample-vala-plugin.vala
> error: Package `Totem-1.0' not found in specified Vala API directories or GObject-Introspection GIR directories
> Compilation failed: 1 error(s), 0 warning(s)
> [125/150] Linking target src/plugins/ontop/libontop.so.
> [126/150] Linking target src/totem.
> [127/150] Generating Totem-1.0.gir with a custom command.
> ninja: build stopped: subcommand failed.
> phase `build' failed after 15.8 seconds
> builder for `/gnu/store/l6pv9v3kvvbj4dfnmqj2irmqzwa9hw4c-totem-3.26.0.drv' failed with exit code 1
> @ build-failed /gnu/store/l6pv9v3kvvbj4dfnmqj2irmqzwa9hw4c-totem-3.26.0.drv - 1 builder for `/gnu/store/l6pv9v3kvvbj4dfnmqj2irmqzwa9hw4c-totem-3.26.0.drv' failed with exit code 1
>
> I'd like to understand what led you to believe that removing this fix
> was appropriate.  In general, we don't add #:parallel-build? #f without
> a good reason.  The code even included a comment referencing bug #28813.
> I assume that you saw the comment, since you removed it.
>
> So, what made you think that this fix was no longer needed?  Can you
> help me understand how this happened?
>
>       Mark

I mistakenly thought Totem had been updated since that change and I had
built it successfully a few times on my computer. I've reverted this
change on master.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Please write "Update to <version>" instead of "Update snapshot"

[Kei Kebreau]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

I thought "Update snapshot." had become customary for updating to
different VCS commits. I am in favor of keeping "Update to <version>."
where <version> is the Guix version string of the package in
question. This practice is especially useful when using "git shortlog"
and related tools.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Please write "Update to <version>" instead of "Update snapshot"

[Mark H Weaver]

Hello Guix,

I'd like to propose that we deprecate the practice of simply writing
"Update snapshot" in the summary line of software updates, and instead
consistently write "Update to <version>", as we do for the vast majority
of updates.

This practice seems to have originated with our 'guix-devel' package,
and iirc for a long time that was the sole exception to our usual
convention.  However, recently I've seen this practice gradually
spreading to other packages, e.g. gcl, kodi, xf86-video-intel, cuirass,
guile2.2-ssh, etc.  I've CC'd the few Guix developers who have started
doing this.

In my opinion, the version number is a very useful piece of information
to see for update commits when browsing the commit history.  I regard
the practice of omitting the version number to be a slowly creeping
regression in our otherwise exceptionally good conventions for commit
logs.  I humbly propose that we nip this regression in the bud.

What do you think?

      Mark

Re: Please write "Update to <version>" instead of "Update snapshot"

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Sat, Nov 25, 2017 at 07:43:11PM -0500, Mark H Weaver wrote:
> In my opinion, the version number is a very useful piece of information
> to see for update commits when browsing the commit history.  I regard
> the practice of omitting the version number to be a slowly creeping
> regression in our otherwise exceptionally good conventions for commit
> logs.  I humbly propose that we nip this regression in the bud.

I agree that the commit message should always include the new version of
the package being updated.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Please write "Update to <version>" instead of "Update snapshot"

[Ludovic Courtès]

Heya,

Leo Famulari <leo@famulari.name> skribis:

> On Sat, Nov 25, 2017 at 07:43:11PM -0500, Mark H Weaver wrote:
>> In my opinion, the version number is a very useful piece of information
>> to see for update commits when browsing the commit history.  I regard
>> the practice of omitting the version number to be a slowly creeping
>> regression in our otherwise exceptionally good conventions for commit
>> logs.  I humbly propose that we nip this regression in the bud.
>
> I agree that the commit message should always include the new version of
> the package being updated.

I plaid guilty here, but yes, I agree with giving a commit ID in the
summary line when updating the ‘guix’ package and others.

Apologies for the confusion.

Ludo’.