GNU bug report logs - #34378
update GNOME Planner to current

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34378 in the body.
You can then email your comments to 34378 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrew Miloradovsky <andrew <at> interpretmath.pw>
To: guix-patches <at> gnu.org
Subject: update GNOME Planner to current
Date: Fri, 8 Feb 2019 01:54:08 +0000

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

The release is fairly old and contains prebuilt scripts.

[0001-gnu-gnome-planner-update-0.14.6-to-2019-02-08.patch (text/plain, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at 34378 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Andrew Miloradovsky <andrew <at> interpretmath.pw>
Cc: 34378 <at> debbugs.gnu.org
Subject: Re: [bug#34378] update GNOME Planner to current
Date: Tue, 12 Feb 2019 22:58:43 +0100

Hi Andrew,

Andrew Miloradovsky <andrew <at> interpretmath.pw> skribis:

> The release is fairly old and contains prebuilt scripts.

What do you mean by “prebuilt scripts”?

> From cbe5c7a354381c665735085a5eb262404e901385 Mon Sep 17 00:00:00 2001
> From: Andrew Miloradovsky <andrew <at> interpretmath.pw>
> Date: Fri, 8 Feb 2019 00:03:48 +0000
> Subject: [PATCH] gnu: gnome-planner: update 0.14.6 to 2019-02-08
>
> Build all from a modern version, enable Python bindings.
>
> * gnu/packages/gnome.scm (gnome-planner):
>   - Fetch the sources from GNOME's own GitLab.
>   - Run `autogen.sh` with the proper shell paths.
>   - Enable Python 2 bindings, because we can now.
>   - Add all the inputs necessary for all of that.

Please see ‘git log’ and
<https://www.gnu.org/software/guix/manual/en/html_node/Submitting-Patches.html>
for examples of the commit message format.

> +  ;;; Warning:
> +  ;;; The documentation generation mechanism is long broken. No Yelp yet.
> +  ;;; So the output doesn't contain any docs, unlike the ancient release.
> +  ;;; OTOH, that's probably not a huge concern, given the circumstances.
> +  (let ((commit "fa7cbe309d5a705502ca46f808bcf78840804dbe")
> +        (revision "2019-02-08"))

How did you pick this particular commit?  In general we only package
releases, unless there’s a compelling reason to build straight from the
VCS.  Do you think that’s the case here?

Thanks for the patch!

Ludo’.

Message #11 received at 34378 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Miloradovsky <andrew <at> interpretmath.pw>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 34378 <at> debbugs.gnu.org
Subject: Re: [bug#34378] update GNOME Planner to current
Date: Wed, 13 Feb 2019 13:13:59 +0000

Hi Ludovic,

On 2/12/19 9:58 PM, Ludovic Courtès wrote:
> Hi Andrew,
>
> Andrew Miloradovsky <andrew <at> interpretmath.pw> skribis:
>
>> The release is fairly old and contains prebuilt scripts.
> What do you mean by “prebuilt scripts”?

By pre-built scripts I mean things like `configure`, generated by
auto-tools and gnome-common.

>> From cbe5c7a354381c665735085a5eb262404e901385 Mon Sep 17 00:00:00 2001
>> From: Andrew Miloradovsky <andrew <at> interpretmath.pw>
>> Date: Fri, 8 Feb 2019 00:03:48 +0000
>> Subject: [PATCH] gnu: gnome-planner: update 0.14.6 to 2019-02-08
>>
>> Build all from a modern version, enable Python bindings.
>>
>> * gnu/packages/gnome.scm (gnome-planner):
>>   - Fetch the sources from GNOME's own GitLab.
>>   - Run `autogen.sh` with the proper shell paths.
>>   - Enable Python 2 bindings, because we can now.
>>   - Add all the inputs necessary for all of that.
> Please see ‘git log’ and
> <https://www.gnu.org/software/guix/manual/en/html_node/Submitting-Patches.html>
> for examples of the commit message format.

The changes made didn't fit well in the recommended commit message
structure (documenting the changes to each field separately).

>> +  ;;; Warning:
>> +  ;;; The documentation generation mechanism is long broken. No Yelp yet.
>> +  ;;; So the output doesn't contain any docs, unlike the ancient release.
>> +  ;;; OTOH, that's probably not a huge concern, given the circumstances.
>> +  (let ((commit "fa7cbe309d5a705502ca46f808bcf78840804dbe")
>> +        (revision "2019-02-08"))
> How did you pick this particular commit?  In general we only package
> releases, unless there’s a compelling reason to build straight from the
> VCS.  Do you think that’s the case here?

I picked that commit just because it was the most recent: the release is
expected to be very difficult to make, a lot of things need to be
fixed/modernized first, and there are not many people to review the
patches (one to be exact, AFAICT).

I'm not sure there are really compelling reasons: most/all of the
changes made since the release are either about translations
(documentation generation is broken anyways), or fixes of deprecation
warnings (which otherwise would prevent it from building in Nixpkgs with
the default -Werror).

>
> Thanks for the patch!
>
> Ludo’.

Message #14 received at 34378 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Andrew Miloradovsky <andrew <at> interpretmath.pw>
Cc: 34378 <at> debbugs.gnu.org
Subject: Re: [bug#34378] update GNOME Planner to current
Date: Mon, 11 Mar 2019 16:45:21 +0100

Hi Andrew,

Sorry for the loooong delay!

Andrew Miloradovsky <andrew <at> interpretmath.pw> skribis:

> On 2/12/19 9:58 PM, Ludovic Courtès wrote:
>> Hi Andrew,
>>
>> Andrew Miloradovsky <andrew <at> interpretmath.pw> skribis:
>>
>>> The release is fairly old and contains prebuilt scripts.
>> What do you mean by “prebuilt scripts”?
>
> By pre-built scripts I mean things like `configure`, generated by
> auto-tools and gnome-common.

Oh I see.  We currently accept scripts generated by the Autotools (it’s
pretty much an exception in our policy; perhaps that’ll change in the
future.)

>>> +  ;;; Warning:
>>> +  ;;; The documentation generation mechanism is long broken. No Yelp yet.
>>> +  ;;; So the output doesn't contain any docs, unlike the ancient release.
>>> +  ;;; OTOH, that's probably not a huge concern, given the circumstances.
>>> +  (let ((commit "fa7cbe309d5a705502ca46f808bcf78840804dbe")
>>> +        (revision "2019-02-08"))
>> How did you pick this particular commit?  In general we only package
>> releases, unless there’s a compelling reason to build straight from the
>> VCS.  Do you think that’s the case here?
>
> I picked that commit just because it was the most recent: the release is
> expected to be very difficult to make, a lot of things need to be
> fixed/modernized first, and there are not many people to review the
> patches (one to be exact, AFAICT).
>
> I'm not sure there are really compelling reasons: most/all of the
> changes made since the release are either about translations
> (documentation generation is broken anyways), or fixes of deprecation
> warnings (which otherwise would prevent it from building in Nixpkgs with
> the default -Werror).

OK.  I think it’s a case where we’d wait for upstream to push a new
release, rather than guess which commit is appropriate to distribute.

Thoughts?

Thanks,
Ludo’.

Message #19 received at 34378-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Andrew Miloradovsky <andrew <at> interpretmath.pw>, 34378-done <at> debbugs.gnu.org
Subject: Re: bug#34378: update GNOME Planner to current
Date: Tue, 23 Aug 2022 14:55:14 -0400

Hello,

Ludovic Courtès <ludo <at> gnu.org> writes:

[...]

>>>> +  ;;; Warning:
>>>> +  ;;; The documentation generation mechanism is long broken. No Yelp yet.
>>>> +  ;;; So the output doesn't contain any docs, unlike the ancient release.
>>>> +  ;;; OTOH, that's probably not a huge concern, given the circumstances.
>>>> +  (let ((commit "fa7cbe309d5a705502ca46f808bcf78840804dbe")
>>>> +        (revision "2019-02-08"))
>>> How did you pick this particular commit?  In general we only package
>>> releases, unless there’s a compelling reason to build straight from the
>>> VCS.  Do you think that’s the case here?
>>
>> I picked that commit just because it was the most recent: the release is
>> expected to be very difficult to make, a lot of things need to be
>> fixed/modernized first, and there are not many people to review the
>> patches (one to be exact, AFAICT).
>>
>> I'm not sure there are really compelling reasons: most/all of the
>> changes made since the release are either about translations
>> (documentation generation is broken anyways), or fixes of deprecation
>> warnings (which otherwise would prevent it from building in Nixpkgs with
>> the default -Werror).
>
> OK.  I think it’s a case where we’d wait for upstream to push a new
> release, rather than guess which commit is appropriate to distribute.
>
> Thoughts?

Agreed.  Closing.

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.