More regular point releases schedule?

283 views
Skip to first unread message

Marek Marczykowski-Górecki

unread,
Feb 6, 2019, 11:54:37 AM2/6/19
to qubes-devel, Andrew David Wong, Unman, Patrick Schleizer, Frédéric Pierret
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

It may be a good idea to introduce regular schedule for stable [point
releases[1]. It would minimize the need to download a lot of updates
just after installation. This is even more significant, if some updates
may require non-standard update procedure (like installing new template
versions). Such releases should also be coordinated with relevant
templates maintainers.

I'm not sure what such schedule should look like, every 3 months? 6 months?

Any opinions?

[1] https://www.qubes-os.org/doc/version-scheme/#release-version.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxbEUUACgkQ24/THMrX
1yy8Ngf+PG4qVZyTgXxEHdxHFkLZF/ak5w98GT6x06GcekQqnoNbagx/0AKva+qS
CqL11gcKiI/K6ml9dqIkpa0Vvuy+Mw0aUp13vo6qraohXj2JlCmZrr1HCuPD7Jef
sOcXzMk965VovdibmWqsynfFgPe7yf85jQXqWVvhcVn/t+C5BbvHrXSpb+wvA5DR
CUYm1oLr4R0FfwOqd1pcWHGuWneBPFSLv2q5TpExFNZGZBaIlOaSvIEza2evOXYu
X5HQFFh0E6y1E3kN4jkwEsGn+Cv2cZsW/dWHijYOEs1TeAMZblW+4Odp0Sp4gZwO
M8z61S0zOEsYAmrEHR3gvUxWec/7WA==
=TnmP
-----END PGP SIGNATURE-----

Holger Levsen

unread,
Feb 6, 2019, 11:58:53 AM2/6/19
to Marek Marczykowski-Górecki, qubes-devel, Andrew David Wong, Unman, Patrick Schleizer, Frédéric Pierret
On Wed, Feb 06, 2019 at 05:54:29PM +0100, Marek Marczykowski-Górecki wrote:
> It may be a good idea to introduce regular schedule for stable [point
> releases[1]. It would minimize the need to download a lot of updates
> just after installation. This is even more significant, if some updates
> may require non-standard update procedure (like installing new template
> versions). Such releases should also be coordinated with relevant
> templates maintainers.

good idea!

> I'm not sure what such schedule should look like, every 3 months? 6 months?

start slow, with 6 months, and increase the frequence if deemed useful?


--
tschau,
Holger

-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
signature.asc

Foppe de Haan

unread,
Feb 6, 2019, 2:10:53 PM2/6/19
to qubes-devel
On Wednesday, February 6, 2019 at 5:54:37 PM UTC+1, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> It may be a good idea to introduce regular schedule for stable [point
> releases[1]. It would minimize the need to download a lot of updates
> just after installation. This is even more significant, if some updates
> may require non-standard update procedure (like installing new template
> versions). Such releases should also be coordinated with relevant
> templates maintainers.
>
> I'm not sure what such schedule should look like, every 3 months? 6 months?
>
Going by the amount of issues on the updates-status github page, I'd say once every 4 or 6mo would be ample. Could also commit to 2 or 3 per year depending on big changes / additions, but that will probably involve more stress/overhead than simply having it be part of a release schedule.

Chris Laprise

unread,
Feb 6, 2019, 2:26:04 PM2/6/19
to Marek Marczykowski-Górecki, qubes-devel, Andrew David Wong, Unman, Patrick Schleizer, Frédéric Pierret
On 2/6/19 11:54 AM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> It may be a good idea to introduce regular schedule for stable [point
> releases[1]. It would minimize the need to download a lot of updates
> just after installation. This is even more significant, if some updates
> may require non-standard update procedure (like installing new template
> versions). Such releases should also be coordinated with relevant
> templates maintainers.
>
> I'm not sure what such schedule should look like, every 3 months? 6 months?
>
> Any opinions?
>
> [1] https://www.qubes-os.org/doc/version-scheme/#release-version.

Using a factor other than feature sets (like time) as the determinant is
a problem. The reason is that it makes it harder for tools/apps to
target Qubes according to the version number.

If you really want to do this schedule, I recommend using a sub-point
increment (just as for bug fixes) but with a date indicator also present
in all the relevant release and package files.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Zrubi

unread,
Feb 6, 2019, 2:50:23 PM2/6/19
to Marek Marczykowski-Górecki, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2/6/19 5:54 PM, Marek Marczykowski-Górecki wrote:

> I'm not sure what such schedule should look like, every 3 months?
> 6 months?

I would synchronize this with the most used guest templates: the
Fedora and the Debian releases. Means it should not be purely time
based: see the latest debian point release.

Of course the future Xen bugs may also require a new iso.

If it is only time based, it may be happen that you release a new
Qubes iso, and in the next days debian/fedora/Xen may release a new
version. which makes the qubes release obsoleted.


- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlxbOnQACgkQVjGlenYH
FQ0P2Q/+NV7h4CnXV0/9gYU4tVNuE8d0aqSu68APxSJ1j7/1308F7WKaWBd9dvAx
gNoLi3PNBXuXUrCOleGfPF479Mzblz2sadjtzRLJ2qU70c+Zta1JX/5fw3ACADg4
y1WbTgr+qOFVgVOg+oLlaOL6elO6Wr+mdF8XhXzZQduIua3HjVmDDWQEQfgdegRc
KT9Y/VFhD+AW7BmDqPVQ47O3X0VphiEr+myszMIyBNaBBCRmDsKsJVBMGOSOwLcx
yjvjm/Wp7THaNxtz7bfMvlbekrG+r7G2CRyKpnmw6pjSlzcwwBY+e3pEWwenLCUW
uJbNg/v37qTyr/lFvksm07EbyQEg1Iumf9vx50NnPsoF7WH74BnRJVKR+4ouvpXz
asajwa+VH4iGBc3vudYEWSpiCltVpmsD2+mNI3hX3MdkNZDjWGMBFU64Cc7HChU4
8IILSv/cIWdnGo0DQqmAHV/QUXTDhNgaJ0229OkJGvocuR2ODDWzpopkbFFJWtZk
sHsFcvMJ6fUgd8STcMtAqa/4ieZGnLX3JVV8MWIyJT1CE8QRCQJS+IkB0fs5kP5O
YWt4nni6BA2llDuDVRJfLbWtd0VlAaDo6fCiwlbDaHPtIhu8Hfc8L/SpmSsbmCrf
JuqAxQDgiZLP8eOaly3EApejxiBeRzrkM2YDIMA+pgIkuT9yiIc=
=iCQo
-----END PGP SIGNATURE-----

Marek Marczykowski-Górecki

unread,
Feb 6, 2019, 2:54:31 PM2/6/19
to Zrubi, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Feb 06, 2019 at 08:50:19PM +0100, Zrubi wrote:
> On 2/6/19 5:54 PM, Marek Marczykowski-Górecki wrote:
>
> > I'm not sure what such schedule should look like, every 3 months?
> > 6 months?
>
> I would synchronize this with the most used guest templates: the
> Fedora and the Debian releases. Means it should not be purely time
> based: see the latest debian point release.
>
> Of course the future Xen bugs may also require a new iso.
>
> If it is only time based, it may be happen that you release a new
> Qubes iso, and in the next days debian/fedora/Xen may release a new
> version. which makes the qubes release obsoleted.

That's a good point!
So, maybe something like few weeks after new major template version
lands in stable repository? Which in most cases means every 6 months,
because of Fedora release cycle.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxbO3IACgkQ24/THMrX
1ywsPwf/TqGai5nqTxOS2jL5gvzQufAZ5ygMP8p43JpYs43jlCSwb+QqUdLEsTif
sIXxFMxjiXnV5z9HGLN4PxcGDktyedrxSBHDWepK/8f9ngAt8bzNtrk4cBJaW/D9
hobsEU3ohOb3lDkJEi6Gl+1NPpkox+kSWFAAx9pnCMJwtDecmacYXsaR5EkHHiSV
CsIZPLjqspALnX59Ly65H0z/aVc2Goz9xpFNEjmvuy0lb0cRfooSTgJx0r2xZTx3
o83pC4pHslRSoEqUFi/kbxdqZDEkEmwJM4jh44qja7PzEYGaNPuaO9iwuGeKxCre
zWMmbSY4/JNRUI/XyRTbCRcqLLPzeg==
=XIhX
-----END PGP SIGNATURE-----

Andrew David Wong

unread,
Feb 6, 2019, 9:54:09 PM2/6/19
to Marek Marczykowski-Górecki, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06/02/2019 1.54 PM, Marek Marczykowski-Górecki wrote:
> On Wed, Feb 06, 2019 at 08:50:19PM +0100, Zrubi wrote:
>> On 2/6/19 5:54 PM, Marek Marczykowski-Górecki wrote:
>
>>> I'm not sure what such schedule should look like, every 3
>>> months? 6 months?
>
>> I would synchronize this with the most used guest templates: the
>> Fedora and the Debian releases. Means it should not be purely
>> time based: see the latest debian point release.
>
>> Of course the future Xen bugs may also require a new iso.
>
>> If it is only time based, it may be happen that you release a
>> new Qubes iso, and in the next days debian/fedora/Xen may release
>> a new version. which makes the qubes release obsoleted.
>
> That's a good point! So, maybe something like few weeks after new
> major template version lands in stable repository? Which in most
> cases means every 6 months, because of Fedora release cycle.
>

This sounds good to me.

I agree that having more frequent point releases is a good idea, since
it makes it easier for new users to get started with Qubes and makes
it easier for existing users to upgrade. However, as others have
pointed out, this benefit doesn't require *rapid* point releases, and
there is little to be gained by trying to stick to a rigid schedule.
Event-driven at roughly six-month intervals sounds fine.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxbnbIACgkQ203TvDlQ
MDAPcRAAsY8MFH9Nw0GB0rWMmE6WfQOBAoAhWd1cpocS1Mbmu5ZPS2UE2JSBnJ+4
2HC/8zPNKBrc2fiUEk1qiyJ20PT3MoCDu86ld0Njrt7aIQyJG2CBl06qN9Fp5dfp
gVeFGJ06mdss9VwxETZIFV9tWw6KN+XK9gnh2LHCl85ikJZdeTtAlbBjBxmAio5b
iKbxRlAupQtApP6WbHS9E85C181S3KtAPqRKvyi2+Twcj3k62H23qTGWIHiKwuHd
0lvDIEGRnakiHMEBGOZJM1iu+uNE8i2P7DrLtqNyHtnlGByEGo0W29tr4mFpJTq/
ObASIC8ZtUcjgaaghZvjIWk3Lt0PfrQ3nV1mBbkmp0D5D96LgbZhxXglzA5qfobw
e2SwCHatfnSIjYMp2CZo+K8k2xCnlqWLYscdpHl1Sp0UXqpvwVcnI91E4sStBc6J
8YrCFA0Erfw5UlDF0568ElnYdVZhNUDx39n0huAuNafYbXJX8rQhBLt2fonuw1AY
ddbsVi0ZK+vPDoks/Zkxr/4ytKBpJ/6bh4NgQvrxJWwhnjBWnK+Dsq+Q1uz29Czc
72QM7B0id89/xc8lbdOdjDyZqA7i3nzVD5XQl76S2qHNCC318pI/AF+SkddYwHOw
Wl6AzvRePVGbCiIEP6WRLAe0eQ9+1xEQnhxum12S9c5XS3zOTZc=
=Q0gq
-----END PGP SIGNATURE-----


Patrick Schleizer

unread,
Feb 8, 2019, 4:28:50 AM2/8/19
to Marek Marczykowski-Górecki, qubes-devel, Andrew David Wong, Unman, Frédéric Pierret
From the Whonix side that should work quite well. Perhaps worthwhile to
automate testing after the build process somehow for some basics?

whonixcheck --verbose --leak-tests

Worthwhile to run in inside all Whonix VMs (gateway+workstation
template, anon-whonix, sys-whonix, dvm-template, and DispVM).

whonixcheck exit codes should be reliable already (or easily be fixed by
me to be made reliable). Only exception:

The "systemd-modules-load.service loaded failed failed Load Kernel
Modules" bug [1] currently results in a non-zero exit code. So I'd
either would have to relax that test or wait for that Qubes bug to be
fixed. Or manually read the output of whonixcheck.

Other prudent tests:
Check if torbrowser starts from anon-whonix and DispVM. I could add test
to "whonixcheck --test" which checks that Tor Browser indeed ended up in
user home folder and has expected hardcoded version number to automate
that as well if deemed useful.

("--test" or so meaning "for use in automated testing after template build")

Should be quite stable but not a good idea to release entirely untested
templates.

Cheers,
Patrick

[1] It's either
https://github.com/QubesOS/qubes-issues/issues/4608
and/or
https://github.com/QubesOS/qubes-issues/issues/2638

Marek Marczykowski-Górecki

unread,
Feb 8, 2019, 6:19:19 AM2/8/19
to Patrick Schleizer, qubes-devel, Andrew David Wong, Unman, Frédéric Pierret
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Feb 08, 2019 at 09:28:00AM +0000, Patrick Schleizer wrote:
> From the Whonix side that should work quite well. Perhaps worthwhile to
> automate testing after the build process somehow for some basics?
>
> whonixcheck --verbose --leak-tests
>
> Worthwhile to run in inside all Whonix VMs (gateway+workstation
> template, anon-whonix, sys-whonix, dvm-template, and DispVM).

That's a good idea. I'll add it to other qubes tests.

BTW we finally achieved the case when all integration tests succeeded in
the same test run:
https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.0&build=4.0-20190126-1&groupid=6
Even though Qubes is running inside KVM there.
This means interpreting results is much easier now. It isn't 100% stable
yet, but it is a major progress anyway.

> whonixcheck exit codes should be reliable already (or easily be fixed by
> me to be made reliable). Only exception:
>
> The "systemd-modules-load.service loaded failed failed Load Kernel
> Modules" bug [1] currently results in a non-zero exit code. So I'd
> either would have to relax that test or wait for that Qubes bug to be
> fixed. Or manually read the output of whonixcheck.
>
> Other prudent tests:
> Check if torbrowser starts from anon-whonix and DispVM. I could add test
> to "whonixcheck --test" which checks that Tor Browser indeed ended up in
> user home folder and has expected hardcoded version number to automate
> that as well if deemed useful.
>
> ("--test" or so meaning "for use in automated testing after template build")

Does it mean "whonixcheck --test" should be run in addition to
"whonixcheck --verbose --leak-tests"? Or one contain the other?

> Should be quite stable but not a good idea to release entirely untested
> templates.
>
> Cheers,
> Patrick
>
> [1] It's either
> https://github.com/QubesOS/qubes-issues/issues/4608
> and/or
> https://github.com/QubesOS/qubes-issues/issues/2638

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxdZa8ACgkQ24/THMrX
1yzOqQf6Axdc3qX7AFfaiSkNZSydpKBMo9gd8t6ZryfWBf/R/+sPpYemkDsukTbg
yXEaakpHK3rbUlFXgv/6sk0g9RcN2tfvcCtB5EFxHi9GOb0soRgKFedzq4YbhuEU
5XYvymI6dQqmOlFO7rYUhBzr+Gur3PWGkU/Lfr6Iqqp204xfVwg5ERlwsc/C/MZ0
jrVHUMt285BXOPjMN7Cs5d5fjZx5bNOog6CianrHoE0d2dt6EO2R58cHSaqqh6lU
TZeufrFaYbfE6I3nzBymUkk8vogcFs7D2KcniARVS2jAx1W97qcEzDrxMnqsh2SO
fLmxf47c1LxDBC/t7KWvJse1iAZsHA==
=RWku
-----END PGP SIGNATURE-----

Patrick Schleizer

unread,
Feb 16, 2019, 11:12:38 AM2/16/19
to Marek Marczykowski-Górecki, qubes-devel, Andrew David Wong, Unman, Frédéric Pierret, Whonix-devel
Marek Marczykowski-Górecki:>> Other prudent tests:
>> Check if torbrowser starts from anon-whonix and DispVM. I could add test
>> to "whonixcheck --test" which checks that Tor Browser indeed ended up in
>> user home folder and has expected hardcoded version number to automate
>> that as well if deemed useful.
>
>> ("--test" or so meaning "for use in automated testing after template build")
>
> Does it mean "whonixcheck --test" should be run in addition to
> "whonixcheck --verbose --leak-tests"? Or one contain the other?

That's up for consideration. Both ways are ok.

I guess an additional --test would be fine.

Note: --test does not exist yet.

Meanwhile "whonixcheck --verbose --leak-tests" will be a good start.

Cheers,
Patrick

Marek Marczykowski-Górecki

unread,
Feb 17, 2019, 8:58:53 PM2/17/19
to Patrick Schleizer, qubes-devel, Andrew David Wong, Unman, Frédéric Pierret, Whonix-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Added:
https://github.com/marmarek/openqa-tests-qubesos/commit/433b562d7d2cc51b6c0c2bb82205badb95c436e9

Example run: https://openqa.qubes-os.org/tests/1220
See "Logs & Assets" tab for detailed logs.

Note those tests are still scheduled manually. My plan is to
automatically schedule them when updates are uploaded to testing
repositories (applies to both individual packages and whole templates).
But it isn't done yet.

BTW I have a little problem with "unwanted packages" check. For
integration tests, I install several packages in templates, needed by
some tests. This include "python-pip" (because some python packages are
too old or unavailable in Debian for tests to work - applies to python-uinput and
python-dogtail). This makes "unwanted packages" check to fail.
For now I've completely separated whonixcheck run from other tests, but
this means I need to install templates for tests twice - which adds
about 30min to the whole test run. Not a big deal right now.
It would be probably unwise to disable "unwanted packages" check.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxqEVUACgkQ24/THMrX
1yzs8QgAjgBGDNL49rn1VZsrFncwL83DPICQ2OMUji7cOaIgaTPazGMeOiT4zJK3
oorlcLMLdNM25r3EkDgu/GTjfEyC5cAAeb0cE8CARhxfLjGDUVIVdiclWx56VMSn
jy3+wU1FC19i0miWjUfcbUcmcy6uG2xzhFACyNITgM4BOxfltEKDX2qV1miL4ZnT
SelbBfA0/HHXhtYscrZB/RpqDmc13qFr5eaG8DQrrSegAW8gnp5G/zEmFLq/4+cu
Jb10j0oIX1KdFPq2ZtP0xyXZCUCMS39ngROrymL6Vp4JeH+iQH0AqJ8pLQP3mC3X
YLBSIHKe0o7VrqBpzbyua8XDawf7Mg==
=v5eB
-----END PGP SIGNATURE-----

Patrick Schleizer

unread,
Feb 18, 2019, 3:06:45 AM2/18/19
to whonix...@whonix.org, Marek Marczykowski-Górecki, Patrick Schleizer, Frédéric Pierret, Unman, qubes-devel
Marek Marczykowski-Górecki:
> On Sat, Feb 16, 2019 at 04:12:00PM +0000, Patrick Schleizer wrote:
>> Marek Marczykowski-Górecki:>> Other prudent tests:
>>>> Check if torbrowser starts from anon-whonix and DispVM. I could add test
>>>> to "whonixcheck --test" which checks that Tor Browser indeed ended up in
>>>> user home folder and has expected hardcoded version number to automate
>>>> that as well if deemed useful.
>>>
>>>> ("--test" or so meaning "for use in automated testing after template build")
>>>
>>> Does it mean "whonixcheck --test" should be run in addition to
>>> "whonixcheck --verbose --leak-tests"? Or one contain the other?
>
>> That's up for consideration. Both ways are ok.
>
>> I guess an additional --test would be fine.
>
>> Note: --test does not exist yet.
>
>> Meanwhile "whonixcheck --verbose --leak-tests" will be a good start.
>
> Added:
> https://github.com/marmarek/openqa-tests-qubesos/commit/433b562d7d2cc51b6c0c2bb82205badb95c436e9
>
> Example run: https://openqa.qubes-os.org/tests/1220
> See "Logs & Assets" tab for detailed logs.
>
> Note those tests are still scheduled manually. My plan is to
> automatically schedule them when updates are uploaded to testing
> repositories (applies to both individual packages and whole templates).
> But it isn't done yet.

Awesome!

> BTW I have a little problem with "unwanted packages" check. For
> integration tests, I install several packages in templates, needed by
> some tests. This include "python-pip" (because some python packages are
> too old or unavailable in Debian for tests to work - applies to python-uinput and
> python-dogtail). This makes "unwanted packages" check to fail.
> For now I've completely separated whonixcheck run from other tests, but
> this means I need to install templates for tests twice - which adds
> about 30min to the whole test run. Not a big deal right now.

Btw usually all functions are easily skippable. Except this one. This
will be easily skippable with the next upgrade of whonixcheck which will
be soon.

Git fix:

https://github.com/Whonix/whonixcheck/commit/7dcbf0a3e48336a88739e7ca36f3c2cccdd2d27a

Once upgraded, the way to fix it is using the usual
whonixcheck_skip_functions variable mechanism.

as root:

echo 'whonixcheck_skip_functions+=" check_unwanted_packages "' >
/etc/whonix.d/40_qubes_test.conf

(And later delete /etc/whonix.d/40_qubes_test.conf if keeping the image
perhaps.)

It may be possible to expose this variable using an environment variable.

Alternatively, we could modify the whonixcheck_unwanted_package variable.

The way /usr/bin/whonixcheck looks like now...

https://github.com/Whonix/whonixcheck/blob/master/usr/bin/whonixcheck

... I did not think through yet if it would be a good idea to pass "sudo
-E" (preserve environment).

It's added in config with this:

whonixcheck_unwanted_package+=" python-pip "

/etc/whonix.d/30_whonixcheck_default.conf contains:

## To remove selected packages from the list of unwanted packages,
## you could add something like the following to your
## "/etc/whonix.d/50_whonixcheck_user.conf". (Replace the below example
that is
## using 'popularity-contest' with the actual name of the package you want
## to remove from the list.
#whonixcheck_unwanted_package="$(echo "$whonixcheck_unwanted_package" |
sed 's/ popularity-contest //g')"

So...

whonixcheck_unwanted_package="$(echo "$whonixcheck_unwanted_package" |
sed 's/ python-pip //g')"

... in config /etc/whonix.d/40_qubes_test.conf would do also.

> It would be probably unwise to disable "unwanted packages" check.

So perhaps modification of the whonixcheck_unwanted_package variable is
the way to go?

Marek Marczykowski-Górecki

unread,
Feb 20, 2019, 4:56:58 PM2/20/19
to Patrick Schleizer, whonix...@whonix.org, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Feb 18, 2019 at 08:06:00AM +0000, Patrick Schleizer wrote:
> So perhaps modification of the whonixcheck_unwanted_package variable is
> the way to go?

I've done that and indeed whonixcheck doesn't complain anymore. But it
still exit with code 1. I don't see why, as there are only INFO lines.
Full output: https://gist.github.com/marmarek/13626b87d03921e7fb199a4c6fd718cf
Any idea?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxtzSMACgkQ24/THMrX
1yzCPAf/UmCy5eIa5EUMFOoaUifEyXmi0i7HwAx/QTpwrtR9Nj8jHO5kICWiJ3Nk
KIPAjAuk63cUeOu0C9D9HsEGFAY1x44N3wTTmSzFCyrKFR/wId/mPSDe7vx1h9ji
0yG5hLK+P9ZOk4s/7MpKPuUBwUq/Klk/AdANFYRIjHbeCvUMbwYZQhs+viIeXL1N
zPwWcjdQqT1SuxwL0DkZ4Zji5EPYMZXL/uMkwvIoGfR2YSVItD18ccX8LtxdN+My
p4vB5lrAc5TQDiP1bG1G4iE1UxvtanWsIIBs6x/AAvj4eYRjWm9y0sU+toXqL6Dj
AR4dP/fwcoBliYFZj/ht6qY8PYxNyw==
=NOYm
-----END PGP SIGNATURE-----

Patrick Schleizer

unread,
Feb 23, 2019, 8:49:36 AM2/23/19
to whonix...@whonix.org, Marek Marczykowski-Górecki, Patrick Schleizer, qubes-devel
Marek Marczykowski-Górecki:
> On Mon, Feb 18, 2019 at 08:06:00AM +0000, Patrick Schleizer wrote:
>> So perhaps modification of the whonixcheck_unwanted_package variable is
>> the way to go?
>
> I've done that and indeed whonixcheck doesn't complain anymore. But it
> still exit with code 1. I don't see why, as there are only INFO lines.
> Full output: https://gist.github.com/marmarek/13626b87d03921e7fb199a4c6fd718cf
> Any idea?

This should now be fixed.

https://github.com/Whonix/whonixcheck/commit/ddae5dddb09e1194fac06701a73a21da02c34047

Marek Marczykowski-Górecki

unread,
Feb 23, 2019, 9:24:46 AM2/23/19
to Patrick Schleizer, whonix...@whonix.org, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Which repository should I enable? I see the new package is in all
stretch-testers, stretch-proposed-updates and stretch-developers.
I ask generally, not only for this instance - which testing repository
should be included in automated tests?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxxV6gACgkQ24/THMrX
1yx9Ggf7Bj+Ht1m4OdEOi75+Z2fK/82DrQN4Bjbah5VxCwyY9/Z6NU+c1jJA4Vdl
Nfd3WcimawAzN1lUyzguYKv6m+ZAaE1+fhJEZa30Dsd09e25h3i8EEc7ix+tLsNi
CpKfjyrhHoDIs912zs3RsIJReGPPl98mDZ8lXhjJZBx916mSkOTeYC75mZviXyHj
jWJ6t7vu7sUaPQ2THA0DS2o5GbuUyL9ROlolOFKpMJh3Q6V5MvSuuOYIQuFMIxBw
D5N8bQh0vXD1oxHwFHeGWDtnCV/WYVRooHOz6vZXQI3NpHRW9LjPn9wLLvumVqbN
BtPHZaSVLU+UALf/ViNzZkb1r17E9g==
=bn7M
-----END PGP SIGNATURE-----

Patrick Schleizer

unread,
Feb 23, 2019, 11:54:25 AM2/23/19
to whonix...@whonix.org, Marek Marczykowski-Górecki, qubes-devel
Marek Marczykowski-Górecki:
> On Sat, Feb 23, 2019 at 01:49:00PM +0000, Patrick Schleizer wrote:
>> Marek Marczykowski-Górecki:
>>> On Mon, Feb 18, 2019 at 08:06:00AM +0000, Patrick Schleizer wrote:
>>>> So perhaps modification of the whonixcheck_unwanted_package variable is
>>>> the way to go?
>>>
>>> I've done that and indeed whonixcheck doesn't complain anymore. But it
>>> still exit with code 1. I don't see why, as there are only INFO lines.
>>> Full output: https://gist.github.com/marmarek/13626b87d03921e7fb199a4c6fd718cf
>>> Any idea?
>
>> This should now be fixed.
>
>> https://github.com/Whonix/whonixcheck/commit/ddae5dddb09e1194fac06701a73a21da02c34047
>
> Which repository should I enable? I see the new package is in all
> stretch-testers, stretch-proposed-updates and stretch-developers.
> I ask generally, not only for this instance - which testing repository
> should be included in automated tests?

qubes-template-whonix is currently using as default:

[ -n "$whonix_repository_suite" ] ||
whonix_repository_suite="stretch-proposed-updates"

Was wondering to change that to stretch-testers but not sure.

Not sure, I guess stretch-proposed-updates should be ok until we decide
to change above?

Marek Marczykowski-Górecki

unread,
Feb 23, 2019, 12:03:27 PM2/23/19
to Patrick Schleizer, whonix...@whonix.org, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I've missed it's already enabled. It should be ok.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxxfNcACgkQ24/THMrX
1ywa7gf/RS5l8+Gi1VyTFN45AkIbOHi7fna/FJp5q+mH82ZKT6VzuKPFEcdPs4eM
2UM6c1vVnd9teZ4+me8VS+Uxkul7j3uw89kewwvHgzrjZFazhlZsYBaZdg/HGZ7U
4yOr0R7SrIDDOoEwqEgvNAXfdXeV8IGEFpFXz9zGpi02dUXlAMhWLyPhpzoETmAe
NBhO1ajiAMzgQVpG5EC+/ogPRVEG40rMgoPqzYaRmmFOEsRYbtm/tKnptssWmudQ
EMmO96nOLh26578sMpK3yMLO3nNcnkMrYoXlDleKF2r4cj3vC17wZPggEXUMdWx7
NihrgqYSYs0g0DWgjfgXRugmcEmUKg==
=+rbe
-----END PGP SIGNATURE-----

Marek Marczykowski-Górecki

unread,
Feb 25, 2019, 3:13:45 PM2/25/19
to Patrick Schleizer, whonix...@whonix.org, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The template I was testing didn't have it enabled. Enabling it helped.
And now the test passes:
https://openqa.qubes-os.org/tests/1415

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlx0THAACgkQ24/THMrX
1ywFNwgAhiOcWuBkjw/PBGPBJambLywYFLcJQ46ujk1uMLTkwfGhTRoiWEYKaJnl
aJSRvUHLj+oWGLMvhPOQZHM4ALcTzHnd0R+clj3KHwcJYZ2Kh0onAKohZVpivu6P
Y4B8Rv0BZE+zdRZsUpn/ooVQY3JQPhtpAsC/Dq3pPS2rJCqDYHpb0Am8a6MtXrJD
GLdMNnDLwAawmI5pFc5q5AnGso762eZsjF2dd9O7y+3bdP3At1MPyoQBCu6dAHBg
+MpevzO7YofxFHaTjP2E0QLfKK4XHqb2zO+MV9g8kUvUhnivtHt7gSgiqLWI6jCR
rqL2Qx4bI+iQngX4Bzrp/IURxa/Zfg==
=xvMU
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages