Thinking through what would manually happen… Can you get a Debian stretch installed with i386 and then apt-get install linux-image-amd64? Probably not, because that package is only for the amd64 platform in the Debian repository. This was different in jessie. Compare these two.
We likely would have to add multiarch instructions to the build script.
( Debian -- Error ) Probably not
worth it.
Try adding --arch amd64. It’s not optional.
--kernel linux-image-amd64 alone is worth very little. In essence,
it’s like a default i686 Whonix build (“--arch i686” is implicit)
and after you boot it for the first time, you install manually the linux-image-amd64 kernel package. Only when combining with --arch amd64 it’s really useful.
Since you don’t want i386, the " or using '--arch i386' instead." part won’t work.
So try “Consider installing and booting the 'linux-image-amd64' kernel”. And what I meant by that is NOT --kernel linux-image-amd64 build option. It is installing that very kernel on the Debian or Whonix you are currently using for trying to build Whonix. I.e. sudo apt-get install linux-image-amd64. Then boot that kernel.
Should that not work, you would need an amd64 Debian or Whonix installation. Since no one is providing amd64 Whonix, you would be left with manually starting with amd64 Debian. ((Building on Debian jessie based is currently the only tested option.)
Usually you don’t need to use --kernel. Should you use --arch amd64, the build script will automatically pick the right kernel, linux-image-amd64 for you. Only for other platforms than i686 or amd64 you need to manually specify the right kernel, because that is not yet specified in the build script.
I meant try mixing the linux-image-amd64 kernel on a i686 build machine.
That should work.
In other words, just run sudo apt-get install linux-image-amd64 on
your build machine. Then reboot. Boot that kernel. Never mind if the
build machine is bare metal or a VM. No full 64 bit re-install required.
Just one package.
[Only if that does not work (unlikely) you must use a 64 bit Debian [or
derivatives].]
[[kernel architecture does not equal package architecture. Some can be
mixed. Multi arch.]]
In principal this works with your instructions however the build failed because of the changed package names like you said. The error popped up when installing udisks.
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
volatile.
Also
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.
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
anon-shared-desktop-kde
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.
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…’
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?
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.