Core22 fails for git:// URLs

Since switching from core20 to core22 building snaps that clone git repos via the git scheme, i.e. git repo URLs starting with git://, such as git://, the builds fail with:

:: fetch-pack: unexpected disconnect while reading sideband packet
:: fatal: early EOF
:: fatal: fetch-pack: invalid index-pack output

This is a regression as this used to work with earlier versions and some git repos only provide access via git://.

The only workaround, if applicable, for now, is to use the http or https scheme, e.g.

Hey Christian,

I couldn’t reproduce this. I used the following:

name: git-repo
base: core22
version: '1.0'
summary: 'git-repo'
description: 'git-repo'
grade: devel
confinement: devmode

    plugin: dump
    source: git://

I did some googling of the fetch-pack: invalid index-pack output error. It looks like it can be caused by many issues. Does snapcraft clean help?

I tried to run your example locally but got:

Traceback (most recent call last):
  File "/snap/snapcraft/8931/lib/python3.8/site-packages/craft_providers/bases/", line 582, in _install_snaps
  File "/snap/snapcraft/8931/lib/python3.8/site-packages/craft_providers/actions/", line 328, in inject_from_host
    raise SnapInstallationError(
craft_providers.actions.snap_installer.SnapInstallationError: failed to install snap 'snapcraft'
* Command that failed: 'lxc --project snapcraft exec local:snapcraft-git-repo-on-amd64-for-amd64-1450012 -- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin SNAPCRAFT_MANAGED_MODE=1 snap install /tmp/snapcraft.snap --classic'
* Command exit code: 1
* Command standard error output: b'error: cannot perform the following tasks:\n- Ensure prerequisites for "snapcraft" are available (cannot install snap base "core20": Post "": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers))\n'

I give up on running this locally for now.

I encountered this when building in the cloud on So this may work locally but not on the servers.

I managed to start the snap build process with snapcraft remote-build. I get the same results.

With source: git:// I get:

Initializing parts lifecycle
Executing parts lifecycle...
Executing parts lifecycle: pull git-repo
Executing action
Failed to pull source: command ['git', 'clone', '--recursive', 'git://', '/build/snapcraft-git-repo-401c6557fe453706cceec06437f1a580/parts/git-repo/src'] exited with code 128.
Make sure sources are correctly specified.

and with source: I get:

Initializing parts lifecycle
Executing parts lifecycle...
Executing parts lifecycle: pull git-repo
Executing action
Executed: pull git-repo
Executed parts lifecycle
Running build phase...
Created snap package git-repo_1.0_amd64.snap

@mr_cal Are you certain you cannot reproduce this with the remote-build option? Can you give the exact steps to build the core22 snap with the git:// URL?

Ah, let me try with remote-build and get back to you. I was only building locally.

Yep, I get the same failure when running snapcraft remote-build with my snapcraft.yaml reproducer above.

This looks like a Launchpad or launchpad-buildd issue cloning that git repository. Perhaps a proxy or firewall issue on the build servers? Maybe @cjwatson has more information.

I would recommend raising this bug here or here!

IIRC, you cannot use launchpad with those transports unless perhaps if hosted on launchpad

I think the basic problem here will be that using the git:// protocol in Launchpad builds requires special setup to make it use a proxy. We set this up by writing an lpbuildd-git-proxy script to the container and setting the GIT_PROXY_COMMAND environment variable to point to it. However, snapcraft might be launching its own container inside that and thus not inheriting the proxy setup.

The git:// protocol is increasingly obsolescent - for example GitHub disabled it a while ago - so it’s really better to use https:// if it’s at all possible. If it isn’t, though, I’d echo the request to file a launchpad-buildd bug.

1 Like

It’s still a regression from previous versions where this worked without issues. If this is the intended behaviour now, it should be documented and snapcraft should show a proper error instead of leaving users trying to debug their snapcraft.yaml.

Consider this my bug report :slight_smile: