From Newsgroup: comp.sys.tandem

Hi Everyone,

A new release, 2.39.0, and a patch release 2.38.2 are now available on the ITUGLIB website for the usual build targets.

2.38.2 is a back-port of fixes through 2.39.0.

Regards,
Randall Becker
On Behalf of the ITUGLIB Technical Committee
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.tandem

On Wednesday, December 14, 2022 at 3:06:40 a.m. UTC-5, Randall wrote:

Hi Everyone,

A new release, 2.39.0, and a patch release 2.38.2 are now available on the ITUGLIB website for the usual build targets.

2.38.2 is a back-port of fixes through 2.39.0.

Regards,
Randall Becker
On Behalf of the ITUGLIB Technical Committee

I found an edge condition in releases newer than 2.36.0 relating to local sub-volumes that causes git to limit functionality. If you are using submodules with a clone of a local repository, your submodule operations may fail. Reverting to 2.36.0 appears to be a workaround. Another workaround, without reverting is playing with the value of the configuration variable 'protocol.file.allow' to not be 'user' (the default). Setting the value to 'always' should allow the submodule operation that would otherwise fail. The change after 2.36.0 was to set the default of this configuration to 'user', which triggers this edge condition. The situation is currently under investigation by the git team.
Regards.
Randall
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.tandem

On Wednesday, December 28, 2022 at 9:28:20 a.m. UTC-5, Randall wrote:

On Wednesday, December 14, 2022 at 3:06:40 a.m. UTC-5, Randall wrote:

Hi Everyone,

A new release, 2.39.0, and a patch release 2.38.2 are now available on the ITUGLIB website for the usual build targets.

2.38.2 is a back-port of fixes through 2.39.0.

Regards,
Randall Becker
On Behalf of the ITUGLIB Technical Committee

I found an edge condition in releases newer than 2.36.0 relating to local sub-volumes that causes git to limit functionality. If you are using submodules with a clone of a local repository, your submodule operations may fail. Reverting to 2.36.0 appears to be a workaround. Another workaround, without reverting is playing with the value of the configuration variable 'protocol.file.allow' to not be 'user' (the default). Setting the value to 'always' should allow the submodule operation that would otherwise fail. The change after 2.36.0 was to set the default of this configuration to 'user', which triggers this edge condition. The situation is currently under investigation by the git team.

Regards.
Randall

Nope, the config values do not fix the problem, so if you encounter "fatal: transport 'file' not allowed" during a submodule operation, the defect above has happened, and you probably need to revert. I am hopeful for a fix shortly and will report back.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.tandem

On Wednesday, December 28, 2022 at 9:47:52 a.m. UTC-5, Randall wrote:

On Wednesday, December 28, 2022 at 9:28:20 a.m. UTC-5, Randall wrote:

On Wednesday, December 14, 2022 at 3:06:40 a.m. UTC-5, Randall wrote:

Hi Everyone,

A new release, 2.39.0, and a patch release 2.38.2 are now available on the ITUGLIB website for the usual build targets.

2.38.2 is a back-port of fixes through 2.39.0.

Regards,
Randall Becker
On Behalf of the ITUGLIB Technical Committee

I found an edge condition in releases newer than 2.36.0 relating to local sub-volumes that causes git to limit functionality. If you are using submodules with a clone of a local repository, your submodule operations may fail. Reverting to 2.36.0 appears to be a workaround. Another workaround, without reverting is playing with the value of the configuration variable 'protocol.file.allow' to not be 'user' (the default). Setting the value to 'always' should allow the submodule operation that would otherwise fail. The change after 2.36.0 was to set the default of this configuration to 'user', which triggers this edge condition. The situation is currently under investigation by the git team.

Regards.
Randall

Nope, the config values do not fix the problem, so if you encounter "fatal: transport 'file' not allowed" during a submodule operation, the defect above has happened, and you probably need to revert. I am hopeful for a fix shortly and will report back.

No root cause has yet been identified - not for lack of trying. As soon as I hear anything, I will post news. The key point is that if you are a submodule user, your upstream needs to be remote not local. If you are purely remote, you will not be impacted. Otherwise, you will need to revert to 2.36.0 or earlier. Do not use 2.36.1 or newer as those have the change that causes this.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.tandem

On Friday, December 30, 2022 at 5:57:42 p.m. UTC-5, Randall wrote:

On Wednesday, December 28, 2022 at 9:47:52 a.m. UTC-5, Randall wrote:

On Wednesday, December 28, 2022 at 9:28:20 a.m. UTC-5, Randall wrote:

On Wednesday, December 14, 2022 at 3:06:40 a.m. UTC-5, Randall wrote:

Hi Everyone,

A new release, 2.39.0, and a patch release 2.38.2 are now available on the ITUGLIB website for the usual build targets.

2.38.2 is a back-port of fixes through 2.39.0.

Regards,
Randall Becker
On Behalf of the ITUGLIB Technical Committee

I found an edge condition in releases newer than 2.36.0 relating to local sub-volumes that causes git to limit functionality. If you are using submodules with a clone of a local repository, your submodule operations may fail. Reverting to 2.36.0 appears to be a workaround. Another workaround, without reverting is playing with the value of the configuration variable 'protocol.file.allow' to not be 'user' (the default). Setting the value to 'always' should allow the submodule operation that would otherwise fail. The change after 2.36.0 was to set the default of this configuration to 'user', which triggers this edge condition. The situation is currently under investigation by the git team.

Regards.
Randall

Nope, the config values do not fix the problem, so if you encounter "fatal: transport 'file' not allowed" during a submodule operation, the defect above has happened, and you probably need to revert. I am hopeful for a fix shortly and will report back.

No root cause has yet been identified - not for lack of trying. As soon as I hear anything, I will post news. The key point is that if you are a submodule user, your upstream needs to be remote not local. If you are purely remote, you will not be impacted. Otherwise, you will need to revert to 2.36.0 or earlier. Do not use 2.36.1 or newer as those have the change that causes this.

I think I have found the root cause. 2.39.0 appears fine if you avoid using the 'git remote add origin ../path' command. When I used a simple clone, the origin was set up correctly and the submodule add works correctly. You do need to configure the protocol.file.allow=always variable if you are using local submodules - this was added as a security measure. So no revert is required unless you use the git remote add command with relative paths. Glad that is figured out.
--- Synchronet 3.21d-Linux NewsLink 1.2