Re: [PATCH 1/1] RFC: git: update to v2.43.0-rc1
Christian Hesse wrote: > From: Christian Hesse > > Update to git version v2.43.0-rc1, no additional changes required. s/rc1/rc0 (or wait until tomorrow and update GIT_VER ;) Thanks for keeping things synced! > Signed-off-by: Christian Hesse > --- > Makefile | 4 ++-- > git | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/Makefile b/Makefile > index 3c080fc..9ca0446 100644 > --- a/Makefile > +++ b/Makefile > @@ -14,8 +14,8 @@ htmldir = $(docdir) > pdfdir = $(docdir) > mandir = $(prefix)/share/man > SHA1_HEADER = > -GIT_VER = 2.42.1 > -GIT_URL = https://www.kernel.org/pub/software/scm/git/git-$(GIT_VER).tar.xz > +GIT_VER = 2.43.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 61a22dd..bc52045 16 > --- a/git > +++ b/git > @@ -1 +1 @@ > -Subproject commit 61a22ddaf062693a17ac12f366bd6d167dff > +Subproject commit bc5204569f7db44d22477485afd52ea410d83743 -- Todd
Re: [PATCH 0/2] wiki: update some links and fix some formatting
Hi, I wrote: > I noticed a few of the URLs on the about page had grown stale. While I was > looking at the page, I noticed the git clone command didn't appear to be > indented as intended. > > Trivial fixes for both follow. Just a friendly ping on a topic for the wiki branch. :) -- Todd
Re: Version branches
Christian Hesse wrote: >> - ui-commit: show subject in page title > > No idea about this one. That appears to be: v1 <20200221234518.86715-1-june@causal.agency> v2 <20200223185227.89151-1-june@causal.agency> (w/sign-off) -- Todd signature.asc Description: PGP signature
[PATCH 2/2] index: avoid formatting issue in git clone instructions
The bulleted list which includes instructions for cloning cgit are intended to be formatted as: * clone the repo: * git clone https://git.zx2c4.com/cgit with the git clone command being a nested list. This does not work with markdown-python and instead is rendered as two separate bullet points. According to upstream¹: Python-Markdown consistently requires 4 spaces of indent per level or it ignores the indent While we could adjust the indent level, it seems cleaner to simply remove the nested list item for the git clone command and format it as code. ¹ https://github.com/Python-Markdown/markdown/issues/125#issuecomment-7210925 Signed-off-by: Todd Zullinger --- index | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/index b/index index 048ab05..2570c42 100644 --- a/index +++ b/index @@ -35,8 +35,7 @@ Features Source Code --- * download current or past [releases][] - * clone the repo: - * git clone https://git.zx2c4.com/cgit + * clone the repo: `git clone https://git.zx2c4.com/cgit` * see the [README][] for build instructions [releases]: /cgit/refs/tags -- 2.35.1
[PATCH 0/2] wiki: update some links and fix some formatting
Hi, I noticed a few of the URLs on the about page had grown stale. While I was looking at the page, I noticed the git clone command didn't appear to be indented as intended. Trivial fixes for both follow. Todd Zullinger (2): update Fedora & OS X package links, add OpenBSD index: avoid formatting issue in git clone instructions index | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) -- 2.35.1
[PATCH 1/2] update Fedora & OS X package links, add OpenBSD
Use the current URL's for the Fedora and OS X (Mac Ports) packages. Add a link to the OpenBSD ports tree. Expand the Fedora link to mention EPEL, which covers Alma Linux and Rocky Linux as well as RHEL and CentOS. This may help folks find us better if they're using a RHEL-8 rebuild like Alma or Rocky, now that CentOS Linux 8 is EOL. Signed-off-by: Todd Zullinger --- index | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/index b/index index 8ff5fce..048ab05 100644 --- a/index +++ b/index @@ -46,16 +46,18 @@ Packages * [Arch Linux][archlinux] * [Gentoo][gentoo] - * [Fedora/RHEL/CentOS][fedora] + * [Fedora/EPEL (RHEL/Alma/CentOS/Rocky)][fedora] * [OS X][macports] * [OpenSUSE][OpenSUSE] * [NetBSD][pkgsrc] * [FreeBSD][freshports] + * [OpenBSD][openbsd] [archlinux]:https://www.archlinux.org/packages/?name=cgit -[fedora]: https://apps.fedoraproject.org/packages/cgit +[fedora]: https://packages.fedoraproject.org/pkgs/cgit/cgit/ [gentoo]: https://packages.gentoo.org/packages/www-apps/cgit -[macports]: https://trac.macports.org/browser/trunk/dports/www/cgit +[macports]: https://ports.macports.org/port/cgit/ [opensuse]: https://software.opensuse.org/package/cgit [pkgsrc]: http://pkgsrc.se/www/cgit [freshports]: https://www.freshports.org/devel/cgit/ +[openbsd]: https://cvsweb.openbsd.org/ports/www/cgit/ -- 2.35.1
[PATCH] t0107: support older and/or non-GNU tar
The untar tests for various compression algorithms use shortcut options from GNU tar to handle decompression. These options may not be provided by non-GNU tar nor even by slightly older GNU tar versions which ship on many systems. An example of the latter case is the --zstd option. This was added in GNU tar-1.32 (2019-02-23)¹. This version of tar is not provided by CentOS/RHEL, in particular. In Debian, --zstd has been backported to the tar-1.30 release. Avoid the requirement on any specific implementations or versions of tar by piping decompressed output to tar. This is compatible with older GNU tar releases as well as tar implementations from other vendors. (It may also be a slight benefit that this more closely matches what the snapshot creation code does.) ¹ Technically, the --zstd option was first released in tar-1.31 (2019-01-02), but this release was very short-lived and is no longer listed on the GNU Tar release page. Signed-off-by: Todd Zullinger --- Hi, I'm sending again, in case the previous version which was in reply to the RFC/PATCH was simply not seen. It would be nice to get a fix to allow running the tests on systems which don't have tar >= 1.32 (or Debian-based syttems where the --zstd option was backported to 1.30). I'd also prefer to not carry it as a patch in the packages for Fedora's EPEL branches if I can avoid it. Thanks! tests/t0107-snapshot.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/t0107-snapshot.sh b/tests/t0107-snapshot.sh index c164d3e..8ea95ce 100755 --- a/tests/t0107-snapshot.sh +++ b/tests/t0107-snapshot.sh @@ -25,7 +25,7 @@ test_expect_success 'verify gzip format' ' test_expect_success 'untar' ' rm -rf master && - tar -xzf master.tar.gz + gzip -dc master.tar.gz | tar -xf - ' test_expect_success 'count files' ' @@ -67,7 +67,7 @@ test_expect_success LZIP 'verify lzip format' ' test_expect_success LZIP 'untar' ' rm -rf master && - tar --lzip -xf master.tar.lz + lzip -dc master.tar.lz | tar -xf - ' test_expect_success LZIP 'count files' ' @@ -109,7 +109,7 @@ test_expect_success XZ 'verify xz format' ' test_expect_success XZ 'untar' ' rm -rf master && - tar --xz -xf master.tar.xz + xz -dc master.tar.xz | tar -xf - ' test_expect_success XZ 'count files' ' @@ -151,7 +151,7 @@ test_expect_success ZSTD 'verify zstd format' ' test_expect_success ZSTD 'untar' ' rm -rf master && - tar --zstd -xf master.tar.zst + zstd -dc master.tar.zst | tar -xf - ' test_expect_success ZSTD 'count files' '
Re: [RFC/PATCH] t0107: support older tar in zstd untar test
Yesterday, I wrote: > Does cgit intend to require GNU tar? If not, perhaps we should instead > justify this primarily for compatibility with a wider range of tar > implementations in addition to supporting older versions of GNU tar? The more I thought about it, the more I liked that idea. It makes it simpler for new compression algorithms to re-use the tests for the existing algorithms. We could potentially even create a helper function to handle each compression algo. So here's that version in patch form. -- 8< -- Subject: [PATCH] t0107: support older and/or non-GNU tar The untar tests for various compression algorithms use shortcut options from GNU tar to handle decompression. These options may not be provided by non-GNU tar nor even by slightly older GNU tar versions which ship on many systems. An example of the latter case is the --zstd option. This was added in GNU tar-1.32 (2019-02-23)¹. This version of tar is not provided by CentOS/RHEL, in particular. In Debian, --zstd has been backported to the tar-1.30 release. Avoid the requirement on any specific implementations or versions of tar by piping decompressed output to tar. This is compatible with older GNU tar releases as well as tar implementations from other vendors. (It may also be a slight benefit that this more closely matches what the snapshot creation code does.) ¹ Technically, the --zstd option was first released in tar-1.31 (2019-01-02), but this release was very short-lived and is no longer listed on the GNU Tar release page. Signed-off-by: Todd Zullinger --- tests/t0107-snapshot.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/t0107-snapshot.sh b/tests/t0107-snapshot.sh index c164d3e..8ea95ce 100755 --- a/tests/t0107-snapshot.sh +++ b/tests/t0107-snapshot.sh @@ -25,7 +25,7 @@ test_expect_success 'verify gzip format' ' test_expect_success 'untar' ' rm -rf master && - tar -xzf master.tar.gz + gzip -dc master.tar.gz | tar -xf - ' test_expect_success 'count files' ' @@ -67,7 +67,7 @@ test_expect_success LZIP 'verify lzip format' ' test_expect_success LZIP 'untar' ' rm -rf master && - tar --lzip -xf master.tar.lz + lzip -dc master.tar.lz | tar -xf - ' test_expect_success LZIP 'count files' ' @@ -109,7 +109,7 @@ test_expect_success XZ 'verify xz format' ' test_expect_success XZ 'untar' ' rm -rf master && - tar --xz -xf master.tar.xz + xz -dc master.tar.xz | tar -xf - ' test_expect_success XZ 'count files' ' @@ -151,7 +151,7 @@ test_expect_success ZSTD 'verify zstd format' ' test_expect_success ZSTD 'untar' ' rm -rf master && - tar --zstd -xf master.tar.zst + zstd -dc master.tar.zst | tar -xf - ' test_expect_success ZSTD 'count files' ' -- Todd
[RFC/PATCH] t0107: support older tar in zstd untar test
The tar --zstd option was added in GNU tar-1.32 (2019-02-23)¹. Avoid the requirement on a (relatively) recent version of tar by piping the output of `zstd -dcf` to tar. As a real-world example, I ran into this test failure while building for CentOS/RHEL 8, which ships with tar-1.30. It may also be a slight benefit that this more closely matches what the snapshot creation code does, so arguably we could adjust the other tests to match. Alternately, we could add PREREQ's for the version of tar which adds the corresponding compression algorithm shortcut², but that seems like a bit of work for very little gain. And it differs (if only ever so slightly) from the pipe method we use to create the tar archives being tested. ¹ Technically, it was first released in tar-1.31 (2019-01-02), but this release was very short-lived and is no longer listed on the GNU Tar release page. ² The compression shortcuts for the 3 algorithms we have behind PREREQ's are --xz, --lzip, and --zstd. For reference, these were added to GNU Tar as follows: c10830a (Add xz support., 2009-03-04), tar-1.22 (2009-03-05) bffe107 (Add Lzip support, 2010-03-02), tar-1.23 (2010-03-10) 3d45373 (Add support for zstd compression, 2018-03-18), tar-1.32 (2019-02-23) Signed-off-by: Todd Zullinger --- Hi all, As I mentioned in the commit message, I ran into this test failure when I tried building for CentOS/RHEL 8. While this solves that particular issue, it did raise a few questions which I thought were worth answering before applying this patch as-is. Does cgit intend require GNU tar? If not, perhaps we should instead justify this primarily for compatibility with a wider range of tar implementations in addition to supporting older versions of GNU tar? (I haven't looked at or tested on systems which use a non-GNU tar, so there are posibly other issues with our tar invocations apart from these compression shortcut options. Finding and fixing that can be a #lefoverbit for anyone more familiar with such a system(s).) I'd be happy to make such an adjustment to the other tests and commit message(s). I think this would all fit nicely in a single commit, but I can split it in one for each of the three current compression algorithms which use the --$algo shortcuts if that's preferred. If we wanted to convert all the tests to use a decompress pipe into tar, I could do that instead. The latter would likely be less to ensure support for different tar implemtations and more for consistency in the test suite. Whether that's worth the churn is debatable. :) Thanks, tests/t0107-snapshot.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/t0107-snapshot.sh b/tests/t0107-snapshot.sh index c164d3e..5b5d727 100755 --- a/tests/t0107-snapshot.sh +++ b/tests/t0107-snapshot.sh @@ -151,7 +151,7 @@ test_expect_success ZSTD 'verify zstd format' ' test_expect_success ZSTD 'untar' ' rm -rf master && - tar --zstd -xf master.tar.zst + zstd -dcf master.tar.zst | tar -xf - ' test_expect_success ZSTD 'count files' ' -- Todd
Re: [ANNOUNCE] CGIT v1.2.1 Released
Hi Jason, Jason A. Donenfeld wrote: > Hi folks, > > CGit 1.2.1 is now available. It contains an important security fix and > everybody should update immediately. Yikes, thanks for the heads-up! Do you know if there is a CVE assigned for this issue yet? It sounds like it affects all releases from 0.8 through 1.2, right? Thanks, -- Todd ~~ The power of accurate observation is frequently called cynicism by those who don't have it. -- George Bernard Shaw signature.asc Description: PGP signature ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
Re: [PATCH] Update COPYING
The address of the Free Software Foundation has changed since the
license was added in 7640d90 ("Add license file and copyright notices",
2006-12-10). Update the license file from gnu.org¹.
The only non-whitespace changes are the updated FSF address and two
references to the L in LGPL changed from Library to Lesser.
¹ https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
Signed-off-by: Todd Zullinger
---
Hi,
I wrote:
> John Keeping wrote:
>> Missing sign-off.
>
> D'oh!
>
> Signed-off-by: Todd Zullinger
>
> Let me know if a resend is easier.
>
>> Acked-by: John Keeping
Here's a resend with the sign-off. Hopefully this can make
it into the 1.2 release.
COPYING | 39 +++
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/COPYING b/COPYING
index 5b6e7c6..d159169 100644
--- a/COPYING
+++ b/COPYING
@@ -1,12 +1,12 @@
- GNU GENERAL PUBLIC LICENSE
- Version 2, June 1991
+GNU GENERAL PUBLIC LICENSE
+ Version 2, June 1991
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
- 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
- Preamble
+Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
@@ -15,7 +15,7 @@ software--to make sure the software is free for all its
users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.) You can apply it to
+the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
@@ -55,8 +55,8 @@ patent must be licensed for everyone's free use or not
licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
-
- GNU GENERAL PUBLIC LICENSE
+
+GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
@@ -110,7 +110,7 @@ above, provided that you also meet all of these conditions:
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
-
+
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
@@ -168,7 +168,7 @@ access to copy from a designated place, then offering
equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
-
+
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
@@ -225,7 +225,7 @@ impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
-
+
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
@@ -255,7 +255,7 @@ make exceptions for this. Our decision will be guided by
the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
- NO WARRANTY
+NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
@@ -277,9 +277,9 @@ YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE
WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
-END OF TERMS AND CONDITIONS
-
- How to Apply These Terms to Your New Programs
+ END OF TERMS AND CONDITIONS
+
+How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way t
Re: [PATCH] Update COPYING
John Keeping wrote:
> On Sat, Jun 16, 2018 at 09:57:37PM -0400, Todd Zullinger wrote:
>> The address of the Free Software Foundation has changed since the
>> license was added in 7640d90 ("Add license file and copyright notices",
>> 2006-12-10). Update the license file from gnu.org¹.
>>
>> The only non-whitespace changes are the updated FSF address and two
>> references to the L in LGPL changed from Library to Lesser.
>>
>> ¹ https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
>
> Missing sign-off.
D'oh!
Signed-off-by: Todd Zullinger
Let me know if a resend is easier.
> Acked-by: John Keeping
Thanks,
--
Todd
~~
...more people are driven insane through religious hysteria than by
drinking alcohol.
-- W.C. Fields
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit
[PATCH] Update COPYING
The address of the Free Software Foundation has changed since the
license was added in 7640d90 ("Add license file and copyright notices",
2006-12-10). Update the license file from gnu.org¹.
The only non-whitespace changes are the updated FSF address and two
references to the L in LGPL changed from Library to Lesser.
¹ https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
---
This will help users & distributors who download & package cgit.
COPYING | 39 +++
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/COPYING b/COPYING
index 5b6e7c6..d159169 100644
--- a/COPYING
+++ b/COPYING
@@ -1,12 +1,12 @@
- GNU GENERAL PUBLIC LICENSE
- Version 2, June 1991
+GNU GENERAL PUBLIC LICENSE
+ Version 2, June 1991
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
- 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
- Preamble
+Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
@@ -15,7 +15,7 @@ software--to make sure the software is free for all its
users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.) You can apply it to
+the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
@@ -55,8 +55,8 @@ patent must be licensed for everyone's free use or not
licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
-
- GNU GENERAL PUBLIC LICENSE
+
+GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
@@ -110,7 +110,7 @@ above, provided that you also meet all of these conditions:
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
-
+
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
@@ -168,7 +168,7 @@ access to copy from a designated place, then offering
equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
-
+
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
@@ -225,7 +225,7 @@ impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
-
+
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
@@ -255,7 +255,7 @@ make exceptions for this. Our decision will be guided by
the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
- NO WARRANTY
+NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
@@ -277,9 +277,9 @@ YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE
WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
-END OF TERMS AND CONDITIONS
-
- How to Apply These Terms to Your New Programs
+ END OF TERMS AND CONDITIONS
+
+How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
@@ -303,10 +303,9 @@ the "copyright" line and a pointer to where the full
notice is found.
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
-You should have received a
Re: [RFC PATCH] Makefile: work around parallel make issues in docs
Hi, John Keeping wrote: > On Sat, Jun 16, 2018 at 12:32:06PM -0400, Todd Zullinger wrote: >> We might also want to drop 'doc-pdf' from the default 'doc' >> target. The alternative is driving the asciidoc pipeline >> for the pdf generation too. That looks a little more >> involved than doing it for html, but perhaps it's not as bad >> as I think. > > I think we can definitely drop doc-pdf from the default output. > > I'm half tempted to say we should just delete the PDF output completely > and see if anyone complains, unless you know of anyone using this? We don't generate the pdf docs for the Fedora/EPEL cgit builds and no one has yet filed a bug asking for it. Poking around, none of Arch, Debian, Gentoo, and Ubuntu build the pdf docs (in fact, they don't include the html target either). Maybe that's a good sign that the pdf target wouldn't be missed by many people. > Otherwise, the dependency on $(DOC_MAN5) seems reasonable > to me, probably accompanied with a comment explaining the > clash in a2x's intermediate files. Cool. I'll wait a bit and see if anyone chimes in with support for keeping the pdf target. If not, dropping it is the easier option. Thanks, -- Todd ~~ I dropped acid on a Saturday night Just to see what the fuss was about. Now there goes the neighborhood. ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
Re: [RFC PATCH] Makefile: work around parallel make issues in docs
Thomas Moschny wrote: > Todd Zullinger : > >> When make is run with multiple jobs, doc-man and doc-html fail. The >> a2x command tries to write %.5.xml for each invocation, overwriting >> each other. >> >> Work around this by copying %.5 to %.5+ in doc-man. This is a rather >> gross hack, but nothing better came to mind. Using --asciidoc-opts to >> pass the '--out-file' did not affect the temporary .xml file at issue. > > What about using a --destination-dir (-D) to a2x? It puts the > temporary .xml also into that dir. Something like this: > > diff --git a/Makefile b/Makefile > index 687069f..2ccee34 100644 > --- a/Makefile > +++ b/Makefile > @@ -131,7 +131,10 @@ doc-html: $(DOC_HTML) > doc-pdf: $(DOC_PDF) > > %.5 : %.5.txt > - a2x -f manpage $< > + mkdir $@.dir > + a2x -f manpage -D $@.dir $< > + mv $@.dir/$@ . > + rmdir $@.dir > > $(DOC_HTML): %.html : %.txt > a2x -f xhtml --stylesheet=cgit-doc.css --xsltproc-opts="--param > generate.consistent.ids 1" $< > > > One might want to additionally clean up the directory somewhere (as it > is not removed in case something goes wrong with the a2x call). Yeah, that's a nice solution too. Thanks! It's really a2x's fault for stripping the extension and replacing it with .xml rather than just appending .xml to the target name. (But perhaps someone on Windows doesn't want to see a temp file named .html.xml or something.) -- Todd ~~ A cynic is a man who, when he smells flowers, looks around for a coffin. -- H. L. Mencken ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
Re: [RFC PATCH] Makefile: work around parallel make issues in docs
Hi John, John Keeping wrote: > How about the patch below instead? It's a bigger change to the output > format for HTML, but as a side effect it fixes the parallel build. It does, but only if the targets are 'doc-man doc-html'. For the default 'doc' target which includes 'doc-pdf', the issue is still present. As a bonus, the output is much nicer, I think. We could perhaps work around the 'doc-pdf' failure by adding a dep on '($DOC_MAN5)': -- >8 -- diff --git i/Makefile w/Makefile index 70f32a4..4879a5a 100644 --- i/Makefile +++ w/Makefile @@ -143,7 +143,7 @@ $(DOC_HTML): %.html : %.txt $(TXT_TO_HTML) -o $@+ $< && \ mv $@+ $@ -$(DOC_PDF): %.pdf : %.txt +$(DOC_PDF): %.pdf : $(DOC_MAN5) %.txt a2x -f pdf cgitrc.5.txt clean: clean-doc -- >8 -- That's hackish, no doubt. We might also want to drop 'doc-pdf' from the default 'doc' target. The alternative is driving the asciidoc pipeline for the pdf generation too. That looks a little more involved than doing it for html, but perhaps it's not as bad as I think. At first I was concerned that this loses the xsltproc option to generate consistent id's in the html, but the html generated by asciidoc this way doesn't appear to suffer from the problem solved by that xsltproc option. :) Thanks, -- Todd ~~ Common sense is the collection of prejudices acquired by age eighteen. -- Albert Einstein ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
[RFC PATCH] Makefile: work around parallel make issues in docs
When make is run with multiple jobs, doc-man and doc-html fail. The a2x command tries to write %.5.xml for each invocation, overwriting each other. Work around this by copying %.5 to %.5+ in doc-man. This is a rather gross hack, but nothing better came to mind. Using --asciidoc-opts to pass the '--out-file' did not affect the temporary .xml file at issue. Signed-off-by: Todd Zullinger --- I ran into this in the Fedora/EPEL package builds long ago and set -j1 for the doc build at the time. I finally got around to looking a little deeper. I'm not happy with this patch, but as I said above, nothing better came to mind. I'm hoping that submitting this will spur some discussion about a better way to handle this. Though maybe the best way to handle it will be "don't build the docs in parallel, you're not saving any time for the single file that is built." :) That's effectively what I've done for ages, a separate 'make -j1 doc-man doc-html' invocation. Reproduction should be simple: make -j2 doc-man doc-html Each a2x process tries to create cgitrc.5.xml in the process of generating the man and html files, clobbering each other and causing xmllint to fail. This is still broken when calling 'make -j2 doc' as I only added the rename work-around to doc-man, so if doc-man, doc-html, and doc-pdf are all run, the two without the work-around will cause the same issue. I consider this more of a demonstration of the issue than a fix. I hope that by sending it, someone will respond with the obvious, elegant, and correct solution. Or maybe moments after I send it, that solution will come to me. Things often work out that way. :) Thanks, Todd Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 687069f..da36872 100644 --- a/Makefile +++ b/Makefile @@ -131,7 +131,9 @@ doc-html: $(DOC_HTML) doc-pdf: $(DOC_PDF) %.5 : %.5.txt - a2x -f manpage $< + cp -a $@.txt $@+.txt && \ + a2x -f manpage $@+.txt && \ + rm -f $@+.txt $(DOC_HTML): %.html : %.txt a2x -f xhtml --stylesheet=cgit-doc.css --xsltproc-opts="--param generate.consistent.ids 1" $< ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
[PATCH] doc: use consistent id's when generating html files
The html documentation is generated using a2x which calls docbook tools to do the work. The generate.consistent.ids parameter ensures that when the docbook stylesheet assigns an id value to an output element it is consistent as long as the document structure has not changed. Having consistent html files reduces frivolous changes between builds. Distributions can more easily deploy multiple architecture builds and compare changes between package versions. End-users avoid needless changes in files deployed or backed up. The generate.consistent.ids parameter was added in docbook-xsl-1.77.0. Older versions gracefully ignore the parameter, so we can pass the parameter unconditionally. Most distributions contain docbook-xsl newer than 1.77.0. This includes Fedora, Debian, Ubuntu, and RHEL/CentOS 7. RHEL/CentOS 6 and Debian Wheezy (old stable) ship with an older version, unsurprisingly. Signed-off-by: Todd Zullinger <t...@pobox.com> --- I wrote: > Jason A. Donenfeld wrote: >> Seems reasonable to me. Can you resubmit with your `Signed-off-by:`? > > D'oh! > > I meant to check that I had the sign-off and managed to get > sidetracked before sending. Signed-off-by: Scatterbrain. ;) There was supposed to be a proper signoff on that reply. Scatterbrain was only meant to be a joke. Third time's a charm, hopefully. I'll really feel dumb if I forget it one more time. :/ Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 8321ecc..687069f 100644 --- a/Makefile +++ b/Makefile @@ -134,7 +134,7 @@ doc-pdf: $(DOC_PDF) a2x -f manpage $< $(DOC_HTML): %.html : %.txt - a2x -f xhtml --stylesheet=cgit-doc.css $< + a2x -f xhtml --stylesheet=cgit-doc.css --xsltproc-opts="--param generate.consistent.ids 1" $< $(DOC_PDF): %.pdf : %.txt a2x -f pdf cgitrc.5.txt -- 2.16.2 -- Todd ~~ When buying and selling are controlled by legislation, the first things to be bought and sold are legislators. -- P.J. O'Rourke ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
[PATCH/wiki] Update Fedora package link
Also note that packages for RHEL/CentOS can be found at the same location. Signed-off-by: Todd Zullinger <t...@pobox.com> --- I've had this laying around in my tree for a while. The Fedora link was broken when the pkgdb app was retired. The pkgdb app is dead, long live the packages app (we hope ;). index | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index b/index index 3176d46..0dd3fbe 100644 --- a/index +++ b/index @@ -46,13 +46,13 @@ Packages * [Arch Linux][archlinux] * [Gentoo][gentoo] - * [Fedora][fedora] + * [Fedora/RHEL/CentOS][fedora] * [OS X][macports] * [OpenSUSE][OpenSUSE] * [NetBSD][pkgsrc] [archlinux]:https://www.archlinux.org/packages/?name=cgit -[fedora]: https://admin.fedoraproject.org/pkgdb/acls/name/cgit +[fedora]: https://apps.fedoraproject.org/packages/cgit [gentoo]: http://packages.gentoo.org/package/www-apps/cgit [macports]: http://trac.macports.org/browser/trunk/dports/www/cgit [opensuse]: https://build.opensuse.org/package/show?package=cgit=devel%3Atools%3Ascm -- 2.16.2 ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
[PATCH] doc: use consistent id's when generating html files
The html documentation is generated using a2x which calls docbook tools to do the work. The generate.consistent.ids parameter ensures that when the docbook stylesheet assigns an id value to an output element it is consistent as long as the document structure has not changed. Having consistent html files reduces frivolous changes between builds. Distributions can more easily deploy multiple architecture builds and compare changes between package versions. End-users avoid needless changes in files deployed or backed up. The generate.consistent.ids parameter was added in docbook-xsl-1.77.0. Older versions gracefully ignore the parameter, so we can pass the parameter unconditionally. Most distributions contain docbook-xsl newer than 1.77.0. This includes Fedora, Debian, Ubuntu, and RHEL/CentOS 7. RHEL/CentOS 6 and Debian Wheezy (old stable) ship with an older version, unsurprisingly. --- Jason A. Donenfeld wrote: > Seems reasonable to me. Can you resubmit with your `Signed-off-by:`? D'oh! I meant to check that I had the sign-off and managed to get sidetracked before sending. Signed-off-by: Scatterbrain. ;) Thanks! Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 8321ecc..687069f 100644 --- a/Makefile +++ b/Makefile @@ -134,7 +134,7 @@ doc-pdf: $(DOC_PDF) a2x -f manpage $< $(DOC_HTML): %.html : %.txt - a2x -f xhtml --stylesheet=cgit-doc.css $< + a2x -f xhtml --stylesheet=cgit-doc.css --xsltproc-opts="--param generate.consistent.ids 1" $< $(DOC_PDF): %.pdf : %.txt a2x -f pdf cgitrc.5.txt -- 2.16.2 -- Todd ~~ Philosophy, n. A route of many roads leading from nowhere to nothing. -- Ambrose Bierce, "The Devil's Dictionary" ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
[PATCH] doc: use consistent id's when generating html files
The html documentation is generated using a2x which calls docbook tools to do the work. The generate.consistent.ids parameter ensures that when the docbook stylesheet assigns an id value to an output element it is consistent as long as the document structure has not changed. Having consistent html files reduces frivolous changes between builds. Distributions can more easily deploy multiple architecture builds and compare changes between package versions. End-users avoid needless changes in files deployed or backed up. The generate.consistent.ids parameter was added in docbook-xsl-1.77.0. Older versions gracefully ignore the parameter, so we can pass the parameter unconditionally. Most distributions contain docbook-xsl newer than 1.77.0. This includes Fedora, Debian, Ubuntu, and RHEL/CentOS 7. RHEL/CentOS 6 and Debian Wheezy (old stable) ship with an older version, unsurprisingly. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 8321ecc..687069f 100644 --- a/Makefile +++ b/Makefile @@ -134,7 +134,7 @@ doc-pdf: $(DOC_PDF) a2x -f manpage $< $(DOC_HTML): %.html : %.txt - a2x -f xhtml --stylesheet=cgit-doc.css $< + a2x -f xhtml --stylesheet=cgit-doc.css --xsltproc-opts="--param generate.consistent.ids 1" $< $(DOC_PDF): %.pdf : %.txt a2x -f pdf cgitrc.5.txt -- 2.16.2 ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
Re: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
John Keeping wrote: On Sat, Mar 07, 2015 at 06:35:10PM -0500, Todd Zullinger wrote: But while we're on the subject, are there PGP signatures available for the cgit tarballs themselves? I know the git tags are signed, but I don't think I've seen detached signatures for the tarballs. In this case, how does a user become happy that the CGit distribution they have is trustworthy? The cgit tarball download isn't available via https either, which might be a reasonable answer in the absence of a detached git signature. Without a signature on the tarball or some other method to verify the cgit tarball, the sha256 of the git tarball included in the cgit Makefile is more or less only useful as a basic download integrity check (in which case sha256 is mild overkill). None of this is to say that this patch isn't a step in the right direction. It certainly helps to display a nicer error message if a user receives a corrupted git tarball. It's just important that users don't confuse this with providing any real authentication of the git tarball. I'm not sure this is true. Providing that the CGit tarball is trusted, then I think this does provide sufficient authentication of the Git tarball. If the CGit tarball isn't trusted, then all bets are off anyway. Agreed. The caveat is that I'm not sure there is a convenient method for end-users or packagers to verify the authenticity of a cgit tarball. Those on the list can check the PGP signature on the announcement mail and then use the included SHA1 to check the tarball, but doing that as a non-list member isn't as easy due to many list archives stripping or mangling PGP signatures. I tried doing this with the 0.11 announcement from the Mailman and Gmane archives now and wasn't successful. Posting a detached PGP signature for the tarball would improve the ability for users to trust and verify the cgit tarball. It's not a blocker for your patch, but it would make it significantly more useful, so I thought I would broach the subject. ;) Thank you for all of your work on cgit. It's very nice to see it continue to improve, with even the smallest details getting attention. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Now don't say you can't swear off drinking; it's easy. I've done it a thousand times. -- W.C. Fields ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading
Jason A. Donenfeld wrote: On Mar 8, 2015 12:35 AM, Todd Zullinger t...@pobox.com wrote: But while we're on the subject, are there PGP signatures available for the cgit tarballs themselves? I include a sha256 of the tarball in the announcement emails. Those emails are pgp signed. My pgp key is embedded in the repo, as well, and it's verifiable that all announce emails have been signed with the same key. (It's a SHA1, isn't it? Not that I care terribly about that part, other than a general preference for SHA256. :) More importantly is that verifying the PGP signature from an archive is not always easy. More often than not, list archives introduce subtle whitespace damage or worse. The other point that John made is more interesting. If cgit generates a tarball on demand, aren't there opportunities for the hash in the announcement mail (or a detactch signature) to become invalid? I belive that git archive has made changes in the past to avoid including the timestamp in the gzip archive, which helps. I don't know if there are other ways this could change. In the end, I don't know if it's a problem that can be solved in a way that doesn't cause more work for you as a maintainer or the other fine folks who are contributing. That's certainly not my intention. ;) On Mar 9, 2015 9:49 PM, John Keeping j...@keeping.me.uk wrote: It turns out that GMane mangles the list address in the message, Better archives: http://lists.zx2c4.com/pipermail/cgit/ I tried that earlier, before posting and found that it munges things too. Mailman's munging is often due to whitespace changes and are hard to avoid. Maybe the change to hyperkitty in Mailman 3 will improve this aspect of the archives. ;) -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Damn you and your estrogenical treachery! -- Stewie Griffin ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
