lwip submodule should point to a tag or branch tip in the remote repository

[ali1234]

Currently the lwip submodule points to an arbitrary commit c385f31076b27efb8ee37f00cb5568783a58f299. Most git servers, including GNU Savannah, only allow shallow clones of branch tips and tags. This means if you do a shallow recursive clone of pico-extras (for example, in a CI pipeline), you will get the following error:

Error: error: Server does not allow request for unadvertised object c385f31076b27efb8ee37f00cb5568783a58f299
Error: fatal: Fetched in submodule path 'lib/lwip', but it did not contain c385f31076b27efb8ee37f00cb5568783a58f299. Direct fetching of that commit failed.

User must instead do a full clone of the submodule, which might mean doing a full clone of pico-extras too. This is slow, wastes bandwidth and electricity, uses up extra Actions minutes, and hammers the GNU servers.

This can be fixed by either changing the submodule to point to an existing tag or branch (if branch, you have to keep on updating the submodule whenever the branch tip changes), or by forking the upstream repository and adding a tag to the commit you want to use, and then adjusting the submodule to point to your fork.

[lurch]

I believe the contents of this repo are basically "unsupported, use at your own risk", and I'm not aware of any plans to actively update the contents of this repo.

Looking at https://savannah.nongnu.org/projects/lwip/ I see that lwIP 2.1.2 was released in November 2018 and lwIP 2.1.3 was released in November 2021. I've never looked at any of the lwIP stuff myself, so would you be willing to do some testing to see if STABLE-2_1_3_RELEASE would be a suitable tag for us to pin the submodule to?

[kilograham]

yes we can update the tag if you find one that works

[ali1234]

I have never used lwip either. I don't know what it is supposed to do. The only reason I even know it exists is because of the build failure it causes. There are no mentions of it anywhere in pico-sdk or pico-playground repositories and the only use in pico-extras is where the platform code initializes it. As such it isn't clear how I would determine whether it is working correctly or not, since it doesn't actually do anything.

I can tell you that 2.1.x is a stable release with backported fixes and therefore does not contain every commit present in c385f3107 because it branched when 2.1.0 was released in 2018.

[lurch]

pico-extras is effectively a "use at your own risk" collection of not-yet-officially-supported code, so it might be better to copy out the parts that you need into your own project, rather than trying to clone the whole repo during your CI process? :man_shrugging:

[kilograham]

then, you should be able just add:

set(SKIP_LWIP 1)

to the top of your CMakeLists.txt (before you init the SDK)

[ali1234]

That won't help because the problem occurs during the cloning of the repository:

$ git clone --recursive --depth 1 --shallow-submodules https://github.com/raspberrypi/pico-extras
Cloning into 'pico-extras'...
remote: Enumerating objects: 153, done.
remote: Counting objects: 100% (153/153), done.
remote: Compressing objects: 100% (118/118), done.
remote: Total 153 (delta 14), reused 121 (delta 6), pack-reused 0
Receiving objects: 100% (153/153), 131.68 KiB | 807.00 KiB/s, done.
Resolving deltas: 100% (14/14), done.
Submodule 'lwip' (https://git.savannah.nongnu.org/git/lwip.git) registered for path 'lib/lwip'
Cloning into '/home/al/pico-extras/lib/lwip'...
remote: Counting objects: 851, done.        
remote: Compressing objects: 100% (742/742), done.        
remote: Total 851 (delta 176), reused 497 (delta 71)        
Receiving objects: 100% (851/851), 1.84 MiB | 2.14 MiB/s, done.
Resolving deltas: 100% (176/176), done.
remote: Total 0 (delta 0), reused 0 (delta 0)
error: Server does not allow request for unadvertised object c385f31076b27efb8ee37f00cb5568783a58f299
Fetched in submodule path 'lib/lwip', but it did not contain c385f31076b27efb8ee37f00cb5568783a58f299. Direct fetching of that commit failed.

[kilograham]

well it is the only submodule, so you don't need to do a recursive clone...

... should be a workaround until we update it.