Looks like a mistake.
Same for this.
A helpful answer.
dpkg-checkbuilddepsdpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 9) dh-systemd (>= 1.5)Parsing that should make things a bit easier at least than doing the whole debian/control parsing?
Shows only missing build dependencies. Not already installed ones. Otherwise outputs nothing. But that is actually an advantage for this use case, no?
By asking on some debian mailing list, we could likely learn about even more suitable tools.
Why is this needed?
[hr]
Looks like it’s getting quite a lot comments. Perhaps it would have been better if I created tickets for each of them to not forget about any?
qubes-whonix-preinst - I don’t think this one is necessary. Any folders required are created during install so or so.
[hr]
There are more matches of “qubes-whonixcheck”.
[hr]
Not that important:
but usually it’s not two new lines at the end, just one.
[quote=“Patrick, post:25, topic:764”]qubes-whonix-preinst - I don’t think this one is necessary. Any folders required are created during install so or so.
mkdir -p /usr/lib/qubes-whonix/init[hr]
There are more matches of “qubes-whonixcheck”.
[hr]
Not that important:
but usually it’s not two new lines at the end, just one.[/quote]
Think I took care of this
[quote=“Patrick, post:24, topic:764”]Why is this needed?
export DESTDIR=$(shell pwd)/debian/whonix-qubesIt’s needed for the Qubes builder. Qubes builds a bit differently than you do 
Looks like it's getting quite a lot comments. Perhaps it would have been better if I created tickets for each of them to not forget about any?
I have been going though them one by one. Think I have them all handled at this point.
[quote=“Patrick, post:17, topic:764”]Can you change the location from GitHub - nrgaway/qubes-whonix: Configures Whonix to run as a ProxyVM / AppVM on Qubes OS to GitHub - nrgaway/qubes-whonix: Configures Whonix to run as a ProxyVM / AppVM on Qubes OS please?
Because the package is called whonix-qubes as well and the name of the folder is used in scripts as package name. Would really simplify things. That might have been the issue with make-helper.bsh also.[/quote]
I see you posted this one after (although it is showing before) I renamed the whole package to qubes-whonix so I figure this is not required anymore. It is pointing to Whonix repo though.
Everything seems to be building correctly now since I wrote those new Debian parsers.
[quote=“Patrick, post:19, topic:764”]There is dpkg-parsechangelog. See also:
I think once based on jessie, it will be improved.
It’s used by make-helper.bsh also.
make-helper.bsh can also be sourced, it will do nothing then, but when you run make_get_variables it will set all the version numbers to variables it has parsed from debian/changelog.
Debian must have existing code to parse debian/control, no? Otherwise how is stuff like “apt-get build-dep” working?[/quote]
It will be interesting to see what replies you receive back from your post. There does seem to be many utilities that do parse the Debian control and changelog, but I had not seen any that are meant to retrieve only the desired fields, etc.
I am happy with the parse_debian script I wrote since it will parse the log and only return what I ask it to return, therefore no further parsing is required. For example:
Will only return a space separated string of build dependencies:
parse_debian control --build-depends debian/controlWill only return a space separated string of package dependencies:
parse_debian control --depends debian/controlReturns the package release name (qubes-whonix_9.4-1):
parse_debian changelog --package-release-name debian/changelogReturns epoc:
parse_debian changelog --package-version-epoc debian/changelogReturns version without epoc
parse_debian changelog --package-version debian/changelogReturns version including epoc
parse_debian changelog --package-version-full debian/changelogI am not opposed to the python script, just I prefer to exhausting other options before inventing something, i.e. asking upstream about it.
[hr]
32_uwt_default… Wouldn’t 32_uwt_qubes be more appropriate?
Think I have them all handled at this point.
There is a lot that has not been addressed. Didn’t go through everything again yet. Just a few that are missing:
- /etc/hosts - Whonix Forum
- .anondist - Whonix Forum
- typos - Whonix Forum
- CONTRIBUTING.md - Whonix Forum
Don’t get me wrong. You’re not obligated to address any of these. Of course not. I just preferred if they were in the bug tracker, so we don’t forget about them, perhaps I or someone else fixing them.
There is one issue why I haven’t added the package to https://github.com/Whonix/Whonix/tree/master/packages folder yet. It [font=courier]Build-Depends:[/font] on [font=courier]dh-systemd[/font]. That dependency isn’t available as long as Whonix is based on Debian wheezy. So building Whonix would break when attempting to build the qubes-whonix package.
We could add another hack to https://github.com/Whonix/Whonix/blob/master/build-steps.d/1100_prepare-build-machine#L415 to install it from jessie in meanwhile. Want me to do this?
How do you install systemd in wheezy based Whonix-Qubes anyhow?
[quote=“Patrick, post:29, topic:764”]There is one issue why I haven’t added the package to https://github.com/Whonix/Whonix/tree/master/packages folder yet. It [font=courier]Build-Depends:[/font] on [font=courier]dh-systemd[/font]. That dependency isn’t available as long as Whonix is based on Debian wheezy. So building Whonix would break when attempting to build the qubes-whonix package.
We could add another hack to https://github.com/Whonix/Whonix/blob/master/build-steps.d/1100_prepare-build-machine#L415 to install it from jessie in meanwhile. Want me to do this?
How do you install systemd in wheezy based Whonix-Qubes anyhow?[/quote]
I will get to the issues above when I get a chance. For now I just build the package with qubes-builder along with the other Qubes modules.
When installing the actual package after Whonix has been installed (or just in wheezy) I do get an install error from makefile.bsh. I had to create a script to remake /dev/fd directory:
# Debian chroot /dev/fd is all messed up; links are not normal and prevents dpkg redirect:
# /make-helper.bsh: line 256: /dev/fd/62: No such file or directory
@if [ ! -L $(CHROOT_DIR)/dev/fd ]; then \
if [ ! -a $(CHROOT_DIR)/dev/fd ]; then \
sudo chroot $(CHROOT_DIR) mv /dev/fd /dev/fd.dist; \
fi; \
sudo chroot $(CHROOT_DIR) ln -s /proc/self/fd /dev/fd; \
fi
I don’t actually know why your script calls /dev/fd62 but I noticed that the wheezy /fd directories look like this (I wonder if this is normal?) compared to say Fedora:
Wheezy:
drwxr-xr-x 2 root root 4096 Nov 25 18:58 .
drwxr-xr-x 4 root root 4096 Jan 6 16:51 ..
lrwxrwxrwx 1 root root 15 Nov 25 18:58 fd -> ../proc/self/fd
lrwxrwxrwx 1 root root 17 Nov 25 18:58 stderr -> ../proc/self/fd/2
lrwxrwxrwx 1 root root 17 Nov 25 18:58 stdin -> ../proc/self/fd/0
lrwxrwxrwx 1 root root 17 Nov 25 18:58 stdout -> ../proc/self/fd/1
Fedora (linked directly to /proc/self/fd
dr-x------ 2 user user 0 Jan 7 09:27 .
dr-xr-xr-x 7 user user 0 Jan 7 09:27 ..
lrwx------ 1 /user user 64 Jan 7 09:27 0 -> /dev/pts/0
lrwx------ 1 user user 64 Jan 7 09:27 1 -> /dev/pts/0
lrwx------ 1 user user 64 Jan 7 09:27 2 -> /dev/pts/0
lr-x------ 1 user user 64 Jan 7 09:27 3 -> /proc/19185/fdSee Wheezy has no number codes 0, 1 2 instead names. Have you ever experienced this?
This is what causes it; even if I just manually install the package via ‘dpkg -i qubes-whonix’, or build run ‘make deb-dist’. When I apply the patch above it works:
done < <( dpkg-parsechangelog )Anyway, here is the script I use to install systemd on Wheezy (The aptRemove/Install just calls a bash function that chroots to image with apt-get install command…):
#### '--------------------------------------------------------------------------
info ' Remove sysvinit'
#### '--------------------------------------------------------------------------
echo 'Yes, do as I say!' | aptRemove sysvinit
#### '--------------------------------------------------------------------------
info ' Preventing sysvinit re-installation'
#### '--------------------------------------------------------------------------
chroot apt-mark hold sysvinit
#### '--------------------------------------------------------------------------
info ' Pin sysvinit to prevent being re-installed'
#### '--------------------------------------------------------------------------
cat > "${INSTALLDIR}/etc/apt/preferences.d/qubes_sysvinit" <<EOF
Package: sysvinit
Pin: version *
Pin-Priority: -100
EOF
chmod 0644 "${INSTALLDIR}/etc/apt/preferences.d/qubes_sysvinit"
#### '--------------------------------------------------------------------------
info ' Install Systemd'
#### '--------------------------------------------------------------------------
aptUpdate
aptInstall systemd-sysv
#### '--------------------------------------------------------------------------
info ' Set multu-user.target as the default target (runlevel 3)'
#### '--------------------------------------------------------------------------
chroot rm -f /etc/systemd/system/default.target
chroot ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
#
# From functions.sh; a sourced script
#
# ==============================================================================
# apt-get remove
# ==============================================================================
function aptRemove() {
files="$@"
DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true \
chroot apt-get ${APT_GET_OPTIONS} remove ${files[@]}
}
# ==============================================================================
# apt-get install
# ==============================================================================
function aptInstall() {
files="$@"
DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true \
chroot apt-get ${APT_GET_OPTIONS} install ${files[@]}
When installing the actual package after Whonix has been installed (or just in wheezy) I do get an install error from makefile.bsh. I had to create a script to remake /dev/fd directory:Looks like a Qubes specific issue.
I don't actually know why your script calls /dev/fd62It doesn't. At least not explicitly.
(I wonder if this is normal?)No idea.
here is the script I use to install systemd on WheezyHm. Sounds brave. See also: https://www.whonix.org/wiki/Dev/APT_Pinning I wonder if this could cause issues when trying to upgrade to jessie and/or Whonix 10.
Hm. Sounds brave. See also:
I wonder if this could cause issues when trying to upgrade to jessie and/or Whonix 10.[/quote]
I don’t think it will cause any issues. The pinning just prevents sysvinit from being re installed. If the pin is not added sysvinit will get re-installed automatically with an ‘apt-get dist-upgrade’. A separate template is already available for Jessie, and I would use that over updating any existing template. Jessie does not need to have sysvinit pinned when upgrading to or using systemd.
If any issues were to come to light, the qubes-whonix package could change the pin. I don’t think the comments of the posts you linked to apply to this situation since the wheezy templates and Whonix implementation are more of a distribution and I would not just consider it a just a package and the pinning is also not being used to control an installed package.
Went through this whole thread again and created separate tickets for all stuff not addressed yet:
https://phabricator.whonix.org/maniphest/?statuses=open%2Creview&allProjects=PHID-PROJ-o2gfrvskvs2nnw6amfsd#R
Many thanks to nrgaway for the qubes-whonix package! It would have taken quite a lot time until I could have figured out how to make Whonix run on top of Qubes.
I think there are still major issues with the package.
(Independently from this, I’ll add it to the repository. [⚓ T182 Add qubes-whonix 9.6.2-1 to Whonix APT Repository])
Lintian reports many warnings for the package:
https://phabricator.whonix.org/T186
For most of them, separate tickets have been created by me.
For a lot stuff, it’s hacks and workarounds, for stuff that would be cleaner if it was fixed upstream in Qubes or Whonix. No security issues (didn’t test the code or leak test, that’s up to you), but I it’s prone to generate all sorts of issues. (Issues with upgrading, support requests, various instability.) It’s good enough as initial implementation but should be implemented in a more robust way.
There are a few tickets closed as invalid:
https://phabricator.whonix.org/maniphest/query/lFf8LAejlxKO/#R
I suggested to solve these issues upstream in Qubes so these hacks can be removed from the qubes-whonix package. And to add them as goals to later milestones. Or if you don’t want to work on them, consider to reopen them and to leave them just tagged Qubes, so anyone else can figure out there is an issue that should be sorted out.
(Adding version goals should be up to the maintainers, because it’s you who would / would not work on it anyhow. See the “Qubes” tag as a general catch all. And other tags [whonix-qubes 11 or w/e] for stuff you plan to work on.)
Also derivation from Whonix (systemd, whonix-setup-wizard) is a bad idea in my opinion and inviting trouble. Adding the latest hot stuff is more like the rolling distribution style (Gentoo and similar) and doesn’t match Whonix’s model with stable hotfixes and major new version.
Anyhow. That’s just my feedback. What you make out of it is up to you, since you maintain it.