GNU bug report logs - #43348
Profanity

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 43348 in the body.
You can then email your comments to 43348 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: Raghav Gururajan <raghavgururajan <at> disroot.org>
To: guix-patches <at> gnu.org
Cc: dannym <at> scratchpost.org
Subject: Profanity
Date: Fri, 11 Sep 2020 15:52:23 -0400

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

Hello Guix!

Please find the attached patch to make changed to Profanity.

Regards,
RG.

[0004-gnu-profanity-Revise-package-definition.patch (text/x-patch, attachment)]

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

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

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Raghav Gururajan <raghavgururajan <at> disroot.org>
Cc: 43348 <at> debbugs.gnu.org
Subject: Re: Profanity
Date: Sat, 12 Sep 2020 02:51:38 +0200

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

Hi RG,

please, for existing packages, try to be as clear as possible in the commit
messages in what is changed (only one related set of things should be changed
per commit).

In this case the commit confounds things:

* Changing the build-system reference.  This does not enable runtime
features--which is what the commit message's topic stated that the commit does.
* Changing the autoconf method.  This does not enable runtime features--which
is what the commit message's topic stated that the commit does.
* Adding Python as a NATIVE input.  What is that about?  Is profanity using
a Python program as a compiler only?
* I think that moving those native-inputs to inputs, while correct, does not
enable runtime features--which is what the commit message's topic stated that
the commit does.
* Please use two spaces (after the period) in order to separate sentences.
* Moving blocks around makes review much harder for users.

The goal of those commit messages, and of the commit rules, is to make it
easy for each user to see at a glance what topic each commit changes.

[Message part 2 (application/pgp-signature, inline)]

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

From: Raghav Gururajan <raghavgururajan <at> disroot.org>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 43348 <at> debbugs.gnu.org
Subject: Re: Profanity
Date: Sun, 13 Sep 2020 00:38:02 -0400

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

Hi Danny!

> please, for existing packages, try to be as clear as possible in the commit
> messages in what is changed (only one related set of things should be changed
> per commit).
> 
> In this case the commit confounds things:
> 
> * Changing the build-system reference.  This does not enable runtime
> features--which is what the commit message's topic stated that the commit does.
> * Changing the autoconf method.  This does not enable runtime features--which
> is what the commit message's topic stated that the commit does.
> * Adding Python as a NATIVE input.  What is that about?  Is profanity using
> a Python program as a compiler only?
> * I think that moving those native-inputs to inputs, while correct, does not
> enable runtime features--which is what the commit message's topic stated that
> the commit does.
> * Please use two spaces (after the period) in order to separate sentences.
> * Moving blocks around makes review much harder for users.
> 
> The goal of those commit messages, and of the commit rules, is to make it
> easy for each user to see at a glance what topic each commit changes.

You are correct. I always do these in a hurry, sorry about that. Please
find the attached patches.

Regards,
RG.

[0001-gnu-profanity-Make-some-cosmetic-changes.patch (text/x-patch, attachment)]

[0002-gnu-profanity-Move-some-dependencies.patch (text/x-patch, attachment)]

[0003-gnu-profanity-Enable-missing-features.patch (text/x-patch, attachment)]

[0004-gnu-profanity-Change-build-system.patch (text/x-patch, attachment)]

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

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

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Raghav Gururajan <raghavgururajan <at> disroot.org>
Cc: 43348 <at> debbugs.gnu.org
Subject: Re: Profanity
Date: Sun, 13 Sep 2020 11:11:05 +0200

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

Hi RG,

thank you!  That's almost perfect.

I still don't get it why python-wrapper is a *native* input in order to support
Python plugins.  That would mean the Python plugins are only used at build time
and not used at runtime.  Is that correct?

[Message part 2 (application/pgp-signature, inline)]

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

From: Raghav Gururajan <raghavgururajan <at> disroot.org>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 43348 <at> debbugs.gnu.org
Subject: Re: Profanity
Date: Sun, 13 Sep 2020 05:12:04 -0400

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

Hi Danny!

> thank you!  That's almost perfect.

\o/ :-)

> I still don't get it why python-wrapper is a *native* input in order to support
> Python plugins.  That would mean the Python plugins are only used at build time
> and not used at runtime.  Is that correct?

As far as I understand, the package uses the python binary to compile a
component, which will be used to add/remove python plugins.

Regards,
RG.

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

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

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Raghav Gururajan <raghavgururajan <at> disroot.org>
Cc: 43348-done <at> debbugs.gnu.org
Subject: Re: Profanity
Date: Sun, 13 Sep 2020 11:54:26 +0200

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

Hi RG,

On Sun, 13 Sep 2020 05:12:04 -0400
Raghav Gururajan <raghavgururajan <at> disroot.org> wrote:

> > I still don't get it why python-wrapper is a *native* input in order to support
> > Python plugins.  That would mean the Python plugins are only used at build time
> > and not used at runtime.  Is that correct?  
> 
> As far as I understand, the package uses the python binary to compile a
> component, which will be used to add/remove python plugins.

I doubt it.

$ ./pre-inst-env guix gc --references `./pre-inst-env guix build profanity`
[...]
/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2

So it keeps a runtime reference to python.  I suspect it just embeds a Python
interpreter.  So it should probably be a regular input.
The question is whether the plugins written in Python actually work or not.
Usually they require some extra PYTHONPATH or whatever setting in order to
find stuff.  Just raw Python is often not enough.

But we'll see.

Moved python-wrapper to regular input.

Pushed patchset to master.

I edited the commit messages not to include internal rationale like that that
change is the correct change (for glib-or-gtk-build-system) or whatever.

If we need that it should go in the source code as a comment--where it can
be easily seen.

[Message part 2 (application/pgp-signature, inline)]

Previous Next

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