cabal configure makes undesired network requests

[clinty]

Not sure if this is a bug in cabal-install or hackage-security.

When running cabal as part of a Debian package build, requiresBootstrap triggers and this happens.

Running cabal configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro --haddockdir=/usr/lib/ghc-doc/haddock/iso8601-time-0.1.4/ --datasubdir=iso8601-time --htmldir=/usr/share/doc/libghc-iso8601-time-doc/html/ --enable-library-profiling --enable-tests
Config file path source is default config file.
Config file
/<<PKGBUILDDIR>>/debian/cabalconfig/.cabal/config
not found.
Writing default configuration to
/<<PKGBUILDDIR>>/debian/cabalconfig/.cabal/config
/usr/bin/ghc --numeric-version
looking for tool ghc-pkg near compiler in /usr/bin
found ghc-pkg in /usr/bin/ghc-pkg
/usr/bin/ghc-pkg --version
/usr/bin/ghc --supported-languages
/usr/bin/ghc --info
Trying to locate mirrors via DNS for initial bootstrap of secure repository
'http://hackage.haskell.org/' ...
Warning: 'nslookup' tool missing - can't locate mirrors
Selected mirror http://hackage.haskell.org/
Downloading root
Reading available packages...
Warning: The package list for 'hackage.haskell.org' does not exist. Run 'cabal
update' to download it.
index-state(hackage.haskell.org) =
Failed to query pkg-config, Cabal will continue without solving for pkg-config
constraints: dieVerbatim: user error (CallStack (from HasCallStack):
die', called at libraries/Cabal/Cabal/Distribution/Simple/Program/Db.hs:423:28
in Cabal-2.0.1.0:Distribution.Simple.Program.Db
requireProgram, called at ./Distribution/Solver/Types/PkgConfigDb.hs:65:21 in
main:Distribution.Solver.Types.PkgConfigDb
cabal: The program 'pkg-config' is required but it could not be found.
)
Resolving dependencies...

We don't actually want it to do that. Maybe if this is a desired default, an --offline flag could be added for all relevant subcommands (cf. #5346). Also this is apparently breaking Ubuntu.

[gbaz]

Is this a regression compared to prior versions of cabal, or longstanding behavior?

[clinty]

With cabal-install 1.24, there is no attempt to do an "initial bootstrap of secure repository" or find nslookup or download "root"; it just complains and then moves on:

Reading available packages...
Warning: The package list for 'hackage.haskell.org' does not exist. Run 'cabal
update' to download it.
Failed to query pkg-config, Cabal will continue without solving for pkg-config
constraints: user error (The program 'pkg-config' is required but it could not
be found.)
Choosing modular solver.
Resolving dependencies...

[23Skidoo]

/cc @hvr
Do we actually need to do this in configure?

[LocutusOfBorg]

for some reason changing this in rules file

-DEB_SETUP_BIN_NAME = cabal
+DEB_SETUP_BIN_NAME = debian/hlibrary.setup

fixes the issue...

[clinty]

(that tells it to compile Setup.hs as debian/hlibrary.setup and to run e.g. debian/hlibrary.setup configure instead of cabal configure)

[gbaz]

That makes sense -- just running the setup.hs script directly is a lot more "basic" as an interface than using the cabal-install tool.

[clinty]

FTR, we only use cabal(-install) itself for a couple of packages.

[hvr]

@23Skidoo iirc this is a side-effect of the hackage-security integration which tries to bootstrap the TUF metadata, specifically the root.json file (once that single file has been cached, this weird implicit bootstrapping won't occur anymore). I thought we had a ticket about this already, but I can't seem to find it. To answer your question: I don't think this to be necessary, but rather to be an oversight..

[claudeha]

This (I think) bit me recently, I had installed a fresh ghc 8.4.3 and cabal 2.2 to work on a train journey without internet access, but it was wedged:

$ cabal --version
cabal-install version 2.2.0.0
compiled using version 2.2.0.1 of the Cabal library 
$ cabal install
Warning: Caught exception during _mirrors lookup:res_query: does not exist
(Connection refused)
Warning: No mirrors found for http://hackage.haskell.org/
dieVerbatim: user error (cabal: '/usr/bin/wget' exited with an error:
--2018-07-16 10:15:31-- http://hackage.haskell.org/root.json
Resolving hackage.haskell.org (hackage.haskell.org)... failed: Temporary
failure in name resolution.
wget: unable to resolve host address ‘hackage.haskell.org’
)

Luckily I had an old cabal binary that still worked offline so I could still hack on my code a bit:

$ /usr/bin/cabal --version
cabal-install version 1.24.0.1
compiled using version 1.24.1.0 of the Cabal library 

[schmittlauch]

This also bit me under NixOS with cabal run. I set up a simulation container without internet connection and all dependencies having been fetched and built at container build time.

Even on my internet-connected development host, each cabal run invocation triggers a hackage lookup.

version: cabal-install 3.0.0.0

[plredmond]

I'm having the same problem as @schmittlauch, cabal's bootstrapping TUF with a network connection breaks its use in a nix build container

touch config
env CABAL_CONFIG=config cabal ...

this fixes that, but there are further problems

[schmittlauch]

cabal-install 3.4 includes a documented fix/ workaround: #4821 (comment)

[gbaz]

Does this happen only on initial run in a clean env (i.e. bootstrapping) or does it occur even after that data is fetched? i.e. if there's a successful cabal run and then access is removed, does run then start to fail?

[gbaz]

Does this still occur on master?

I tried it out and it appears to work properly (albeit with ugly error message formatting?)

% cabal build
Warning: The package list for 'hackfake' does not exist. Run 'cabal update' to
download it.RemoteRepo {remoteRepoName = RepoName "hackfake", remoteRepoURI =
http://hackfake.haskell.org/, remoteRepoSecure = Nothing, remoteRepoRootKeys =
[], remoteRepoKeyThreshold = 0, remoteRepoShouldTryHttps = False}
Resolving dependencies...
Build profile: -w ghc-8.10.4 -O1
In order, the following will be built (use -v for more details):
 - foo-0.1.0.0 (lib) (configuration changed)
Configuring library for foo-0.1.0.0..
Preprocessing library for foo-0.1.0.0..
Building library for foo-0.1.0.0..

[Mikolaj]

Hello! Could you help us? Can you still reproduce the problem with cabal 3.6.2? Thank you!

[schmittlauch]

Currently only cabal-install 3.4 is in nixpkgs, so I hope to come back to this later once 3.6.2 has reached the repo.

[ulysses4ever]

How am I supposed to repro this exactly? My guess:

Console interaction

cabal/t5363/foobaz via λ 9.0.2 
❯ ping 8.8.8.8
ping: connect: Network is unreachable

cabal/t5363/foobaz via λ 9.0.2 
❯ cabal --version
cabal-install version 3.6.2.0
compiled using version 3.6.3.0 of the Cabal library 

cabal/t5363/foobaz 
❯ cabal init -m -n

Guessing dependencies...

Generating LICENSE...
Warning: unknown license type, you must put a copy in LICENSE yourself.
Generating CHANGELOG.md...
Generating app/Main.hs...
Generating foobaz.cabal...

Warning: no synopsis given. You should edit the .cabal file and add one.
You may want to edit the .cabal file and add a Description field.

cabal/t5363/foobaz via λ 9.0.2 
❯ cabal configure
Resolving dependencies...
Build profile: -w ghc-9.0.2 -O1
In order, the following would be built (use -v for more details):
- foobaz-0.1.0.0 (exe:foobaz) (first run)

cabal/t5363/foobaz via λ 9.0.2 
❯ cabal build
Build profile: -w ghc-9.0.2 -O1
In order, the following will be built (use -v for more details):
- foobaz-0.1.0.0 (exe:foobaz) (first run)
Configuring executable 'foobaz' for foobaz-0.1.0.0..
Preprocessing executable 'foobaz' for foobaz-0.1.0.0..
Building executable 'foobaz' for foobaz-0.1.0.0..
[1 of 1] Compiling Main             ( app/Main.hs, /home/artem/tmp/cabal/t5363/foobaz/dist-newstyle/build/x86_64-linux/ghc-9.0.2/foobaz-0.1.0.0/x/foobaz/build/foobaz/foobaz-tmp/Main.o )
Linking /home/artem/tmp/cabal/t5363/foobaz/dist-newstyle/build/x86_64-linux/ghc-9.0.2/foobaz-0.1.0.0/x/foobaz/build/foobaz/foobaz ...

So, no problem with configure or build apparently (I tried build w/o configure too). Looks like this could be closed?

[Mikolaj]

With new cabals, configure barely does anything, but build does all configure did previously, so reproduction should be possible. I take it this fixed itself. However, please kindly open new tickets (linking to this one) if anything crops up.

[Mikolaj]

BTW, the discussion seems to have moved to #5346.