[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39263: closed ([PATCH 0/2] Update Godot)

From: GNU bug Tracking System
Subject: bug#39263: closed ([PATCH 0/2] Update Godot)
Date: Wed, 29 Jan 2020 08:01:01 +0000

Your message dated Wed, 29 Jan 2020 08:00:27 +0000
with message-id <address@hidden>
and subject line Re: [bug#39263] [PATCH 2/2] gnu: godot: Unbundle some 
has caused the debbugs.gnu.org bug report #39263,
regarding [PATCH 0/2] Update Godot
to be marked as done.

(If you believe you have received this mail in error, please contact

39263: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39263
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [PATCH 0/2] Update Godot Date: Fri, 24 Jan 2020 15:50:59 +0100

these patches update Godot to latest stable version 3.1.2 and unbundle
bullet, pcre2 and zstd libraries.


Timotej Lazar (2):
  gnu: godot: Update to 3.1.2.
  gnu: godot: Unbundle some dependencies.

 gnu/packages/game-development.scm | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)


--- End Message ---
--- Begin Message --- Subject: Re: [bug#39263] [PATCH 2/2] gnu: godot: Unbundle some dependencies. Date: Wed, 29 Jan 2020 08:00:27 +0000 User-agent: mu4e 1.2.0; emacs 26.3
Timotej Lazar <address@hidden> writes:

> Thanks for the feedback! I am sending updated patches after this reply.
> Christopher Baines <address@hidden> [2020-01-25 09:16:08+0000]:
>> I did have a look if the package builds with the mbedtls-apache
>> package, rather than using the included source code, and it looks to.
>> Although I'm aware that [1] says there are modifications.
> The two Godot patches for mbedtls don’t seem to be relevant to Guix, so
> I replaced the bundled copy with the mbedtls-apache package. I don’t
> have a use case to test this, but the minimal example from the
> HTTPRequest tutorial seems to work OK with an HTTPS URI.

Wonderful :)

> Christopher Baines <address@hidden> [2020-01-25 09:18:33+0000]:
>> One thought I had here is that it would be more rigorous to have a list
>> of directories that are kept, and anything not on the list is deleted.
>> That way it's harder for new thirdparty dependencies to sneak in.
> Makes sense. As you suggest, I flipped the logic for removing thirdparty
> files: whitelist preserved files and remove everything else. The snippet
> can only preserve direct children of the thirdparty/ directory, which
> keeps it simple but perhaps not flexible enough in the long run.

Great, this looks really useful.

> Do we generally prefer whitelisting bundled files? Most packages I have
> seen (and written) do the opposite and list the files to remove. Maybe
> we could add a guideline somewhere? Or point me to the one I missed. :)

I don't know if it's written down somewhere, all I can say is it
occurred to me when looking at the package definition.

I've pushed the 3 latest patches you sent to master, so they're included
in 18f8e935e85a99d5c284c0a6b719351a402ada21.



Attachment: signature.asc
Description: PGP signature

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]