Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • T tor-browser-build
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 212
    • Issues 212
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 5
    • Merge requests 5
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Applications
  • tor-browser-build
  • Issues
  • #28754
Closed
Open
Issue created Dec 06, 2018 by Georg Koppen@gkDeveloper

make testbuild-android-armv7 stalls during sha256sum step

Suppose you don't have a testbuild directory containing any already built bundles. Now, start a build with make testbuild-android-armv7 to get an .apk. The result is a stalled build in the release project.

The reason for that is that

sha256sum $(ls -1 *.exe *.tar.xz *.dmg *.mar *.zip *.tar.gz | grep -v '\.incremental\.mar$' | sort) > sha256sums-unsigned-build.txt

evaluates to

sha256sum > sha256sums-unsigned-build.txt

which waits for input. We have not been hitting that so far as both in the alpha and the nightly case other bundles in the directory are available. And for the mobile case legacy/trac#25164 (moved) is about to fix this as well. However, we might want to be a bit more conservative and only execute sha256sum if we actually have an argument to pass. Otherwise this can lead to surprising results (like in this case).

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking