Gnucobol pushed to version 3.2 and implemented berkeley db support #20968

alexbodn · 2024-07-28T09:00:50Z

as the title says.

i had to also patch the upstream configure.ac alittle,
thus the patched version is served from my github in the mean time.

this replaces my previously rejected PR.
this fixes the issue #20818, i've previously reported

GitMensch

see "upstream suggestions" below

GitMensch · 2024-07-28T09:52:31Z

packages/gnucobol/rmdoc.in.patch

instead of this just touch the target files provided in the distribution tarball after patching libcob

GitMensch · 2024-07-28T09:55:34Z

packages/gnucobol/tmploc.patch

A patch like this was also included in the old package, while the new name is better I do question if this is really needed - because this part is only applied if none of TMDIR, TMP, TEMP are set - and I think this is already the case, no?

since the patch does apply, there is a "/tmp" literal somewhere.
anyway, if you set the catch all /tmp, i'm happy it could be supported in termux too.

GitMensch · 2024-07-28T09:57:54Z

packages/gnucobol/libcob-mlio.c.patch

one patch file to do the include in both places would be necessary if building from last year's 3.2 dist tarball; can be dropped for 3.3 (or a theoretical possible 3.2.1) where this is solved

the missing includes have nothing to do with termux, hence they're part of the upstream patch.

GitMensch · 2024-07-28T10:00:39Z

packages/gnucobol/configure.patch

this patch is correct to be deleted when building 3.2 as it is already included (and extended) there: https://github.com/OCamlPro/gnucobol/blob/gnucobol-3.2/configure.ac

there's no configure.patch in my PR.
i'm patching configure.ac and autogenerating configure in the upstream part of the patch.

GitMensch · 2024-07-28T10:03:17Z

packages/gnucobol/build.sh

 	local lp64="$(( $TERMUX_ARCH_BITS / 32 - 1 ))"
 	export COB_LI_IS_LL="${lp64}"
 	export COB_32_BIT_LONG="$(( 1 - ${lp64} ))"
 	export COB_HAS_64_BIT_POINTER="${lp64}"


Are those not correctly set by configure? Please verify and drop a comment on that in the build script.

well i didn't touch these.
nor have i tried any pointers yet.
all i did was making core functionality :).

GitMensch · 2024-07-28T10:05:00Z

packages/gnucobol/build.sh

 "

 termux_step_pre_configure() {
 	local lp64="$(( $TERMUX_ARCH_BITS / 32 - 1 ))"
 	export COB_LI_IS_LL="${lp64}"
 	export COB_32_BIT_LONG="$(( 1 - ${lp64} ))"
 	export COB_HAS_64_BIT_POINTER="${lp64}"
+
+	export BDB_HEADER=$(cat db_header.c |cc -I$TERMUX_PREFIX/include -P -E -| tail -n 1| sed -e 's/[\ \t]//g')


please add a comment here that this a workaround for not being setup correctly in cross-compiling contexts, "last checked GnuCOBOL 3.2"

with cross compiling configure refused to run any program, hence i did the header autodetection before configure, and pass the result to configure.

it may be the other long-size related exports do fulfill the same void as my call:
inability to call code while configuring for cross compilation.

GitMensch · 2024-07-28T10:08:15Z

packages/gnucobol/build.sh

+TERMUX_PKG_VERSION=3.2
+TERMUX_PKG_REVISION=0
+
+TERMUX_PKG_SRCURL=git+https://github.com/alexbodn/gnucobol-3.2.git


Do you really need to change the upstream tarball?
Note that as-is you very likely trash the timestamps in that way, forcing a recreation of many files which wouldn't be necessary normally.

it was your suggestion to put the last release.
but i'm serving it off my github until you'd fix the issues upstream.
the main file to change was configure, and a file containing a timestamp.
i had to run autoconfig, hadn't i?

and the termux people didn't like the huge diff created by configure change.

and the termux people didn't like the huge diff created by configure change.

My main issue with it is that it is unmaintainable.
It's gonna stop applying and need triage as soon as there is any update to the package.

I should take this opportunity to note that changing the source URL to your personal fork is a complete no go unless you have a good explanation for why that is necessary.

We can guarantee $TMPDIR to have a consistent value at build time.
We can't guarantee that users won't willfully break their environments.

In this case I'd say let's give them the fun to have a broken GnuCOBOL that way and drop the patch.

and the termux people didn't like the huge diff created by configure change.

My main issue with it is that it is unmaintainable. It's gonna stop applying and need triage as soon as there is any update to the package.

I may argue, that each package is targeting a specific version of upstream, with a very specific sha256sum.

i had to change things when switching from gnucobol 3.1.2 to 3.2, but had to extend the changes since important functionality failed in termux, initially with both upstream versions btw.

it's the same with debian packages.

I may argue, that each package is targeting a specific version of upstream, with a very specific sha256sum.

The TERMUX_PKG_SHA256 field is a security and integrity measure.
It helps ensure that package sources have not been tampered with or corrupted.
The binding to a specific version is a result of this, though somewhat incidental.

In this case I'd say let's give them the fun to have a broken GnuCOBOL that way and drop the patch.

I think it's a pitty.
if upstream gives this fallback option, why not on termux too?
it's definitely and legitimately termux related.

alexbodn · 2024-07-28T12:58:53Z

one more thing, @GitMensch .
i notice that the man pages arrive trashed on the phone.
i don't have any idea why.

truboxl · 2024-07-29T06:27:48Z

.github/workflows/packages.yml

@@ -6,6 +6,7 @@ on:
    - master
    - dev
    - 'dev/**'
+    - 'gnucobol-db'


Do not change the CI workflow file. You can also create a Pull Request in your own fork for CI testing.

TomJo2000 · 2024-07-29T22:11:38Z

packages/gnucobol/tmploc.patch

+-			strcpy (tmp, "/tmp");
+		if (!check_valid_dir ("@TERMUX_PREFIX@/tmp")) {
+			tmp = cob_fast_malloc (strlen("@TERMUX_PREFIX@") + 5U);
+			strcpy (tmp, "@TERMUX_PREFIX@/tmp");


I think it's a pitty.
if upstream gives this fallback option, why not on termux too?
it's definitely and legitimately termux related.

Let's move the discussion of the /tmp patch to the patch in question.
I think this is good, and should be kept.
This is straight forward case of fixing a hardcoded path, it just so happens that $TMPDIR already does this job.

alexbodn added 2 commits July 28, 2024 09:13

branch from before my changes

d6836ec

workflow

6825d8d

alexbodn requested review from finagolfin and Grimler91 as code owners July 28, 2024 09:00

alexbodn mentioned this pull request Jul 28, 2024

fixing issue #20818 . upgrade gnucobol upstream and the local patches to allow usage of indexed files by libdb. #20961

Closed

GitMensch reviewed Jul 28, 2024

View reviewed changes

truboxl reviewed Jul 29, 2024

View reviewed changes

TomJo2000 reviewed Jul 29, 2024

View reviewed changes

TomJo2000 mentioned this pull request Apr 2, 2025

bump(main/libxml2): 2.14.1 #24059

Merged

Uh oh!

Gnucobol pushed to version 3.2 and implemented berkeley db support #20968

Are you sure you want to change the base?

Gnucobol pushed to version 3.2 and implemented berkeley db support #20968

Uh oh!

Conversation

alexbodn commented Jul 28, 2024

Uh oh!

GitMensch left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexbodn Jul 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GitMensch Jul 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexbodn Jul 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexbodn Jul 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexbodn Jul 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexbodn Jul 29, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexbodn commented Jul 28, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alexbodn Jul 28, 2024 •

edited

Loading

GitMensch Jul 28, 2024 •

edited

Loading

alexbodn Jul 28, 2024 •

edited

Loading

alexbodn Jul 28, 2024 •

edited

Loading

alexbodn Jul 28, 2024 •

edited

Loading

alexbodn Jul 29, 2024 •

edited

Loading