From tsu.yubo at gmail.com  Fri Sep  9 02:29:21 2022
From: tsu.yubo at gmail.com (Bo YU)
Date: Fri, 9 Sep 2022 10:29:21 +0800
Subject: cgit build on riscv64 machine
In-Reply-To: <20220719101555.541fe80469a251350d237211@kodafritt.se>
References: <CAKq8=3+QN+j_4dkX0i2GY6yYq99T+ipR0rtvyatQ4cGcKkh7Qw@mail.gmail.com>
 <20220719093856.03adef0e08d4cb7364b9700f@kodafritt.se>
 <20220719080230.5avsx37o756ha6pv@debian>
 <20220719101555.541fe80469a251350d237211@kodafritt.se>
Message-ID: <20220909022921.yzgwbriypjiagl56@debian>

hi,
On Tue, Jul 19, 2022 at 10:15:55AM +0200, Samuel Lid?n Borell wrote:
>Hi,
>
>On Tue, 19 Jul 2022 16:02:30 +0800, Bo YU <tsu.yubo at gmail.com> wrote:
>
>> >Are you using qemu-user?
>>
>> It is interesting. In fact, I build it on real riscv64
>> hardware(Unmatched boards).
>>
>> ```
>> vimer at unmatched:~/build/07/31_cgit/cgit-master/tests$ uname -a
>> Linux unmatched 5.18.0-2-riscv64 #1 SMP Debian 5.18.5-1 (2022-06-16) riscv64 GNU/Linux
>> ```
>> >
>> >That test uses strace, which in turn uses the ptrace() system call.
>> >qemu-user does not support ptrace(). At least it didn't when I tried a couple of years ago.
>>
>> I just test strace cmd after see your hint, but it looks ok(If I do
>> wrong please conrect me)
>
>The strace output looks good to me. But did you check the strace.out file, that the test creates?
>The test will fail if it contains this string:
>/path/to/some/place/that/does/not/possibly/exist
>
>Maybe something is causing that string to be printed.

Maybe I did not get your point, but now some people submit a patch:
https://lists.debian.org/debian-riscv/2022/09/msg00009.html

Bo
>
>Best Regards,
>Samuel

-- 
Regards,
--
   Bo YU

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20220909/a8374cc5/attachment.sig>

From list at eworm.de  Fri Sep 16 09:33:48 2022
From: list at eworm.de (Christian Hesse)
Date: Fri, 16 Sep 2022 11:33:48 +0200
Subject: [PATCH 1/1] RFC: git: update to v2.38.0-rc0
Message-ID: <20220916093348.38423-1-list@eworm.de>

From: Christian Hesse <mail at eworm.de>

Update to git version v2.38.0-rc0, no additional changes required.

Signed-off-by: Christian Hesse <mail at eworm.de>
---
 Makefile | 4 ++--
 git      | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 6928e16..2f2600f 100644
--- a/Makefile
+++ b/Makefile
@@ -14,8 +14,8 @@ htmldir = $(docdir)
 pdfdir = $(docdir)
 mandir = $(prefix)/share/man
 SHA1_HEADER = <openssl/sha.h>
-GIT_VER = 2.37.3
-GIT_URL = https://www.kernel.org/pub/software/scm/git/git-$(GIT_VER).tar.xz
+GIT_VER = 2.38.0.rc0
+GIT_URL = https://www.kernel.org/pub/software/scm/git/testing/git-$(GIT_VER).tar.xz
 INSTALL = install
 COPYTREE = cp -r
 MAN5_TXT = $(wildcard *.5.txt)
diff --git a/git b/git
index ac8035a..d3fa443 160000
--- a/git
+++ b/git
@@ -1 +1 @@
-Subproject commit ac8035a2affdf30f2c691ad760826d955bba0507
+Subproject commit d3fa443f97e3a8d75b51341e2d5bac380b7422df
-- 
2.37.3


From valdis.vitolins at odo.lv  Fri Sep 16 19:55:39 2022
From: valdis.vitolins at odo.lv (=?UTF-8?B?VmFsZGlzIFbEq3RvbGnFhsWh?=)
Date: Fri, 16 Sep 2022 22:55:39 +0300
Subject: Downloading objects hangs up around 65kB
Message-ID: <0ef89b1e-6543-e726-2cf0-b68e7167fabe@odo.lv>

Probably it is issue on 64-bit ARM architecture, because I tested that 
it works on x86_64 virtual machine.

Some time ago (because I haven't used HTTPS protocol for repositories 
recently) downloading plain objects/blobs hangs up around 65kB of data.

You can test it with:

wget -O "01_About.odp" -d 
"https://odo.lv/git/JTM/plain/doc/presentations/01_About.odp"

It shows:
...
Saving to: ?01_About.odp?

01_About.odp                        8%[====>                           ] 
  63,64K  13,0KB/s    in 4,9s

2022-09-16 22:32:33 (13,0 KB/s) - Connection closed at byte 65169. Retrying.
...
etc.

Server architecture is 64-bit ARM:
uname -a
Linux odo 5.15.0-1019-aws #23~20.04.1-Ubuntu SMP Thu Aug 18 03:23:03 UTC 
2022 aarch64 aarch64 aarch64 GNU/Linux

Cgit package version:
cgit    1.2.3+git2.25.1-1

Apache version:
apache2 -v
Server version: Apache/2.4.41 (Ubuntu)
Server built:   2022-06-14T13:30:55

Sincerely,
Valdis

From grahamperrin at freebsd.org  Sat Sep 17 14:32:48 2022
From: grahamperrin at freebsd.org (Graham Perrin)
Date: Sat, 17 Sep 2022 15:32:48 +0100
Subject: Angle brackets - < and >
Message-ID: <8bd1288b-28b4-9000-1bde-37743bafe089@freebsd.org>

Hi

Commit messages 
<https://github.com/freebsd/freebsd-doc/commit/f814150c1af932259a239ad01c0237f58bdce402> 
and 
<https://github.com/freebsd/freebsd-doc/commit/9d5951404e425725a84265113abef1c3b2e86d91> 
appear OK.

In corresponding 
<https://cgit.freebsd.org/doc/commit/?id=f814150c1af932259a239ad01c0237f58bdce402> 
and 
<https://cgit.freebsd.org/doc/commit/?id=9d5951404e425725a84265113abef1c3b2e86d91>, 
it's as if the closing angle bracket is misinterpreted as part of the 
address.

Please, might this be a bug in cgit?

Reference:

RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax, Appendix C:

<https://datatracker.ietf.org/doc/html/rfc3986#appendix-C>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20220917/611be1de/attachment.sig>

From john at keeping.me.uk  Sat Sep 17 15:47:06 2022
From: john at keeping.me.uk (John Keeping)
Date: Sat, 17 Sep 2022 16:47:06 +0100
Subject: Angle brackets - < and >
In-Reply-To: <8bd1288b-28b4-9000-1bde-37743bafe089@freebsd.org>
References: <8bd1288b-28b4-9000-1bde-37743bafe089@freebsd.org>
Message-ID: <YyXr+pL5L6htt5z0@keeping.me.uk>

On Sat, Sep 17, 2022 at 03:32:48PM +0100, Graham Perrin wrote:
> Commit messages <https://github.com/freebsd/freebsd-doc/commit/f814150c1af932259a239ad01c0237f58bdce402>
> and <https://github.com/freebsd/freebsd-doc/commit/9d5951404e425725a84265113abef1c3b2e86d91>
> appear OK.
> 
> In corresponding <https://cgit.freebsd.org/doc/commit/?id=f814150c1af932259a239ad01c0237f58bdce402>
> and <https://cgit.freebsd.org/doc/commit/?id=9d5951404e425725a84265113abef1c3b2e86d91>,
> it's as if the closing angle bracket is misinterpreted as part of the
> address.
> 
> Please, might this be a bug in cgit?

Commit message formatting in CGit is extensible and the example filter
shipped with CGit does not do any URL detection, so cgit.freebsd.org
must be using their own filter.

I suggest you report a bug to them.


Regards,
John

From john at keeping.me.uk  Sat Sep 17 16:07:59 2022
From: john at keeping.me.uk (John Keeping)
Date: Sat, 17 Sep 2022 17:07:59 +0100
Subject: Downloading objects hangs up around 65kB
In-Reply-To: <0ef89b1e-6543-e726-2cf0-b68e7167fabe@odo.lv>
References: <0ef89b1e-6543-e726-2cf0-b68e7167fabe@odo.lv>
Message-ID: <YyXw33mpiGRmcfZO@keeping.me.uk>

On Fri, Sep 16, 2022 at 10:55:39PM +0300, Valdis V?toli?? wrote:
> Probably it is issue on 64-bit ARM architecture, because I tested that it
> works on x86_64 virtual machine.
> 
> Some time ago (because I haven't used HTTPS protocol for repositories
> recently) downloading plain objects/blobs hangs up around 65kB of data.
> 
> You can test it with:
> 
> wget -O "01_About.odp" -d
> "https://odo.lv/git/JTM/plain/doc/presentations/01_About.odp"
> 
> It shows:
> ...
> Saving to: ?01_About.odp?
> 
> 01_About.odp                        8%[====>                           ]
> 63,64K  13,0KB/s    in 4,9s
> 
> 2022-09-16 22:32:33 (13,0 KB/s) - Connection closed at byte 65169. Retrying.
> ...
> etc.

This seems very strange (it also happens with the .../tree/... pages
showing the hexdump file content).

My guess is that this is caused by the Apache configuration rather than
anything CGit is doing itself.

Have you tested running cgit outside Apache using something like:

	CGIT_CONFIG=/path/to/cgitrc \
	QUERY_STRING=url=JTM/plain/doc/presentations/01_About.odb \
	cgit

That should give some idea whether CGit itself is returning short data
or if the response is being truncated downstream.


Regards,
John

From valdis.vitolins at odo.lv  Sat Sep 17 20:04:55 2022
From: valdis.vitolins at odo.lv (=?UTF-8?B?VmFsZGlzIFbEq3RvbGnFhsWh?=)
Date: Sat, 17 Sep 2022 23:04:55 +0300
Subject: Downloading objects hangs up around 65kB
In-Reply-To: <YyXw33mpiGRmcfZO@keeping.me.uk>
References: <0ef89b1e-6543-e726-2cf0-b68e7167fabe@odo.lv>
 <YyXw33mpiGRmcfZO@keeping.me.uk>
Message-ID: <32098e9d-00dc-7bcb-e1e6-562c352846cc@odo.lv>

Thanks, John, for hints!

That allowed me to find this page:

https://blog.cryptomilk.org/2011/08/04/debugging-cgit/

And I got content returned with these settings (and had to run as root 
user):

CGIT_CONFIG=/etc/cgitrc \
QUERY_STRING="url=JTM/plain/doc/presentations/01_About.odp" \
/usr/lib/cgit/cgit.cgi 1>cgit.odt 2>cgit.log

cgit.log is empty and
cgit.odt is 713K file which starts with content:

X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none'
Content-Type: application/octet-stream
Content-Length: 729281
Content-Disposition: inline; filename="01_About.odp"
Last-Modified: Sat, 17 Sep 2022 19:48:19 GMT
Expires: Sat, 17 Sep 2022 19:53:19 GMT
ETag: "7048b4feba4cd80d4d56dcb3ea4b063c93b620bd"

P?CqR3&??/mimetypeapplication/vnd.oasis.opendocument.presentationP?CqRConfigurations2/toolbar/P?CqRConfigurations2/floater/P?CqRConfigurations2/menubar/P?CqR?Configurations2/popupmenu/P?CqRConfigurations2/progressbar/P?CqR?Configurations2/statusbar?CqR'Configurations2/accelerator/current.xmlPP?CqRConfigurations2/images/Bitmaps/P?CqR?Configurations2/toolpanel?CqR
...

So, it may be problem with apache. I have quite many of modules loaded 
for reverse proxy and and url and html link rewrites to shorten URL 
coming from XWiki content management system.

apachectl -M
Loaded Modules:
  core_module (static)
  so_module (static)
  watchdog_module (static)
  http_module (static)
  log_config_module (static)
  logio_module (static)
  version_module (static)
  unixd_module (static)
  access_compat_module (shared)
  alias_module (shared)
  auth_basic_module (shared)
  authn_core_module (shared)
  authn_file_module (shared)
  authz_core_module (shared)
  authz_host_module (shared)
  authz_user_module (shared)
  autoindex_module (shared)
  cache_module (shared)
  cache_disk_module (shared)
  cgi_module (shared)
  deflate_module (shared)
  dir_module (shared)
  env_module (shared)
  filter_module (shared)
  headers_module (shared)
  mime_module (shared)
  mpm_prefork_module (shared)
  negotiation_module (shared)
  php7_module (shared)
  proxy_module (shared)
  proxy_connect_module (shared)
  proxy_html_module (shared)
  proxy_http_module (shared)
  reqtimeout_module (shared)
  rewrite_module (shared)
  setenvif_module (shared)
  socache_shmcb_module (shared)
  ssl_module (shared)
  status_module (shared)
  xml2enc_module (shared)

Question is how I can debug it, knowing that this is production site and 
that I don't have much of experience debugging apache?

Valdis

> On Fri, Sep 16, 2022 at 10:55:39PM +0300, Valdis V?toli?? wrote:
>> Probably it is issue on 64-bit ARM architecture, because I tested that it
>> works on x86_64 virtual machine.
>>
>> Some time ago (because I haven't used HTTPS protocol for repositories
>> recently) downloading plain objects/blobs hangs up around 65kB of data.
>>
>> You can test it with:
>>
>> wget -O "01_About.odp" -d
>> "https://odo.lv/git/JTM/plain/doc/presentations/01_About.odp"
>>
>> It shows:
>> ...
>> Saving to: ?01_About.odp?
>>
>> 01_About.odp                        8%[====>                           ]
>> 63,64K  13,0KB/s    in 4,9s
>>
>> 2022-09-16 22:32:33 (13,0 KB/s) - Connection closed at byte 65169. Retrying.
>> ...
>> etc.
> 
> This seems very strange (it also happens with the .../tree/... pages
> showing the hexdump file content).
> 
> My guess is that this is caused by the Apache configuration rather than
> anything CGit is doing itself.
> 
> Have you tested running cgit outside Apache using something like:
> 
> 	CGIT_CONFIG=/path/to/cgitrc \
> 	QUERY_STRING=url=JTM/plain/doc/presentations/01_About.odb \
> 	cgit
> 
> That should give some idea whether CGit itself is returning short data
> or if the response is being truncated downstream.
> 
> 
> Regards,
> John

From peter at colberg.org  Sun Sep 18 00:40:59 2022
From: peter at colberg.org (Peter Colberg)
Date: Sat, 17 Sep 2022 20:40:59 -0400
Subject: [PATCH v1] tests: fix test_no_home_access on riscv64
Message-ID: <20220918004059.28596-1-peter@colberg.org>

On riscv64, access(2) does not exist and faccessat(2) is called with
the directory file descriptor set to AT_FDCWD, which behaves the
same as access(2). Trace access(2), faccessat(2), and faccessat2(2)
to ease porting to future architectures and do not fail if any of
these does not exist depending on architecture and kernel version.

Link: https://bugs.debian.org/1019369
Co-Developed-by: Sakura286 <chenxuan at iscas.ac.cn>
Co-Developed-by: Paul Wise <pabs at debian.org>
Signed-off-by: Peter Colberg <peter at colberg.org>
---
 tests/t0109-gitconfig.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/t0109-gitconfig.sh b/tests/t0109-gitconfig.sh
index 189ef28..f67f553 100755
--- a/tests/t0109-gitconfig.sh
+++ b/tests/t0109-gitconfig.sh
@@ -24,7 +24,8 @@ test_no_home_access () {
 		-E HOME="$non_existent_path" \
 		-E CGIT_CONFIG="$PWD/cgitrc" \
 		-E QUERY_STRING="url=$1" \
-		-e access -f -o strace.out cgit &&
+		-e '?access,?faccessat,?faccessat2' \
+		-f -o strace.out cgit &&
 	! grep "$non_existent_path" strace.out
 }
 
-- 
2.30.2


From list at eworm.de  Thu Sep 22 08:33:37 2022
From: list at eworm.de (Christian Hesse)
Date: Thu, 22 Sep 2022 10:33:37 +0200
Subject: [PATCH 1/1] RFC: git: update to v2.38.0-rc1
Message-ID: <20220922083337.49611-1-list@eworm.de>

From: Christian Hesse <mail at eworm.de>

Update to git version v2.38.0-rc1, no additional changes required.

Signed-off-by: Christian Hesse <mail at eworm.de>
---
 Makefile | 4 ++--
 git      | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 6928e16..51d049a 100644
--- a/Makefile
+++ b/Makefile
@@ -14,8 +14,8 @@ htmldir = $(docdir)
 pdfdir = $(docdir)
 mandir = $(prefix)/share/man
 SHA1_HEADER = <openssl/sha.h>
-GIT_VER = 2.37.3
-GIT_URL = https://www.kernel.org/pub/software/scm/git/git-$(GIT_VER).tar.xz
+GIT_VER = 2.38.0.rc1
+GIT_URL = https://www.kernel.org/pub/software/scm/git/testing/git-$(GIT_VER).tar.xz
 INSTALL = install
 COPYTREE = cp -r
 MAN5_TXT = $(wildcard *.5.txt)
diff --git a/git b/git
index ac8035a..1b3d6e1 160000
--- a/git
+++ b/git
@@ -1 +1 @@
-Subproject commit ac8035a2affdf30f2c691ad760826d955bba0507
+Subproject commit 1b3d6e17fe83eb6f79ffbac2f2c61bbf1eaef5f8
-- 
2.37.3


From grahamperrin at freebsd.org  Fri Sep 23 05:55:06 2022
From: grahamperrin at freebsd.org (Graham Perrin)
Date: Fri, 23 Sep 2022 06:55:06 +0100
Subject: Angle brackets - < and >
In-Reply-To: <YyXr+pL5L6htt5z0@keeping.me.uk>
References: <8bd1288b-28b4-9000-1bde-37743bafe089@freebsd.org>
 <YyXr+pL5L6htt5z0@keeping.me.uk>
Message-ID: <6a88fcac-f043-6c48-2f03-5aa2e1f65ea6@freebsd.org>

On 17/09/2022 16:47, John Keeping wrote:

> On Sat, Sep 17, 2022 at 03:32:48PM +0100, Graham Perrin wrote:
>> Commit messages 
>> <https://github.com/freebsd/freebsd-doc/commit/f814150c1af932259a239ad01c0237f58bdce402>
>> and 
>> <https://github.com/freebsd/freebsd-doc/commit/9d5951404e425725a84265113abef1c3b2e86d91>
>> appear OK.
>>
>> In corresponding 
>> <https://cgit.freebsd.org/doc/commit/?id=f814150c1af932259a239ad01c0237f58bdce402>
>> and 
>> <https://cgit.freebsd.org/doc/commit/?id=9d5951404e425725a84265113abef1c3b2e86d91>,
>> it's as if the closing angle bracket is misinterpreted as part of the
>> address.
>>
>> Please, might this be a bug in cgit?
> Commit message formatting in CGit is extensible and the example filter
> shipped with CGit does not do any URL detection, so cgit.freebsd.org
> must be using their own filter.
>
> I suggest you report a bug to them.
>
>
> Regards,
> John

Thank you.

 From a commit today, it seems that white space delimitation is 
similarly affected. FYI:

266473 ? cgit.freebsd.org breaks some links ? seems to not recognise 
some types of URI delimiter (RFC 3986)
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266473>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20220923/b3812be3/attachment.sig>