GNU bug report logs -
#74133
Some minor patches for the python script
Previous Next
To reply to this bug, email your comments to 74133 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74133
; Package
emacs
.
(Thu, 31 Oct 2024 11:03:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 31 Oct 2024 11:03:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
From a quick discussion on IRC I've decided to contribute the
following two patches. The first is stylistic but the second is
something that was requested. Note that I've already assigned
copyright to the FSF for my contributions to Emacs.
Regards,
Nikolaos Chatzikonstantinou
[0002-download-zst-msys2-sources-before-gzip.patch.asc.asc (text/plain, attachment)]
[0002-download-zst-msys2-sources-before-gzip.patch.asc (text/plain, attachment)]
[0001-add-docstrings.patch.asc (text/plain, attachment)]
[0001-add-docstrings.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74133
; Package
emacs
.
(Thu, 31 Oct 2024 11:09:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 74133 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Is there ever a time where gpg does not embarass me?
Re-attaching the correct files...
Regards,
Nikolaos Chatzikonstantinou
[0002-download-zst-msys2-sources-before-gzip.patch.asc (text/plain, attachment)]
[0001-add-docstrings.patch (text/x-patch, attachment)]
[0002-download-zst-msys2-sources-before-gzip.patch (text/x-patch, attachment)]
[0001-add-docstrings.patch.asc (text/plain, attachment)]
Added tag(s) patch.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Fri, 01 Nov 2024 01:26:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74133
; Package
emacs
.
(Sat, 02 Nov 2024 13:07:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 74133 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> Date: Thu, 31 Oct 2024 07:06:54 -0400
>
> Is there ever a time where gpg does not embarass me?
>
> Re-attaching the correct files...
Corwin, are you looking at this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74133
; Package
emacs
.
(Sun, 03 Nov 2024 08:39:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 74133 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Yes, thank you.
On Sat, Nov 2, 2024, 08:05 Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> > Date: Thu, 31 Oct 2024 07:06:54 -0400
> >
> > Is there ever a time where gpg does not embarass me?
> >
> > Re-attaching the correct files...
>
> Corwin, are you looking at this?
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74133
; Package
emacs
.
(Sun, 10 Nov 2024 19:37:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 74133 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On Sat, Nov 2, 2024, 08:05 Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> Corwin, are you looking at this?
>>
Hi Nikolas,
Thank you very much for working on this. I suspect your code is good
- a big improvement.
Unfortunately, the local version that I have been using contains a
number of fixes that are lost when I apply your patches, some of which
are important, fixing issues that have been reported since the in-tree
version of build-dep-zips.py was last updated (for Emacs 28,
seemingly, but I'm not sure the currently in-tree version ever quite
worked for Emacs 28; certainly it does not for any newer version).
This is entirely my fault: I should have been pushing to get the
in-tree version in sync with what I have been using locally long
before this.
Even more embarrassingly, I'm not a strong enough python programmer to
puzzle out how to merge your changes in against mine. As I mentioned
when we chatted, my only python coding has been trying to keep this
program working enough to use it to produce new deps and dep-sources
archives in preparation for a new major version of Emacs. Left to my
own devices I would have replaced this script entirely given that
recent msys2 updates appear to have invalidated my work toward
introspecting (the just compiled) Emacs (replacing the hard-coded
DLL_REQ variable). As I'm sure you recall from our chat, we cannot
simply use ntdll because the majority of the dependencies are
"optional", being loaded at the run-time if available. Since upgrading
and updating my msys2 install I'm unable to find a way to launch the
Emacs compiled for Windows from the msys2 msys shell in which this
python script must run.
All of this said, I think your patches are in the right direction and
will greatly improve upon what we have. Thus, as the coup de gras of
this "pie-in-the-face" escapade, I must reward your hard work by
asking for harder and more tedious work still. I'm entirely open to
suggestions; the approach I'm prescribing defends against regressions
(loss of any fix introduced in the script by me but not pushed to
emacs.git that solved some problem we encountered) in consideration of
my ignorance of and discomfort with python.
I have attached the version of the script that (so far) appears
successful for the emacs-30.0.92 set of binaries. If you are willing,
I would like you to respin your patch against my version. To restate:
the in-tree version from which you based your patches does not work:
it will not run on current versions of msys2. If it did run, it would
produce results that would be both incorrect and incomplete. For that
reason, I don't believe it would be a problem to push the version
attached to emacs.git if that makes your work easier. Alternatively,
I believe you would be welcome to rewrite as much of the program as
you feel necessary, so long as we achieve identical results as I'm
able to get from the version I have attached to this message. I will
test your work by ensuring that your new/patched version outputs
archives are identical to those produced by mine, currently the top
two items in this listing:
https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30/?C=M;O=D
As far as I know, I'm the only regular user of this program - given
the brokenness I've described I'm fairly confident of that. Should
you be motivated toward further work on this, our goal will be fix
that - to enable others, by using this script, to more easily comply
with GPL when publishing their own builds of Emacs for Windows and to
more easily package "complete" Windows binaries distributions of Emacs
by using this "turn key" solution for collecting Emacs' dependencies
and their corresponding msys2 source archives.
Coming back to your patches, themselves, the one "note" I have is that
I would prefer not to omit the source-code comments (even where they
may be duplicative of the new docstrings you've suggested adding).
Again, thank you for your contribution and apologies for the various
of my failings that contribute to me being unable, simply, to push
them; I will certainly understand if you aren't inclined to invest
more time in this and would still welcome your comments and
suggestions regarding the best path forward (getting a working version
in-tree) in that event.
Warm regards,
Corwin
[build-dep-zips-30.0.92.py (text/plain, attachment)]
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 02 Jan 2025 02:11:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74133
; Package
emacs
.
(Thu, 13 Feb 2025 10:12:01 GMT)
Full text and
rfc822 format available.
Message #24 received at 74133 <at> debbugs.gnu.org (full text, mbox):
Corwin Brust <corwin <at> bru.st> writes:
>> On Sat, Nov 2, 2024, 08:05 Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>
>>> Corwin, are you looking at this?
>>>
>
> Hi Nikolas,
>
> Thank you very much for working on this. I suspect your code is good
> - a big improvement.
>
> Unfortunately, the local version that I have been using contains a
> number of fixes that are lost when I apply your patches, some of which
> are important, fixing issues that have been reported since the in-tree
> version of build-dep-zips.py was last updated (for Emacs 28,
> seemingly, but I'm not sure the currently in-tree version ever quite
> worked for Emacs 28; certainly it does not for any newer version).
> This is entirely my fault: I should have been pushing to get the
> in-tree version in sync with what I have been using locally long
> before this.
>
> Even more embarrassingly, I'm not a strong enough python programmer to
> puzzle out how to merge your changes in against mine. As I mentioned
> when we chatted, my only python coding has been trying to keep this
> program working enough to use it to produce new deps and dep-sources
> archives in preparation for a new major version of Emacs. Left to my
> own devices I would have replaced this script entirely given that
> recent msys2 updates appear to have invalidated my work toward
> introspecting (the just compiled) Emacs (replacing the hard-coded
> DLL_REQ variable). As I'm sure you recall from our chat, we cannot
> simply use ntdll because the majority of the dependencies are
> "optional", being loaded at the run-time if available. Since upgrading
> and updating my msys2 install I'm unable to find a way to launch the
> Emacs compiled for Windows from the msys2 msys shell in which this
> python script must run.
>
> All of this said, I think your patches are in the right direction and
> will greatly improve upon what we have. Thus, as the coup de gras of
> this "pie-in-the-face" escapade, I must reward your hard work by
> asking for harder and more tedious work still. I'm entirely open to
> suggestions; the approach I'm prescribing defends against regressions
> (loss of any fix introduced in the script by me but not pushed to
> emacs.git that solved some problem we encountered) in consideration of
> my ignorance of and discomfort with python.
>
> I have attached the version of the script that (so far) appears
> successful for the emacs-30.0.92 set of binaries. If you are willing,
> I would like you to respin your patch against my version. To restate:
> the in-tree version from which you based your patches does not work:
> it will not run on current versions of msys2. If it did run, it would
> produce results that would be both incorrect and incomplete. For that
> reason, I don't believe it would be a problem to push the version
> attached to emacs.git if that makes your work easier. Alternatively,
> I believe you would be welcome to rewrite as much of the program as
> you feel necessary, so long as we achieve identical results as I'm
> able to get from the version I have attached to this message. I will
> test your work by ensuring that your new/patched version outputs
> archives are identical to those produced by mine, currently the top
> two items in this listing:
>
> https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30/?C=M;O=D
>
> As far as I know, I'm the only regular user of this program - given
> the brokenness I've described I'm fairly confident of that. Should
> you be motivated toward further work on this, our goal will be fix
> that - to enable others, by using this script, to more easily comply
> with GPL when publishing their own builds of Emacs for Windows and to
> more easily package "complete" Windows binaries distributions of Emacs
> by using this "turn key" solution for collecting Emacs' dependencies
> and their corresponding msys2 source archives.
>
> Coming back to your patches, themselves, the one "note" I have is that
> I would prefer not to omit the source-code comments (even where they
> may be duplicative of the new docstrings you've suggested adding).
>
> Again, thank you for your contribution and apologies for the various
> of my failings that contribute to me being unable, simply, to push
> them; I will certainly understand if you aren't inclined to invest
> more time in this and would still welcome your comments and
> suggestions regarding the best path forward (getting a working version
> in-tree) in that event.
>
> Warm regards,
> Corwin
Nikolas, did you have a chance to look into the changes that Corwin
requested above? Thanks in advance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74133
; Package
emacs
.
(Thu, 13 Feb 2025 14:49:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 74133 <at> debbugs.gnu.org (full text, mbox):
On Thu, Feb 13, 2025 at 5:11 AM Stefan Kangas <stefankangas <at> gmail.com> wrote:
>
> Corwin Brust <corwin <at> bru.st> writes:
>
> >> On Sat, Nov 2, 2024, 08:05 Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>>
> >>> Corwin, are you looking at this?
> >>>
> >
> > Hi Nikolas,
> >
> > Thank you very much for working on this. I suspect your code is good
> > - a big improvement.
> >
> > Unfortunately, the local version that I have been using contains a
> > number of fixes that are lost when I apply your patches, some of which
> > are important, fixing issues that have been reported since the in-tree
> > version of build-dep-zips.py was last updated (for Emacs 28,
> > seemingly, but I'm not sure the currently in-tree version ever quite
> > worked for Emacs 28; certainly it does not for any newer version).
> > This is entirely my fault: I should have been pushing to get the
> > in-tree version in sync with what I have been using locally long
> > before this.
> >
> > Even more embarrassingly, I'm not a strong enough python programmer to
> > puzzle out how to merge your changes in against mine. As I mentioned
> > when we chatted, my only python coding has been trying to keep this
> > program working enough to use it to produce new deps and dep-sources
> > archives in preparation for a new major version of Emacs. Left to my
> > own devices I would have replaced this script entirely given that
> > recent msys2 updates appear to have invalidated my work toward
> > introspecting (the just compiled) Emacs (replacing the hard-coded
> > DLL_REQ variable). As I'm sure you recall from our chat, we cannot
> > simply use ntdll because the majority of the dependencies are
> > "optional", being loaded at the run-time if available. Since upgrading
> > and updating my msys2 install I'm unable to find a way to launch the
> > Emacs compiled for Windows from the msys2 msys shell in which this
> > python script must run.
> >
> > All of this said, I think your patches are in the right direction and
> > will greatly improve upon what we have. Thus, as the coup de gras of
> > this "pie-in-the-face" escapade, I must reward your hard work by
> > asking for harder and more tedious work still. I'm entirely open to
> > suggestions; the approach I'm prescribing defends against regressions
> > (loss of any fix introduced in the script by me but not pushed to
> > emacs.git that solved some problem we encountered) in consideration of
> > my ignorance of and discomfort with python.
> >
> > I have attached the version of the script that (so far) appears
> > successful for the emacs-30.0.92 set of binaries. If you are willing,
> > I would like you to respin your patch against my version. To restate:
> > the in-tree version from which you based your patches does not work:
> > it will not run on current versions of msys2. If it did run, it would
> > produce results that would be both incorrect and incomplete. For that
> > reason, I don't believe it would be a problem to push the version
> > attached to emacs.git if that makes your work easier. Alternatively,
> > I believe you would be welcome to rewrite as much of the program as
> > you feel necessary, so long as we achieve identical results as I'm
> > able to get from the version I have attached to this message. I will
> > test your work by ensuring that your new/patched version outputs
> > archives are identical to those produced by mine, currently the top
> > two items in this listing:
> >
> > https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30/?C=M;O=D
> >
> > As far as I know, I'm the only regular user of this program - given
> > the brokenness I've described I'm fairly confident of that. Should
> > you be motivated toward further work on this, our goal will be fix
> > that - to enable others, by using this script, to more easily comply
> > with GPL when publishing their own builds of Emacs for Windows and to
> > more easily package "complete" Windows binaries distributions of Emacs
> > by using this "turn key" solution for collecting Emacs' dependencies
> > and their corresponding msys2 source archives.
> >
> > Coming back to your patches, themselves, the one "note" I have is that
> > I would prefer not to omit the source-code comments (even where they
> > may be duplicative of the new docstrings you've suggested adding).
> >
> > Again, thank you for your contribution and apologies for the various
> > of my failings that contribute to me being unable, simply, to push
> > them; I will certainly understand if you aren't inclined to invest
> > more time in this and would still welcome your comments and
> > suggestions regarding the best path forward (getting a working version
> > in-tree) in that event.
> >
> > Warm regards,
> > Corwin
>
> Nikolas, did you have a chance to look into the changes that Corwin
> requested above? Thanks in advance.
I had forgotten, but I'm taking a look today. I'll try to contact
Corwin on IRC too.
Regards,
Nikolaos Chatzikonstantinou
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74133
; Package
emacs
.
(Thu, 13 Feb 2025 14:59:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 74133 <at> debbugs.gnu.org (full text, mbox):
Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> writes:
> I had forgotten, but I'm taking a look today. I'll try to contact
> Corwin on IRC too.
Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74133
; Package
emacs
.
(Thu, 13 Feb 2025 15:48:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 74133 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Feb 13, 2025 at 9:58 AM Stefan Kangas <stefankangas <at> gmail.com> wrote:
>
> Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> writes:
>
> > I had forgotten, but I'm taking a look today. I'll try to contact
> > Corwin on IRC too.
>
> Thanks!
Here's a patch that will download zst and if it fails it will download
tarball for *every archive* that download_sources() is used on.
Also Corwin let me know if you need something else, but I think this
is what we had discussed in the past.
Regards,
Nikolaos Chatzikonstantinou
[0001-download-zst-msys2-sources-before-gzip.patch (text/x-patch, attachment)]
This bug report was last modified 124 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.