Hello,
On 2023/10/14 9:38, Greg Stein wrote:
On Fri, Oct 13, 2023 at 10:35 AM Stefan Sperling wrote:
On Fri, Oct 13, 2023 at 12:42:27AM -0500, Greg Stein wrote:
...
I have only seen cases where mailer.py is invoked with its command line
via a hook script.
Great situational feedback. Th
On Fri, Oct 13, 2023 at 10:35 AM Stefan Sperling wrote:
> On Fri, Oct 13, 2023 at 12:42:27AM -0500, Greg Stein wrote:
>
>...
> I have only seen cases where mailer.py is invoked with its command line
> via a hook script.
>
Great situational feedback. Thx.
> And I would say if anyone reached in
On Fri, Oct 13, 2023 at 12:42:27AM -0500, Greg Stein wrote:
> Hey all,
>
> So I'm looking at incorporating a couple key svn-mailer (by Andre Malo)
> features into mailer.py. Specifically, the body-length limit and mail
> encoding, and in turn deferring to viewvc links to replace what would be
> la
On Mon, Dec 21, 2020 at 07:15:53AM +, Daniel Shahaf wrote:
> s...@apache.org wrote on Mon, 14 Dec 2020 16:57 -:
> > URL: http://svn.apache.org/viewvc?rev=1884427&view=rev
> > Log:
> > Make mailer.py work properly with Python 3, and drop Python 2 support.
> >
> > Most of the changes deal wi
Yasuhito FUTATSUKI wrote on Wed, Dec 23, 2020 at 03:13:42 +0900:
> On 2020/12/21 16:15, Daniel Shahaf wrote:
> > s...@apache.org wrote on Mon, 14 Dec 2020 16:57 -:
> >> URL: http://svn.apache.org/viewvc?rev=1884427&view=rev
> >> Log:
> >> Make mailer.py work properly with Python 3, and drop Pyt
On 2020/12/21 16:15, Daniel Shahaf wrote:
> s...@apache.org wrote on Mon, 14 Dec 2020 16:57 -:
>> URL: http://svn.apache.org/viewvc?rev=1884427&view=rev
>> Log:
>> Make mailer.py work properly with Python 3, and drop Python 2 support.
>>
>> Most of the changes deal with the handling binary data
Yasuhito FUTATSUKI wrote on Thu, 09 Jan 2020 01:06 +00:00:
> (I'm sorry I cannot spare much time in this month later, so
> it is next month if I work for this issue...)
No worries; the bug has been there since time immemorial. There's no
urgency to fix it.
Cheers,
Daniel
On 2020/01/08 2:03, Daniel Shahaf wrote:
> Yasuhito FUTATSUKI wrote on Tue, Jan 07, 2020 at 06:52:20 +0900:
>> I found tools/hook-scripts/mailer/mailer.py can produce very long
>> subject header line without folding. It can be easily over 1000
>> characters [1] if some large source tree is imported
Yasuhito FUTATSUKI wrote on Wed, Jan 08, 2020 at 00:26:39 +0900:
> On 2020/01/07 9:41, Yasuhito FUTATSUKI wrote:
> > On 2020/01/07 6:52, Yasuhito FUTATSUKI wrote:
> >> By the way, it seems another issue about truncate_subject that current
> >> implementation of truncate_subject may break utf-8 mult
Yasuhito FUTATSUKI wrote on Tue, Jan 07, 2020 at 06:52:20 +0900:
> I found tools/hook-scripts/mailer/mailer.py can produce very long
> subject header line without folding. It can be easily over 1000
> characters [1] if some large source tree is imported in a repository
> and truncate_subject config
On 2020/01/07 9:41, Yasuhito FUTATSUKI wrote:
> On 2020/01/07 6:52, Yasuhito FUTATSUKI wrote:
>> By the way, it seems another issue about truncate_subject that current
>> implementation of truncate_subject may break utf-8 multi-bytes character
>> sequence, but I didn't reproduce it(because I always
On 2020/01/07 6:52, Yasuhito FUTATSUKI wrote:
> By the way, it seems another issue about truncate_subject that current
> implementation of truncate_subject may break utf-8 multi-bytes character
> sequence, but I didn't reproduce it(because I always use ascii
> characters only for file names...).
P
Troy Curtis Jr wrote on Sun, 11 Feb 2018 14:27 +:
> All this being said, I'm fine reverting the import swap if that is what is
> desired, as all indications are that it works either way now. I simply
> liked the communication of intent better with this order.
I think the primary reason for th
On Sun, Feb 11, 2018 at 2:38 AM Daniel Shahaf
wrote:
> Troy Curtis Jr wrote on Sun, 11 Feb 2018 02:28 +:
> > I committed the fix to the bindings in
> > https://svn.apache.org/viewvc?view=revision&revision=1823802 . In
> addition
> > to Kenneth's suggestion of opening in binary mode, I switch
Troy Curtis Jr wrote on Sun, 11 Feb 2018 02:28 +:
> I committed the fix to the bindings in
> https://svn.apache.org/viewvc?view=revision&revision=1823802 . In addition
> to Kenneth's suggestion of opening in binary mode, I switched the imports
> so that the python2-future's implementation woul
Troy Curtis Jr wrote on Sun, 11 Feb 2018 03:36 +:
> I believe that Subversion has an internal diff generation utility, could
> someone point me in the right direction?
tools/diff/diff
svn_diff_diff_2()
> I think just changing the implementation to using an internal diff
> would make this mor
On Sat, Feb 10, 2018 at 8:28 PM Troy Curtis Jr
wrote:
> On Thu, Feb 8, 2018 at 12:22 PM Kenneth Porter
> wrote:
>
>> On 2/8/2018 4:35 AM, Daniel Shahaf wrote:
>> > So, just to be clear, the problem is that svn/fs.py is not py3
>> > compatible, and having the 'builtins' module under py2 merely
>>
On Thu, Feb 8, 2018 at 12:22 PM Kenneth Porter
wrote:
> On 2/8/2018 4:35 AM, Daniel Shahaf wrote:
> > So, just to be clear, the problem is that svn/fs.py is not py3
> > compatible, and having the 'builtins' module under py2 merely
> > exposes that? I.e., we have no reason to suspect a bug in the
On 2/8/2018 4:35 AM, Daniel Shahaf wrote:
So, just to be clear, the problem is that svn/fs.py is not py3
compatible, and having the 'builtins' module under py2 merely
exposes that? I.e., we have no reason to suspect a bug in the 'future'
package's implementation of builtins.open() under py2.
T
Troy Curtis Jr wrote on Thu, 08 Feb 2018 03:29 +:
> but sure enough, a 'rpm -ql python2-future' reveals:
> ...
> /usr/lib/python2.7/site-packages/builtins
> ...
>
> That was certainly unexpected..and presumably a bad way to detect
> python3/python2. Though the case could be
> made that if the
On Wed, Feb 7, 2018 at 8:53 PM Kenneth Porter wrote:
> --On Thursday, February 08, 2018 2:30 AM + Troy Curtis Jr
> wrote:
>
> > If that package was being imported, I'd definitely expect that kind of
> > behavior, but merely it's presence on your system should not be enough to
> > actually ca
--On Thursday, February 08, 2018 2:30 AM + Troy Curtis Jr
wrote:
If that package was being imported, I'd definitely expect that kind of
behavior, but merely it's presence on your system should not be enough to
actually cause your python scripts to use the "future" behavior within
python 2.
--On Thursday, February 08, 2018 2:27 AM + Troy Curtis Jr
wrote:
I believe that Kenneth is actually referring to putting the type(fp) test
in svn/fs.py, where it is doing the prefixing internally, not that it is
leaking out into his application. I think he was simply trying to debug
our di
On Wed, Feb 7, 2018 at 11:54 AM Kenneth Porter
wrote:
> --On Wednesday, February 07, 2018 9:35 AM -0800 Kenneth Porter
> wrote:
>
> > So there's a builtins package hiding in this system somewhere.
>
> Found it. The system has the python2-future package which is a dependency
> of the certbot pack
On Wed, Feb 7, 2018 at 1:06 PM Daniel Shahaf wrote:
> Kenneth Porter wrote on Wed, 07 Feb 2018 09:35 -0800:
> > The overload of type was happening due to the unprefix stuff in fs.py.
> Red
> > herring, though interesting.
>
> This should only happen with 1.7 and earlier, see
> https://subversion.
Kenneth Porter wrote on Wed, 07 Feb 2018 09:35 -0800:
> The overload of type was happening due to the unprefix stuff in fs.py. Red
> herring, though interesting.
This should only happen with 1.7 and earlier, see
https://subversion.apache.org/docs/release-notes/1.8#swig-py-star
Cheers,
Daniel
--On Wednesday, February 07, 2018 9:35 AM -0800 Kenneth Porter
wrote:
So there's a builtins package hiding in this system somewhere.
Found it. The system has the python2-future package which is a dependency
of the certbot package. I think I got that from the epel repo.
Here's the metadata
The overload of type was happening due to the unprefix stuff in fs.py. Red
herring, though interesting.
I distilled the failure down to this foo.py program. Of interest is that
"import builtins" succeeds on a Python 2.5 system. It should be throwing
unless Python is v3. So there's a builtins p
Here's an interesting clue. I added "print type(fp)" after the temp file is
opened to see what kind of file object was returned by the open call and
got this traceback. How is the type function getting overloaded with
svn_fs_type? So far I haven't been able to recreate this with a short
hello-w
On 2/6/2018 7:56 PM, Troy Curtis Jr wrote:
Kenneth, I'm having trouble reproducing your issue. Any other hints
at what might causing the trouble in your environment that you can
think of? I've tried changing my locale, changing the files diffed to
being utf8, all with no luck. Regardless you
Proposed edit to fs.py: Change 'w+' to 'wb' when copying svn stream object
>> to temporary file. Update isn't needed, and the code just needs to dump
>> the
>> raw data into a file for the external diff to access, so no
>> encoding/decoding should occur. Hence we should open the file in binary
>> m
On Thu, Feb 1, 2018, 12:34 PM Kenneth Porter wrote:
> [moving discussion to dev list as I think this is now the correct fix.]
>
> --On Wednesday, January 31, 2018 7:40 PM -0800 Kenneth Porter
> wrote:
>
> > --On Wednesday, January 31, 2018 7:23 PM -0800 Kenneth Porter
> > wrote:
> >
> >> fp
[moving discussion to dev list as I think this is now the correct fix.]
--On Wednesday, January 31, 2018 7:40 PM -0800 Kenneth Porter
wrote:
--On Wednesday, January 31, 2018 7:23 PM -0800 Kenneth Porter
wrote:
fp = builtins.open(file, 'w+') # avoid namespace clash with
33 matches
Mail list logo
