Re: Gitea 1.20.0

2023-07-24 Thread Stuart Henderson 
On 2023/07/24 11:49, Stuart Henderson wrote:
> On 2023/07/24 13:45, Pavel Korovin wrote:
> > Gitea is a go binary, so in most cases the old package won't become
> > non-functional very soon.
> 
> It already did for machines with IBT.

(not affecting people who are already up-to-date on -current, but will
affect people moving from.older -current or 7.3).

Re: Gitea 1.20.0

2023-07-24 Thread Stuart Henderson 
On 2023/07/24 13:45, Pavel Korovin wrote:
> Gitea is a go binary, so in most cases the old package won't become
> non-functional very soon.

It already did for machines with IBT.

Re: Gitea 1.20.0

2023-07-24 Thread Pavel Korovin 
On 07/24, Stuart Henderson wrote:
> pkg_add -u will display MESSAGE if it changed since the previous version
> so the user can easily find information about how to fix it. (The
> downside is that it's displayed for new installs with "pkg_add gitea"
> too).
> 
> Another way is simply to list changes needed in faq/current.html (which
> is usually copied over to the upgrade notes for the next OpenBSD
> release). But on an interactive update, this is easier to miss than
> MESSAGE.
> This situation (upstream requiring config changes) is not uncommon
> - unless things are likely to be a real mess we don't normally use
> @ask-update for them.
> 
> The problem with @ask-update is that non-interactive updates just skip
> updating the relevant package; but sometimes after an OS update the old
> package is non-functional too.
> 
> There are some exceptions in-tree: freeradius 2->3 and dovecot 1->2,
> where they have multiple configuration files which don't work well
> with the @sample mechanism and they had big changes that really needed
> attention, at least a backup, before the update. But it seems this is
> not really a problem with the changes needed for gitea?

Gitea is a go binary, so in most cases the old package won't become
non-functional very soon.
I'd leave @ask-update with a message like:
"gitea-v1.20.0 fails to start if configuration contains deprecated options,
make sure your configuration is up-to-date"
And leave it for a user to decide about his config. Because:
1) There's a list of deprecated options, and gitea blames those in logs, but
still works
2) There are some deprecated options like those in [mailer] section
which make gitea silently fail
3) People can use different options in their configs. I cannot test
which one will break Gitea this or next time

I think it's the app problem, and Gitea devs still din't decide
how to fix it, e.g.:
https://github.com/go-gitea/gitea/pull/25206#issuecomment-1621292395

I'd better not keep trying to fix in the port the problems which should be
fixed in the app itself.

-- 
With best regards,
Pavel Korovin

Re: Gitea 1.20.0

2023-07-24 Thread Stuart Henderson 
On 2023/07/24 01:19, Pavel Korovin wrote:
> > As I see it, @ask-update is mostly needed where you need to take steps
> > _before_ the new version is installed (say, for postgresql if you're in
> > a situation where you can't use pg_upgrade, e.g. using an extension,
> > you need to run the old version in order to dump the db), Whereas if
> > it's steps to be taken after updating, it doesn't really matter if
> > people update first, they can still follow them.
>  
> I'm OK with your approach, the only thing which makes me feel bad is
> the situation when the user runs 'pkg_add -u' and then finds that gitea
> fails to start and something has to be done now to fix it.

pkg_add -u will display MESSAGE if it changed since the previous version
so the user can easily find information about how to fix it. (The
downside is that it's displayed for new installs with "pkg_add gitea"
too).

Another way is simply to list changes needed in faq/current.html (which
is usually copied over to the upgrade notes for the next OpenBSD
release). But on an interactive update, this is easier to miss than
MESSAGE.

This situation (upstream requiring config changes) is not uncommon
- unless things are likely to be a real mess we don't normally use
@ask-update for them.

The problem with @ask-update is that non-interactive updates just skip
updating the relevant package; but sometimes after an OS update the old
package is non-functional too.

There are some exceptions in-tree: freeradius 2->3 and dovecot 1->2,
where they have multiple configuration files which don't work well
with the @sample mechanism and they had big changes that really needed
attention, at least a backup, before the update. But it seems this is
not really a problem with the changes needed for gitea?

Re: Gitea 1.20.0

2023-07-24 Thread Jasper Lievisse Adriaanse 



> On 24 Jul 2023, at 00:19, Pavel Korovin  wrote:
> 
> On 07/23, Stuart Henderson wrote:
>> On 2023/07/23 16:05, Pavel Korovin wrote:
>>> I think adding @ask-update makes sense only if there's an UPGRADE section in
>>> README describing what setting is deprecated in which version, otherwise
>>> I'll end up with multiple @ask-update for each version, or with @ask-update
>>> for all versions with something misleading like: "check your config for
>>> deprecated settings", but how people will know what's deprecated?
>> 
>> Users can't see a new pkg-readme on the running system until they've
>> already agreed to accept the update.
> 
> Oops then,  my bad :)
> 
>> IMHO I would go with 4) - 1) and a short pkg/MESSAGE "if updating from
>> before X.Y, see the pkg-readme for config options which are no longer
>> supported". ("deprecated" is "still work but you should stop using them"
>> rather than "no longer works and things break unless you remove them").
>> 
>> As I see it, @ask-update is mostly needed where you need to take steps
>> _before_ the new version is installed (say, for postgresql if you're in
>> a situation where you can't use pg_upgrade, e.g. using an extension,
>> you need to run the old version in order to dump the db), Whereas if
>> it's steps to be taken after updating, it doesn't really matter if
>> people update first, they can still follow them.
> 
> I'm OK with your approach, the only thing which makes me feel bad is
> the situation when the user runs 'pkg_add -u' and then finds that gitea
> fails to start and something has to be done now to fix it.

Using MESSAGE makes sense if upstream notifies of upcoming removals pending 
deprecation.
I.e. if they deprecate an option but don’t actually error out on it?

> -- 
> With best regards,
> Pavel Korovin

Re: Gitea 1.20.0

2023-07-23 Thread Pavel Korovin 
On 07/23, Stuart Henderson wrote:
> On 2023/07/23 16:05, Pavel Korovin wrote:
> > I think adding @ask-update makes sense only if there's an UPGRADE section in
> > README describing what setting is deprecated in which version, otherwise
> > I'll end up with multiple @ask-update for each version, or with @ask-update
> > for all versions with something misleading like: "check your config for
> > deprecated settings", but how people will know what's deprecated?
> 
> Users can't see a new pkg-readme on the running system until they've
> already agreed to accept the update.

Oops then,  my bad :)
 
> IMHO I would go with 4) - 1) and a short pkg/MESSAGE "if updating from
> before X.Y, see the pkg-readme for config options which are no longer
> supported". ("deprecated" is "still work but you should stop using them"
> rather than "no longer works and things break unless you remove them").
> 
> As I see it, @ask-update is mostly needed where you need to take steps
> _before_ the new version is installed (say, for postgresql if you're in
> a situation where you can't use pg_upgrade, e.g. using an extension,
> you need to run the old version in order to dump the db), Whereas if
> it's steps to be taken after updating, it doesn't really matter if
> people update first, they can still follow them.
 
I'm OK with your approach, the only thing which makes me feel bad is
the situation when the user runs 'pkg_add -u' and then finds that gitea
fails to start and something has to be done now to fix it.

-- 
With best regards,
Pavel Korovin

Re: Gitea 1.20.0

2023-07-23 Thread Stuart Henderson 
On 2023/07/23 16:05, Pavel Korovin wrote:
> I think adding @ask-update makes sense only if there's an UPGRADE section in
> README describing what setting is deprecated in which version, otherwise
> I'll end up with multiple @ask-update for each version, or with @ask-update
> for all versions with something misleading like: "check your config for
> deprecated settings", but how people will know what's deprecated?

Users can't see a new pkg-readme on the running system until they've
already agreed to accept the update.

> From the recent security/gnupg update which broke yubikey setups,
> there's no @ask-update but there's an additional note in README.

I've veen pondering that one. Unless there's some indication that the
internal ccid driver does actually work in some cases on OpenBSD, I
think it maybe worth patching to disable it. 

> So I see 3 options:
> 1) Add UPGRADE section in README with the list of deprecated config
> options
> 2) 1) + @ask-update
> 3) 1) + @ask-update for each specific version (not sure if it even
> works)

IMHO I would go with 4) - 1) and a short pkg/MESSAGE "if updating from
before X.Y, see the pkg-readme for config options which are no longer
supported". ("deprecated" is "still work but you should stop using them"
rather than "no longer works and things break unless you remove them").

As I see it, @ask-update is mostly needed where you need to take steps
_before_ the new version is installed (say, for postgresql if you're in
a situation where you can't use pg_upgrade, e.g. using an extension,
you need to run the old version in order to dump the db), Whereas if
it's steps to be taken after updating, it doesn't really matter if
people update first, they can still follow them.

Re: Gitea 1.20.0

2023-07-23 Thread Pavel Korovin 
On 07/23, Pavel Korovin wrote:
> +Check the list of deprecated configuration options below, compare gitea
> +configuration file ${SYSCONFDIR}/gitea/app.ini with
> +${TRUEPREFIX}/gitea/share/gitea/conf/app.example.ini, and the configuration
^^
there's a typo, should be "and adjust the configuration accordingly"

-- 
With best regards,
Pavel Korovin

Re: Gitea 1.20.0

2023-07-23 Thread Pavel Korovin 
On 07/23, Pavel Korovin wrote:
> So I see 3 options:
> 1) Add UPGRADE section in README with the list of deprecated config
> options
> 2) 1) + @ask-update
> 3) 1) + @ask-update for each specific version (not sure if it even
> works)

Attached the diff with the 2nd approach, OK?

-- 
With best regards,
Pavel Korovin
Index: Makefile
===
RCS file: /cvs/ports/www/gitea/Makefile,v
retrieving revision 1.98
diff -u -p -r1.98 Makefile
--- Makefile17 Jul 2023 15:05:57 -  1.98
+++ Makefile23 Jul 2023 18:09:07 -
@@ -1,6 +1,6 @@
 COMMENT =  compact self-hosted Git service
 
-VERSION =  1.20.0
+VERSION =  1.20.1
 DISTNAME = gitea-src-${VERSION}
 PKGNAME =  gitea-${VERSION}
 
Index: distinfo
===
RCS file: /cvs/ports/www/gitea/distinfo,v
retrieving revision 1.81
diff -u -p -r1.81 distinfo
--- distinfo17 Jul 2023 15:05:57 -  1.81
+++ distinfo23 Jul 2023 18:09:07 -
@@ -1,2 +1,2 @@
-SHA256 (gitea-src-1.20.0.tar.gz) = ME2ZYSeaHru/7wBFBmXLpf9dKpl0WrtrmAqmzw37tq4=
-SIZE (gitea-src-1.20.0.tar.gz) = 49049895
+SHA256 (gitea-src-1.20.1.tar.gz) = LYOCNZJiGuMM1ly1Sp+0F8Us8LtAXzH5NzJf2CLcHck=
+SIZE (gitea-src-1.20.1.tar.gz) = 49281655
Index: patches/patch-custom_conf_app_example_ini
===
RCS file: /cvs/ports/www/gitea/patches/patch-custom_conf_app_example_ini,v
retrieving revision 1.17
diff -u -p -r1.17 patch-custom_conf_app_example_ini
--- patches/patch-custom_conf_app_example_ini   17 Jul 2023 15:05:57 -  
1.17
+++ patches/patch-custom_conf_app_example_ini   23 Jul 2023 18:09:07 -
@@ -1,7 +1,7 @@
 Index: custom/conf/app.example.ini
 --- custom/conf/app.example.ini.orig
 +++ custom/conf/app.example.ini
-@@ -47,7 +47,7 @@
+@@ -44,7 +44,7 @@
  APP_NAME = ; Gitea: Git with a cup of tea
  ;;
  ;; RUN_USER will automatically detect the current user - but you can set it 
here change it if you run locally
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/gitea/pkg/PLIST,v
retrieving revision 1.34
diff -u -p -r1.34 PLIST
--- pkg/PLIST   17 Jul 2023 15:05:57 -  1.34
+++ pkg/PLIST   23 Jul 2023 18:09:07 -
@@ -1,3 +1,4 @@
+@ask-update gitea-<1.20.0 Check Upgrading section of the pkg README
 @newgroup _gitea:787
 @newuser _gitea:787:_gitea::Gitea Account:/var/gitea:/bin/sh
 @rcscript ${RCDIR}/gitea
Index: pkg/README
===
RCS file: /cvs/ports/www/gitea/pkg/README,v
retrieving revision 1.7
diff -u -p -r1.7 README
--- pkg/README  9 Jan 2023 17:39:56 -   1.7
+++ pkg/README  23 Jul 2023 18:09:07 -
@@ -21,7 +21,6 @@ On OpenBSD, initial gitea configuration 
  - Server runs in "offline" mode, which means that external services such as
Gravatar/OpenID are not used
  - New repositories have "private" checkbox checked by default
- - Password hash algorithm changed from pbkdf2 to argon2
 
 Adjust these configuration settings according to your requirements.
 
@@ -40,10 +39,12 @@ Relevant configuration directives in ${S
 
# An HTTPS server using SSL/TLS
server "gitea.example.com" {
-   listen on $ext_addr tls port 443
-   tls certificate "/etc/ssl/gitea.example.com.pem"
-   tls key "/etc/ssl/private/gitea.example.com.key"
-   location "*" { fastcgi socket "/run/gitea/gitea.sock" }
+   root "/gitea"
+   listen on * tls port 443
+   log style forwarded
+   location match "/assets/(.*)" { request rewrite "/public/%1" }
+   location "/public/*" { no fastcgi }
+   location "*" { fastcgi socket "run/gitea/gitea.sock" }
}
 
 Relevant configuration directives in ${SYSCONFDIR}/gitea/app.ini:
@@ -62,3 +63,37 @@ Customizing gitea
 =
 For custom public files, templates, gitignores, labels, licenses and READMEs,
 please use ${LOCALSTATEDIR}/gitea/custom directory.
+
+Upgrading gitea
+===
+Upgrade procedure: https://docs.gitea.com/next/installation/upgrade-from-gitea
+
+Check the list of deprecated configuration options below, compare gitea
+configuration file ${SYSCONFDIR}/gitea/app.ini with
+${TRUEPREFIX}/gitea/share/gitea/conf/app.example.ini, and the configuration
+accordingly.
+
+Section| Option| Deprecated
++---+---
+indexer| ISSUE_INDEXER_QUEUE_TYPE  | 1.20.0
+indexer| ISSUE_INDEXER_QUEUE_DIR   | 1.20.0
+indexer| ISSUE_INDEXER_QUEUE_CONN_STR  | 1.20.0

Re: Gitea 1.20.0

2023-07-23 Thread Pavel Korovin 
On 07/22, Jasper Lievisse Adriaanse wrote:
> You recently committed the update for gitea 1.20.0; I think you should add an 
> @ask-update marker because there are many
> deprecated options which need to be tweaked first otherwise the server breaks 
> on the next boot. The commit message doesn’t
> mention this at all (other than pointing to the raw changelog).

(cc'ing to ports@)

Hi Jasper,

Thanks for spotting the issue. I didn't pay attention for possible
breakages because I usually review logs and check package functionality after
upgrading it, and in case of gitea, when it blames some configuration options
are deprecated, I fix it JIT, that's why it didn't break on my prod/test
setups, and that's why I missed it.

I think adding @ask-update makes sense only if there's an UPGRADE section in
README describing what setting is deprecated in which version, otherwise
I'll end up with multiple @ask-update for each version, or with @ask-update
for all versions with something misleading like: "check your config for
deprecated settings", but how people will know what's deprecated?

https://docs.gitea.com/next/administration/config-cheat-sheet shows only
5 options as deprecated while there are many more:
https://github.com/go-gitea/gitea/pull/22992/commits/77732651b322183d92f6d8401ba1142181d8876c

>From the recent security/gnupg update which broke yubikey setups,
there's no @ask-update but there's an additional note in README.

So I see 3 options:
1) Add UPGRADE section in README with the list of deprecated config
options
2) 1) + @ask-update
3) 1) + @ask-update for each specific version (not sure if it even
works)

-- 
With best regards,
Pavel Korovin