bugGNU Octave - Bugs: bug #57044, Use gnulib without hg subrepo and...

 
 

bug #57044: Use gnulib without hg subrepo and `bootstrap` with proper revision control

Submitter:  Colin Macdonald <cbm>
Submitted:  Fri 11 Oct 2019 10:12:10 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 25 Jan 2020 12:38:19 AM UTC, comment #43: 

Same here.  Thanks jwe for pushing this one.  This solves the issues of the OP and in my private build environment [1] things are getting easier as well*.


  • Because each local clone of the Octave repo still required internet connection (and time) to pull the hg subrepo or ugly patching/hacking.  No longer necessary ;-)


[1] https://github.com/siko1056/OctaveCD

Kai Torben Ohlhus <siko1056>
Group Member
Fri 24 Jan 2020 08:01:14 PM UTC, comment #42: 

This works for me now, with a fresh clone of Octave. Default ./bootstrap pulls upstream gnulib and updates to a8e125d24942. The environment overrides GNULIB_REVISION and GNULIB_URL also work as documented for me.

This was done on the stable and default branches

Mike Miller <mtmiller>
Group Member
Fri 24 Jan 2020 08:15:49 AM UTC, comment #41: 

I definitely want this change, this will help me and avoid many problems with hg subrepos. The drawbacks of this won't bother me personally. I just want to be sure this won't be too disruptive to others. If y'all are happy with having to run git fetch every once in a while, please go ahead.

Mike Miller <mtmiller>
Group Member
Fri 24 Jan 2020 07:40:57 AM UTC, comment #40: 

Mike (comment #38), in the past this did not really happen very often, and the fix is more than obvious.  In the same spirit some developers (including me) face from time to time problems with stale build trees, if there where breaking changes that require deleting all old stuff and starting from bootstrap again.

My overall impression is Octave wins much more by doing this change, than it looses.

Kai Torben Ohlhus <siko1056>
Group Member
Fri 24 Jan 2020 07:21:25 AM UTC, comment #39: 


>Is it only failing if the revision is not present in the local archive and it cannot find it by pulling from a remote archive?


I think gnulib's bootstrap does not pull (fetch) new revisions on it's own.  At lease I did not observe it and do not find neither "pull" or "fetch" in that script.

Updating must be done manually.

> But it works properly if the revision is not present in the local archive but it can access the remote archive to find it?


Again updating must be done manually, I think.

> Or is there some other failure that could happen?


If bootstrap cannot assure the GNULIB_REVISION, it tries to clone a brand new gnulib repo or bootstrap fails with an error.  This is the good news.  The fix for avoiding a new clone is more than obvious


cd gnulib
git pull


For a fresh Octave hg clone this never fails, as bootstrap clones a fresh gnulib repo too.

Kai Torben Ohlhus <siko1056>
Group Member
Fri 24 Jan 2020 07:20:38 AM UTC, comment #38: 

It fails any time the revision is not found in the local history. It does not do a pull or fetch of new revisions at all. In my estimation this will fail for everyone every time GNULIB_REVISION is updated.

Mike Miller <mtmiller>
Group Member
Fri 24 Jan 2020 06:31:25 AM UTC, comment #37: 

Is it only failing if the revision is not present in the local archive and it cannot find it by pulling from a remote archive? 

But it works properly if the revision is not present in the local archive but it can access the remote archive to find it?

Or is there some other failure that could happen?

John W. Eaton <jwe>
Group administrator
Fri 24 Jan 2020 05:18:25 AM UTC, comment #36: 

I think this "failure" you expect is that one "fatal: reference is not a tree":


GNULIB_REVISION=24d438e5e579478a4c4d4fece2f10a68a1836268 ./bootstrap

./bootstrap: Bootstrapping from checked-out octave sources...
fatal: reference is not a tree: 24d438e5e579478a4c4d4fece2f10a68a1836268
<dead>


In this case bootstrap was not able to checkout the correct git id and died.  The reason was in my scenario (comment #34) that git could not find this id in the gnulib repo (as I cut the internet connection and was in an old state).

As soon as the git ID is fetched, it is really hard to provoke a failure scenario.  bootstrap does really a good job, if you do not make it suffer too much with border cases.

Kai Torben Ohlhus <siko1056>
Group Member
Fri 24 Jan 2020 05:13:40 AM UTC, comment #35: 

I'm also not seeing a failure to update to a different revision.

John W. Eaton <jwe>
Group administrator
Fri 24 Jan 2020 02:28:09 AM UTC, comment #34: 

Regarding comment #32 (jwe): No objections, please apply =)

Regarding comment #33 (Mike), comment #27 (Mike):

I tried to reproduce your example


bootstrap.conf
: ${GNULIB_REVISION=a8e125d24942bc581fda1628a61a60b979ab7087}


https://git.savannah.gnu.org/cgit/gnulib.git (orign/master)
24d438e5e579478a4c4d4fece2f10a68a1836268 (01/21/2020 05:59:10 PM -0800)

LOCAL (orign/master)
020f5190955808cafb670d2be6afb7d5faf69621 (01/16/2020 09:41:34 PM +0530)

LOCAL (master)
1fabf601fa87579a9eaed42c92c6bb9a97922c1d (12/13/2019 12:19:56 AM +0100)


DISABLE INTERNET

./bootstrap

./bootstrap: Bootstrapping from checked-out octave sources...
Note: checking out 'a8e125d24942bc581fda1628a61a60b979ab7087'.

... successful



GNULIB_REVISION=020f5190955808cafb670d2be6afb7d5faf69621 ./bootstrap

./bootstrap: Bootstrapping from checked-out octave sources...
Previous HEAD position was a8e125d24 * lib/mknodat.c: Remove incorrect comments.
HEAD is now at 020f51909 vcs-to-changelog: Fix parsing of fndecl without args.

... successful



GNULIB_REVISION=24d438e5e579478a4c4d4fece2f10a68a1836268 ./bootstrap

./bootstrap: Bootstrapping from checked-out octave sources...
fatal: reference is not a tree: 24d438e5e579478a4c4d4fece2f10a68a1836268
<dead>


GNULIB_REVISION= ./bootstrap

./bootstrap: Bootstrapping from checked-out octave sources...
./bootstrap: getting gnulib files...
Cloning into 'gnulib'...
fatal: Unable to look up git.sv.gnu.org (port 9418) (Name or service not known)
<dead>


ENABLE INTERNET

GNULIB_REVISION=24d438e5e579478a4c4d4fece2f10a68a1836268 ./bootstrap

./bootstrap: Bootstrapping from checked-out octave sources...
./bootstrap: getting gnulib files...
Cloning into 'gnulib'...

<old "gnulib" folder removed, startover with a fresh clone>


GNULIB_REVISION= ./bootstrap

<just take what is there>


You are right.  It is maybe 99% of what we want.  But most important, we can easily control via one hash inside bootstrap.conf for a plain standard Octave developer a very easy to maintain and understand way to get the gnulib right.

I things go wrong, bootstrap is smart enough to issue an "tree"-error about git id mismatches.  Thus lets do the change now than later and gain new experience with these border cases.

Kai Torben Ohlhus <siko1056>
Group Member
Thu 23 Jan 2020 11:13:45 PM UTC, comment #33: 

Yes, so I think this change does not actually do what we want. Specifically, the bootstrap script does not actually fetch new revisions from a previously cloned gnulib directory. It does an initial clone, but does not fetch the next time and the next time.

Here's a step-by-step procedure that I just replicated.

1. I first clone Octave and run bootstrap today. This clones a new copy of gnulib with git into the gnulib directory.

2. Some time later, I run 'hg pull -u' and './bootstrap'. If GNULIB_REVISION hasn't changed, everything is fine.

3. Now I pull a new revision and GNULIB_REVISION has been updated. I run bootstrap, and it tries to check out a new commit.

4. Error message "fatal: reference is not a tree: ff29c880629e73def7cd6c4a954e919b174d31b6"

So bootstrap doesn't really do the functionality that we want here.

Mike Miller <mtmiller>
Group Member
Thu 23 Jan 2020 11:02:45 PM UTC, comment #32: 

I'm ready to push the attached change to stable and merge with default.  Any objection?


(file #48280)

John W. Eaton <jwe>
Group administrator
Thu 23 Jan 2020 10:37:36 PM UTC, comment #31: 

We could also use


: ${GNULIB_REVISION=a8e125d24942bc581fda1628a61a60b979ab7087}


so that bootstrap.conf would only set GNULIB_REVISION if it is not already set.  Then you could use


GNULIB_REVISION= ./bootstrap --gnulib-srcdir=path/to/gnulib


to use whatever the current version is.

John W. Eaton <jwe>
Group administrator
Thu 23 Jan 2020 10:26:42 PM UTC, comment #30: 

Yeah, I just tested Kai's original patch and it does force the gnulib directory to 'ff29c880629e73def7cd6c4a954e919b174d31b6', even with --gnulib-srcdir. Even if I run './bootstrap --gnulib-srcdir=../../gnulib --no-git', it still forces my gnulib repo to the pinned revision.

Personally, I would be fine with passing GNULIB_REVISION as an environment variable to workaround this to get what I want, for example 'GNULIB_REVISION=master ./bootstrap ...'. Would this be ok? Change the patch to bootstrap.conf to do this instead? This works for me.


: ${GNULIB_REVISION=ff29c880629e73def7cd6c4a954e919b174d31b6}


Actually I now have some doubts about whether bootstrap correctly fetches new revisions from the gnulib directory after the initial clone. I'll test that next.

Mike Miller <mtmiller>
Group Member
Thu 23 Jan 2020 10:14:05 PM UTC, comment #29: 

Oops, wait, I think I misunderstood what I was seeing and my statement in comment #28 is not correct.

John W. Eaton <jwe>
Group administrator
Thu 23 Jan 2020 10:05:40 PM UTC, comment #28: 

Mike: It looks like if you use


./bootstrap --gnulib-srcdir=path/to/gnulib


then the version used will be whatever is current in the separate gnulib repo.

John W. Eaton <jwe>
Group administrator
Thu 23 Jan 2020 09:59:31 PM UTC, comment #27: 

Kai - when GNULIB_REVISION is added to bootstrap.conf, is there any way for me to run bootstrap and keep gnulib at a different revision? For example, I now typically keep a separate gnulib repository on the master branch and run './bootstrap --gnulib-srcdir=../../gnulib'. Is there any way to override the checkout or will I have to keep a local edit to bootstrap.conf just to keep my gnulib on master? I hope that this change can also support that workflow. Thanks.

Mike Miller <mtmiller>
Group Member
Thu 23 Jan 2020 09:52:22 PM UTC, comment #26: 

Yeah, I think a warning message would be fine, either 'configure' or 'make', either now or later, when there's a mismatch, so users know they should re-run bootstrap.

If Kai thinks it's safe to integrate this into the stable branch for the 5.2 release, seems ok to me. We will need people with various versions of Texinfo to confirm that the latest gnulib fixes the doc problems that Rik reported on the maintainers list, and doesn't introduce any more problems.

I've been building both default and stable with a more recent gnulib branch for a few months and I haven't had run into any problems.


Mike Miller <mtmiller>
Group Member
Thu 23 Jan 2020 09:32:28 PM UTC, comment #25: 

In any case, thanks for the explanation.  We can add a warning later if we decide it is useful.

Should we go ahead with the change to eliminate the subrepo now?

Also, if we go ahead, should the patch from comment #10 be applied to stable (with appropriate gnulib revision) and then merged to default (possibly with a different gnulib revision)?

John W. Eaton <jwe>
Group administrator
Thu 23 Jan 2020 09:25:21 PM UTC, comment #24: 

OK.  I guess my question now is, should there be a warning that the version of gnulib is not the expected one?  I don't think we should prevent that mismatch, but would it be useful to warn about it?

John W. Eaton <jwe>
Group administrator
Thu 23 Jan 2020 09:09:54 PM UTC, comment #23: 

Notice that this is effectively the same as we have today.

Right now, if you update gnulib to a new revision, and I do 'hg pull -u', I do get an automatic recursive pull of the gnulib subrepository. However, those files don't actually get used in the build until I manually run ./bootstrap. It's the same as if I hadn't updated gnulib at all.

So the only effective difference is when does your local copy of gnulib get updated to the new revision that we have pinned in the repository. This change will push the fetch from "hg up" to "./bootstrap" time.

Mike Miller <mtmiller>
Group Member
Thu 23 Jan 2020 08:56:11 PM UTC, comment #22: 

If we don't have gnulib as a subrepo, how are things supposed to work?  After updating, do you now always have to use bootstrap to make sure that you are at the expected gnulib revision?  Will there be any warning from configure or make if you are not?

John W. Eaton <jwe>
Group administrator
Thu 23 Jan 2020 08:28:55 PM UTC, comment #21: 

Ping - can we not add this check to configure? Thoughts on why it would be useful or necessary?

Mike Miller <mtmiller>
Group Member
Mon 23 Dec 2019 06:37:48 PM UTC, comment #20: 

Isn't adding this check into configure a bit of overkill?

When we track gnulib as a hg subrepository, it's true that using "hg update" will automatically switch to the correct revision. However, the user who is bisecting or tracking development still always needs to use bootstrap in order to copy those changes from "gnulib" into "libgnu". Otherwise, they definitely may be building with out of date copies of source files in libgnu.

Adding this check into configure is a step above and beyond what we had been doing before, but it does check for something that would normally have been enforced by hg. However, it's still no guarantee that the user has run bootstrap to copy the sources from gnulib into libgnu. I'm not sure it's useful.

Mike Miller <mtmiller>
Group Member
Mon 23 Dec 2019 04:57:09 PM UTC, comment #19: 

Checking for bootstrap seems like a good idea to me. A user could be building from a git clone or from a hg archive, both which are missing the .hg directory.

Mike Miller <mtmiller>
Group Member
Mon 23 Dec 2019 09:23:06 AM UTC, comment #18: 

In the attached patch, I opted for checking if the bootstrap script is in the source tree. That file isn't in the distribution tarball.

IIRC, Mike uses a git repository for Octave. So checking for the ".hg" directory might cause problems.

(file #48107)

Markus Mützel <mmuetzel>
Group administrator
Mon 23 Dec 2019 06:18:37 AM UTC, comment #17: 

A dump idea which only might complicate things, is to check for the presence of the ".hg" directory.

Kai Torben Ohlhus <siko1056>
Group Member
Mon 23 Dec 2019 05:30:33 AM UTC, comment #16: 

Well, it wasn't completely my idea but what jwe asked for in comment #11.
I haven't tested with a distribution tarball. But I think it would fail without the switch. Good catch.

Is there a way that configure can tell that it is called from a distribution tarball?

Markus Mützel <mmuetzel>
Group administrator
Mon 23 Dec 2019 02:13:49 AM UTC, comment #15: 

Good idea Markus (comment #14, file #48103).  Using an extra file makes much clearer, what the gnulib-revision actually is.

One assertion regarding the configure script.  When configuring a released distribution tarball of Octave, do I always have to add "--without-gnulib-rev-check" with your patch?

Kai Torben Ohlhus <siko1056>
Group Member
Sun 22 Dec 2019 08:24:53 PM UTC, comment #14: 

The attached patch adds a test to the configure script to check whether the current gnulib revision is the expected one. If this is not the case, configure fails.
For this, the git revision is stored in a new file "gnulib_rev" that is used by bootstrap and by configure. That file is part of the hg repository. So every hg revision will continue to be linked to a specific gnulib version.
The file could also be hidden if preferred.

The test can be skipped by adding --without-gnulib-rev-check to the configure switches.

The patch applies on top of Kai's patch from comment #10.
It only works if the gnulib repository is at the default location in the source tree. For other configurations, --without-gnulib-rev-check must be used.


(file #48103)

Markus Mützel <mmuetzel>
Group administrator
Thu 12 Dec 2019 03:30:32 PM UTC, comment #13: 

One addendum to comment #12:  In case you manage some "/path/to/gnulib" in an old state.  From Octave pulled "GNULIB_REVISION", that lies for "/path/to/gnulib" in the future and is not fetched.  Then you need an internet connection and "/path/to/gnulib" is updated, otherwise an error is thrown:


./bootstrap: Bootstrapping from checked-out octave sources...
fatal: reference is not a tree: 70f2e740bba4624934fa1b9e6680d4234949c4a4


Kai Torben Ohlhus <siko1056>
Group Member
Thu 12 Dec 2019 03:01:48 PM UTC, comment #12: 

Indeed, bootstrap is a very "intelligent" script, that can ensure using the correct "GNULIB_REVISION" all by its own.

Regarding older releases, soon 5.2.0 and older:  There the files ".hgsub" and ".hgsubstate" are still present in the repository and will have to use Octave's gnulib hg subrepo https://hg.octave.org/gnulib/ to work in the future.  Thus we cannot delete Octave's gnulib hg subrepo, if we want to be able to know the gnulib version of that releases.

Regarding releases 6.1 and onwards: ".hgsub" and ".hgsubstate" are removed.  The "GNULIB_REVISION" is maintained in "bootstrap.conf" inside Octave's main hg repository.  Thus it is clear for every commit, which "GNULIB_REVISION" was in use.  The hard work is done by bootstrap itself.

Scenario #1: In a fresh Octave hg repo.  Just calling


./bootstrap


will check for "./gnulib/" to be a clone of git://git.sv.gnu.org/gnulib (https://git.savannah.gnu.org/cgit/gnulib.git) and clone it if not existing.  If existing, bootstrap tries to checkout "GNULIB_REVISION".  This works, even if the "GNULIB_REVISION" is in the future, i.e. not fetched inside "./gnulib/".

Scenario #2: In a fresh Octave hg repo.  Custom gnulib git repo


./bootstrap --gnulib-srcdir=path/to/gnulib


and the procedure is as in #1.

As said before in comment #10.  Updating gnulib from 6.1 will be pretty easy compared to now.  Never had such a close look at bootstrap before.

Kai Torben Ohlhus <siko1056>
Group Member
Thu 12 Dec 2019 02:37:45 PM UTC, comment #11: 

The reason for having our own hg repo for gnulib was so that we could have it as an hg subrepo in Octave and to allow us to fix problems that were specific to Octave.  We've only once (?) even tried to fix a problem in gnulib that was specific to Octave, so I don't think that really matters.  And having hg or git for gnulib history in the subrepo used by Octave doesn't really matter.  So I have no problem with using git to manage gnulib in Octave.

As Mike said, we do need a way to record and automatically update to the gnulib version that was used at any particular point in Octave's history.  Otherwise I see problems with bisecting.

Kai, how will that work with your proposed change?  Will the gnulib revision be recorded in bootstrap.conf?  If it is only a bootstrap thing, then I expect people to be out of sync frequently.  Can we make the configure script check that the correct gnulib version is being used for the current Octave version and error if it is not?  A configure option could allow the version mismatch to be ignored.

John W. Eaton <jwe>
Group administrator
Wed 11 Dec 2019 06:25:18 AM UTC, comment #10: 

During the preparation for the 6.1 release, I stumbled over this issue again.  gnulib does not make it easy to understand the bootstrap script.  But basically all that is said in the bootstrap file.  Octave does currently not make use of the


GNULIB_REVISION=03eccb2d010e0755fd55458e2f012fcfb0735c2d


https://hg.octave.org/gnulib/rev/c34f677e6117

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=03eccb2d010e0755fd55458e2f012fcfb0735c2d

feature.  I tried around with it:

+ Works offline (if the revision is fetched inside the git repo).
+ Works with self-hosted gnulib-git repo (git version managed by bootstrap, "--gnulib-srcdir" and "GNULIB_SRCDIR" are dominant)
- `git` becomes a new build requirement (honestly, today not a drawback at all)

With this approach, updating gnulib is now as easy as changing the hash in bootstrap.conf


GNULIB_REVISION=ff29c880629e73def7cd6c4a954e919b174d31b6


and run before committing to the Octave hg repo:


./bootstrap --bootstrap-sync


No more hg subrepo in Octave!! =D

The attached short changeset should be used with a clean clone of Octave and automatically cloned the "gnulib" repo removed:


diff -r 1d04f049a859 -r 1a63b0fbafd3 .hgsub
--- a/.hgsub        Tue Dec 10 17:55:29 2019 -0800
+++ /dev/null        Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +0,0 @@
-gnulib = http://hg.octave.org/gnulib
diff -r 1d04f049a859 -r 1a63b0fbafd3 .hgsubstate
--- a/.hgsubstate        Tue Dec 10 17:55:29 2019 -0800
+++ /dev/null        Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +0,0 @@
-c34f677e6117d1c293338328a6c9b9ce18e9ef53 gnulib
diff -r 1d04f049a859 -r 1a63b0fbafd3 bootstrap.conf
--- a/bootstrap.conf        Tue Dec 10 17:55:29 2019 -0800
+++ b/bootstrap.conf        Wed Dec 11 14:39:32 2019 +0900
@@ -176,10 +176,15 @@ gnulib_tool_option_extras="--libtool"
 gnulib_name="libgnu"
 source_base="libgnu"

-# Don't use git to update gnulib sources. We keep gnulib under a
-# Mercurial subrepository instead.
-use_git=false
-GNULIB_SRCDIR=gnulib
+# Go to https://git.savannah.gnu.org/cgit/gnulib.git to find out the latest
+# revision ID.  Paste it below and run
+#
+#   ./bootstrap --bootstrap-sync
+#
+# To update the ./bootstrap file with that from ./gnulib/build-aux/bootstrap
+#
+GNULIB_REVISION=ff29c880629e73def7cd6c4a954e919b174d31b6
+

 # Don't check for translations since we don't have any in Octave yet.
 # This avoids the need for sha1sum or compatible utility in bootstrap.



(file #48044)

Kai Torben Ohlhus <siko1056>
Group Member
Sat 12 Oct 2019 12:46:04 AM UTC, comment #9: 


> always pull the latest gnulib from git on savannah into a subdirectory, when the user runs ./bootstrap


After thinking about this for a minute, I do think it's important to have some way of tracking which commit from gnulib was used to build a particular revision of Octave, particularly stable releases, so I was wrong in that respect. But in my own development, I do build Octave against gnulib's master branch.

Personally, I think all of the pain points of having gnulib be a hg subrepo are because of the way subrepos are implemented in hg. If they were instead tracked but enabled later at the user's option, as in git modules, I think the problems would dissolve.

Mike Miller <mtmiller>
Group Member
Sat 12 Oct 2019 12:26:29 AM UTC, comment #8: 

jwe - I know Jordi's talked about the pros and cons of hg subrepos before. Do you have a specific new layout you want to use, or are you musing generally about the problems with the current layout?

Personally I would probably prefer that we just not have our own gnulib mirror at all anymore, and use bootstrap the way it was intended, to always pull the latest gnulib from git on savannah into a subdirectory, when the user runs ./bootstrap.

I know another option was to have a new top-level project with no files, that tracks octave and gnulib as subrepos. I'm not really a fan of that idea. I think it would be confusing to need to pull from a new project name, and have a layout that differs from every other GNU / Gnulib / autotools style project out there.

Mike Miller <mtmiller>
Group Member
Sat 12 Oct 2019 12:21:30 AM UTC, comment #7: 

Colin - I think it might be reasonable to put a conditional in there. What about


if test -d .hg; then
  use_git=false
  GNULIB_SRCDIR=gnulib
fi


This should have zero effect on everyone currently working on Octave with hg.

This will affect anyone that was downloading a snapshot of the Octave sources and was expecting ./bootstrap to look for an existing gnulib in the current directory, with this change it would instead use git to pull the latest gnulib from savannah. I expect the number of people working with Octave this way to be close to zero.

Mike Miller <mtmiller>
Group Member
Fri 11 Oct 2019 11:52:48 PM UTC, comment #6: 

We might also reconsider our decision to include gnulib as an hg subrepo contained in a subdirectory of the Octave source tree.

John W. Eaton <jwe>
Group administrator
Fri 11 Oct 2019 10:59:50 PM UTC, comment #5: 

From Octave src root dir, either "git status" or "hg status" will give an error.  Can we modify bootstrap.conf, something like this pseudocode:


if exit_value_of(`hg status`) == 0:
  use_git=false
  GNULIB_SRCDIR=gnulib
endif

B/c without those two lines, git went and grabbed gnulib by itself...

Colin Macdonald <cbm>
Fri 11 Oct 2019 10:30:55 PM UTC, comment #4: 

Heads up to other maintainers and developers, yes I am hosting git mirrors of the Octave source tree in an experiment to see if doing so brings in contributions or raises visibility. If you don't care about git, you can ignore their existence and bugs like this one :)

Mike Miller <mtmiller>
Group Member
Fri 11 Oct 2019 10:22:05 PM UTC, comment #3: 

Sorry, that should be '--gnulib-srcdir=../../gnulib'.

And I think if you simply drop a copy of gnulib or a symlink into the Octave source directory itself, it will just find it where it's expected. No changes needed either way.

Mike Miller <mtmiller>
Group Member
Fri 11 Oct 2019 10:17:49 PM UTC, comment #2: 

The way I build is to use an external gnulib git clone. This could be either in the octave source tree, or in another directory. Here is my exact process.


cd ~/src
git clone https://git.savannah.gnu.org/git/gnulib.git
cd ~/src/octave/default
./bootstrap --with-gnulib=../../gnulib


Gnulib is already a hg subrepository, I'm not sure there is a nice way to make it also a git subrepository without things getting very confusing (both vcs would need to track subrepository state). I don't advocate trying to do this in the Octave official repository.

I may end up making another top-level repository that contains octave and gnulib as subrepos, and configures one to talk to the other. But we can discuss that elsewhere.

Mike Miller <mtmiller>
Group Member
Fri 11 Oct 2019 10:15:43 PM UTC, comment #1: 


diff --git a/bootstrap.conf b/bootstrap.conf
index 6409c133c0..892c5aaf5d 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -177,8 +177,8 @@ source_base="libgnu"

 # Don't use git to update gnulib sources. We keep gnulib under a
 # Mercurial subrepository instead.
-use_git=false
-GNULIB_SRCDIR=gnulib
+#use_git=false
+#GNULIB_SRCDIR=gnulib

 # Don't check for translations since we don't have any in Octave yet.
 # This avoids the need for sha1sum or compatible utility in bootstrap.


This "fixes" it.  So how can we do that selectively?

Colin Macdonald <cbm>
Fri 11 Oct 2019 10:12:10 PM UTC, original submission:  

This bug is only relevant to the gitlab/github mirrors that mtmiller has setup.


# git clone https://gitlab.com/mtmiller/octave.git
# cd octave
# ./bootstrap
./bootstrap: Error: --no-git requires --gnulib-srcdir


Is this a problem we can solve with git submodules?  Or some tweaking to `bootstrap`.  It would be nice if it worked OOTB.

Colin Macdonald <cbm>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #48280:  diffs.txt added by jwe (2KiB - text/plain)
file #48107:  bug57044_gnulib_rev_check_v2.patch added by mmuetzel (2KiB - application/octet-stream)
file #48103:  bug57044_gnulib_rev_check.patch added by mmuetzel (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by cbm (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-04 mtmiller StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-01-24 mtmiller StatusPatch Reviewed Ready For Test
    2020-01-24 siko1056 StatusPatch Submitted Patch Reviewed
    2020-01-23 jwe Attached File- Added diffs.txt, #48280
    2019-12-23 mtmiller Carbon-CopyRemoved mtmiller -
    2019-12-23 mmuetzel Attached File- Added bug57044_gnulib_rev_check_v2.patch, #48107
    2019-12-22 mmuetzel Attached File- Added bug57044_gnulib_rev_check.patch, #48103
        StatusReady For Test Patch Submitted
    2019-12-11 siko1056 SummaryUse `bootstrap` without hg subrepo and proper revision control Use gnulib without hg subrepo and `bootstrap` with proper revision control
    2019-12-11 siko1056 Attached File- Added bug_57044_remove_hg_gnulib.patch, #48044
        Item GroupOther Feature Request
        StatusNone Ready For Test
        Summarygitlab mirror: &quot;bootstrap --no-git requires --gnulib-srcdir&quot; Use `bootstrap` without hg subrepo and proper revision control
    2019-10-11 cbm Carbon-Copy- Added mtmiller

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code