Whonix RC – Testers Wanted!

anon-meta-packages debian/control

Should the updated names go beside current ones or replace them? I don’t want to break Jessie builds


doesn’t exist:

kdm – deprecated by sddm

didn’t check past this section because they seem to be interdependencies between Whonix packages.


Should the updated names go beside current ones or replace them? I don’t want to break Jessie builds

Make it work in wheezy as well as in jessie. That’s the only requirement.

..., udisks | udisks2, ...

is also possible. (But in this specific case not required, since wheezy
has udisk2 also, so we can simply do udisks -> udisks2.


doesn’t exist:

Some of them are Whonix packages. See packages sub folder in Whonix main
source code folder, https://github.com/Whonix or search engines.

It’s not the best time to work on Debian stretch support at this time.
It’s not on the roadmap to Whonix 13. Too much changed. Maybe also too


still applies.

Adding pkg-wheezy | pkg-jessie for the problematic cases, not sure if
that would over complicate anon-meta-packages’s debian/control. Also a
git branches approach seems to over complicate things.

A better time to work on Debian stretch support will be when Debian
stretch was blessed (almost) stable.



Fixed in git master.

kdm – deprecated by sddm

Problematic. Then also probably
https://github.com/Whonix/kde-kdm-autologin needs updates or replacement.


This is also problematic. Would be easier to drop jessie support the
moment porting to stretch. Replacing kde-workspace needs more thought.
Requires a review of kde-workspace’s current dependencies. And a plan on
what to emulate.

  • freespacenotifier -> Drop.
  • kde-window-manager -> Make kwin-x11 dependency of anon-shared-desktop-kde.
  • klipper -> Keep? Otherwise copy and paste works in strange ways.
    [After closing an application, where one copied something from into the
    clipboard, the clipboard is emptied upon closing of that application.]
  • ksysguard -> drop?
  • systemsettings -> Make systemsettings dependency of
  • kde-workspace-bin -> Was removed from Debian stretch. (Reason: “ROM;
    superseded by Plasma 5”) Need to find a drop-in replacement package, if
    it exists or also to be thought through as these packages above.


Packages by Whonix.


TODO. See:



The anon-workstation-langpack-common package? For now, patches welcome.

trap_signal_type_last : ERR
1: : /sbin/init
2: : /usr/bin/konsole
3: : /bin/bash
4: : sudo ./whonix_build --gnw – --build --target qcow2 --allow-untagged true --allow-uncommitted true --arch amd64
5: : /bin/bash ./whonix_build --gnw – --build --target qcow2 --allow-untagged true --allow-uncommitted true --arch amd64
6: : /bin/bash ./help-steps/whonix_build_one --flavor whonix-workstation --build --target qcow2 --allow-untagged true --allow-uncommitted true --arch amd64
7: : /bin/bash ././build-steps.d/1700_install-packages
main (line number: 467)
main (line number: 459)
install-packages (line number: 413)
pkg-install-maybe (line number: 170)
error (line number: 20)
errorhandlerunchrootunpreventunmount (line number: 320)
errorhandlerprocessshared (line number: 159)
last_failed_bash_command: error_ "See above! (There should be a bold, red message surrounded by blue hashtags (#).)"
last_failed_exit_code: 127
ERROR in ././build-steps.d/1700_install-packages detected!

  • true ‘ERROR: As expected, failed again to install anon-workstation-default-applications. (apt_get_exit_code: 100) Trying to diagnose the problem using function apt_get_parse_unmet_dependency…’
  • apt_get_parse_unmet_dependency anon-workstation-default-applications
  • local pkg_unmet
  • pkg_unmet=anon-workstation-default-applications
  • true ‘INFO: Running “dpkg -l | grep anon-workstation-default-applications”…’
  • chroot /home/user/whonix_binary/Whonix-Workstation_image dpkg -l
  • grep anon-workstation-default-applications
  • true
  • chroot /home/user/whonix_binary/Whonix-Workstation_image apt-cache policy anon-workstation-default-applications
    Installed: (none)
    Candidate: (none)
    Version table:
  • local line
  • set +x
  • true ‘INFO: Tried to diagnose the problem using function apt_get_parse_unmet_dependency.’
  • error ‘See above!’
  • true
  • true ‘ERROR: See above!’
  • true

The log is much to short to make head or tail of it.

I discovered the build did not include the new extra packages committed since the branch. Should I not checkout a branch to get all the latest changes?


  • It would be useful to mention in Tor Browser downloader that the hardened version is: (x64 only)


Let’s see for how long this is true…

We unfortunately cannot get rid of dependencies by adding it to
anon-banned-packages. The only way would be to avoid [the chain of] the
application that depends on it.

I have the latest developer branch build but its missing a lot of interesting changes for me.

I tried building from master to get all the uncommitted files but the script dies with an error. It would be nice if you could create a new “testing” rolling branch that you manually commit to every few days.

On their blog post they said a 32bit hardened Tor Browser is not planned at all.

The master branch is a rolling development branch but it would be too
much effort to make sure it’s always successfully building without
errors. However, it’s easy to skip errors or fix them for developers.

The only problem with master is git’s complaints that qxl package is not added as a git submodule from within the Whonix project folder.

Works for me. Please post the log.

I’ll wait for a new branches that include everything instead of troubleshooting every error that comes up otherwise with master.

You probably know but the forum desktop shortcut needs updating to point to the new address. I also think its time to move the IRC support channel to a new server because OFTC has been blocking Tor access for weeks now.

Should solve https://phabricator.whonix.org/T361 instead?


You probably know but the forum desktop shortcut needs updating to point to the new address.

Thanks for reminding me. Updated in git master.


  • It would be useful to mention in Tor Browser downloader that the hardened version is: (x64 only)

The current message in that window is big enough. And that code complex
enough. And explanatory enough. If users stick with the recommended
(pre-selected), everything is fine. Otherwise if they want to use
hardened versions and it fails, they find the related thread on google.
Has not caused support requests yet. So I leave it as is. Patches
happily considered.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]