Bug 286828 - www/gitea: update 1.23.6 --> 1.23.8 and update WWW
Summary: www/gitea: update 1.23.6 --> 1.23.8 and update WWW
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Vladimir Druzenko
URL:
Keywords: buildisok, easy
Depends on:
Blocks:
 
Reported: 2025-05-16 07:19 UTC by Chris Hutchinson
Modified: 2025-05-23 02:12 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (stb)
vvd: merge-quarterly?


Attachments
patch updates www/gitea tp 1.23.8 (3.25 KB, patch)
2025-05-16 07:19 UTC, Chris Hutchinson
no flags Details | Diff
patch against www/gitea version 2 (3.05 KB, patch)
2025-05-17 05:05 UTC, Chris Hutchinson
no flags Details | Diff
patch for www/gitea version 3 (2.93 KB, patch)
2025-05-18 01:58 UTC, Chris Hutchinson
no flags Details | Diff
patch for www/gitea version 4 (3.28 KB, patch)
2025-05-18 02:08 UTC, Chris Hutchinson
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Hutchinson 2025-05-16 07:19:54 UTC
Created attachment 260438 [details]
patch updates www/gitea tp 1.23.8

The patch attached to this pr(1) updates www/gitea
from 1.23.6 to 1.23.8 and updates WWW.
While here, convert to GitHub framework and cleanup
Makefile.

Changes:
Makefile
distinfo

build/install tests return OK
port(lint|fmt|clippy) return OK

That's it. :)
Comment 1 Vladimir Druzenko freebsd_committer freebsd_triage 2025-05-16 11:41:47 UTC
> convert to GitHub framework
Why? GitHub framework used only if upstream does not provide release tarball.
Comment 3 Chris Hutchinson 2025-05-16 19:11:41 UTC
(In reply to Vladimir Druzenko from comment #1)
>> convert to GitHub framework
> Why? GitHub framework used only if upstream does not provide release tarball.
I chose it because it achieves the same results
and makes the Makefile cleaner. :)
Comment 4 Vladimir Druzenko freebsd_committer freebsd_triage 2025-05-17 00:11:38 UTC
(In reply to Chris Hutchinson from comment #3)
The porter's handbook recommends using the upstream tarball instead of the github framework.
Upstream may do some extra work to prepare the release.
Comment 5 Chris Hutchinson 2025-05-17 01:46:38 UTC
(In reply to Vladimir Druzenko from comment #4)
In my humble defense. I used the porters handbook.
example #12. I'm not trying to be argumentative. :)
...
PORTNAME=	foo
DISTVERSIONPREFIX=	v
DISTVERSION=	1.0.2

USE_GITHUB=	yes
> It will automatically set GH_TAGNAME to v1.0.2,
____________________________^^^^^^^^^^^^^^^^^^^^
> while WRKSRC will be kept to ${WRKDIR}/foo-1.0.2.
I necessarily added:
GH_ACCOUNT=
as GitHub (and the ports framework) wouldn't otherwise
know what I was after. :)
This, as the documentation indicates, tells GitHub
to give us the TAG (tarball) we're after.

I'm not able to find where you're telling me I should
otherwise be looking.
Comment 6 Vladimir Druzenko freebsd_committer freebsd_triage 2025-05-17 02:54:52 UTC
(In reply to Chris Hutchinson from comment #5)
https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github
> If the distribution file comes from a specific commit or tag on GitHub for which there is no officially released file,
> there is an easy way to set the right DISTNAME and MASTER_SITES automatically.
"If no officially released file".
> Warning
> As of 2023-02-21 GitHub have announced that source downloads will be stable for a year.
> Please switch to release assets and if not available ask upstream to generate ones.
This is the second reason why it is preferable to use a release tarball made by upstream rather than by github framework.
Comment 7 Chris Hutchinson 2025-05-17 03:34:15 UTC
(In reply to Vladimir Druzenko from comment #6)
D'OH! That should probably be in the color red. :)
Sadly, that makes most of the examples pointless,
and in less than a year, potentially, all of them. :(
I'll whip up a new patch shortly.

Thanks! :)
Comment 8 Chris Hutchinson 2025-05-17 05:05:24 UTC
Created attachment 260467 [details]
patch against www/gitea version 2

OK this one works as expected/intended. This source
doesn't build as happily as the source I targeted.
But the end result is the same. The problem with *this*
source, is that they try and trick the sources with a
symlink(2) in ${WRKSRC}/src that points to ${WRKDIR}/gitea. :(

If this were my port, I might poke at it a bit. But I'm
out of cycles for this. Just trying to help. :)

Thanks!
Comment 9 Vladimir Druzenko freebsd_committer freebsd_triage 2025-05-17 14:13:38 UTC
Port require go 1.23.8, but ports have 1.23.7 only - can't build in poudriere:
===>   gitea-1.23.8 depends on file: /usr/local/bin/go123 - not found
===>   Installing existing package /packages/All/go123-1.23.7_4.pkg
…
===>  Building for gitea-1.23.8
gmake: git: No such file or directory
go: downloading go1.23.8 (freebsd/amd64)
go: download go1.23.8: golang.org/toolchain@v0.0.1-go1.23.8.freebsd-amd64: Get "https://proxy.golang.org/golang.org/toolchain/@v/v0.0.1-go1.23.8.freebsd-amd64.zip": dial tcp: lookup proxy.golang.org on 10.0.0.1:53: write udp 127.0.0.1:26068->10.0.0.1:53: write: permission denied
Gitea requires Go 1.23 or greater to build. You can get it at https://go.dev/dl/
gmake: *** [Makefile:259: go-check] Error 1
*** Error code 1
Comment 10 Chris Hutchinson 2025-05-17 21:14:11 UTC
> gmake: git: No such file or directory
This was the only message I experienced when I build/
tested this. Which is what I was referring to in my
last message.
However. In spite of that, it continued to build/stage
without incident.
I'll see if I can reproduce what you experienced. It
would appear to be a transient uplink problem -- vpn
or (home computer?) :O
Comment 11 Vladimir Druzenko freebsd_committer freebsd_triage 2025-05-17 21:27:43 UTC
(In reply to Chris Hutchinson from comment #10)
In poudriere during build no access to network.
This update requires update port lang/go123 at least to 1.23.8.
Comment 12 Chris Hutchinson 2025-05-18 01:58:43 UTC
Created attachment 260496 [details]
patch for www/gitea version 3

OK. Decided to test against go 1.24.3. All went as
one would hope. But doing that revealed a warn for
unstripped files. I'll whip up a patch for lang/go124 next.

Third times a charm. Sigh...
Comment 13 Chris Hutchinson 2025-05-18 02:08:40 UTC
Created attachment 260497 [details]
patch for www/gitea version 4

Sorry. Too many interruptions. Let's use
this one.
Comment 14 Vladimir Druzenko freebsd_committer freebsd_triage 2025-05-20 18:36:41 UTC
(In reply to Chris Hutchinson from comment #13)
Build fine with go:1.24.
Did you tested runtime?

About merge-quarterly:
1. Update have security fixes - we must do merge-quarterly.
2. In main branch go124 is 1.24.3, but in 2025Q2 go124 is 1.24.1 - there are concerns about the port's functionality with an older version of go124.
I don't have the ability/resources to quickly do such testing.
Comment 16 Chris Hutchinson 2025-05-20 20:31:06 UTC
(In reply to Vladimir Druzenko from comment #14)
My testbed is at 14.3b1 cut @ 05-02. Which WFM.
See also bug #286921 for the patch I created against
lang/go124. Which I used for this build.

Thanks!
Comment 17 Chris Hutchinson 2025-05-21 18:45:42 UTC
> 2. In main branch go124 is 1.24.3, but in 2025Q2 go124 is 1.24.1
> - there are concerns about the port's functionality with an older
> version of go124. I don't have the ability/resources to quickly
> do such testing.
This commit just landed this morning:
https://cgit.freebsd.org/ports/commit/?id=8cb04a4d7a4e76c9ffcb71a50aa73e64712ffc59

excerpt:
defaults: Change Go default to 1.24
There's a lot that's happening in Go town. All Go versions can build any
other Go version, so individual Go ports are irrelevant.
There's no longer any point to having multiple Go versions. On paper,
...

I think we're good to go here. :)
Comment 18 Chris Hutchinson 2025-05-21 19:35:11 UTC
See also: review D49906 and bug #286214
Comment 19 Vladimir Druzenko freebsd_committer freebsd_triage 2025-05-22 19:44:34 UTC
(In reply to Chris Hutchinson from comment #17)
I saw this commit and wanted to write about it here, but I was busy at work.
And when I was free, you were already ahead of me. :-D

I'll commit it now as "Fix security issues", but I'll leave the merge-quarterly to the maintainer's discretion if you can't check the runtime of the build using go 1.24.1 yourself.
Comment 20 commit-hook freebsd_committer freebsd_triage 2025-05-22 20:03:21 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=4a4015c6e349864b1f35a5b7a44dba55a117d689

commit 4a4015c6e349864b1f35a5b7a44dba55a117d689
Author:     Chris Hutchinson <portmaster@bsdforge.com>
AuthorDate: 2025-05-22 19:48:17 +0000
Commit:     Vladimir Druzenko <vvd@FreeBSD.org>
CommitDate: 2025-05-22 20:00:48 +0000

    www/gitea: update 1.23.6 => 1.23.8 (fix security issues)

    Security:
    - Fixed a bug when uploading files via the LFS SSH command
      (affects 1.23)
    - Resolved CVE-2025-22873 in the Go os package, which previously
      allowed improper access to parent directories under certain conditions

    Release notes:
    https://blog.gitea.com/release-of-1.23.7/
    https://blog.gitea.com/release-of-1.23.8/

    Changelogs:
    https://github.com/go-gitea/gitea/releases/tag/v1.23.7
    https://github.com/go-gitea/gitea/releases/tag/v1.23.8

    While here improve port:
     - remove go version after default go version was increased to 1.24
     - update WWW
     - align options

    PR:             286828
    Approved by:    Stefan Bethke <stb@lassitu.de> (maintainer, implicit - fix security issues)
    Security:       CVE-2025-22873

 www/gitea/Makefile | 17 ++++++++---------
 www/gitea/distinfo |  6 +++---
 2 files changed, 11 insertions(+), 12 deletions(-)
Comment 21 Chris Hutchinson 2025-05-23 02:12:49 UTC
(In reply to Vladimir Druzenko from comment #19)
Hah! I *too* was going to make a change today. But you
beat me to it:
-USES=		cpe gmake go:1.23,no_targets
+USES=		cpe gmake go:no_targets

Thank you! :)

I have an opportunity to test against releng-(13|14|15)
tonight. I'll report my findings tonight|tomorrow.

Thanks again, Vladimir! :)