Re: [qubes-users] Documentation on how to setup programs or appvms to open links files in DVMs?

[Ivan Mitev]

On 12/1/18 2:08 AM, Stumpy wrote:
Are there any documents that tell how to setup either individual 
programs, or better, appvms to open links, files, etc in DVMs?
I would love to have the VM that I use for webmail to automatically open 
links or files in the webmails in a DVM, preferably with a context menu 
or something like that gives a choice of regular dvm or whonix dvm.


There is :)

https://github.com/Qubes-Community/Contents/blob/master/docs/common-tasks/opening-urls-in-vms.md

Feel free to improve the doc if you find things that aren' clear.


I found Micha Lee's page which covers this but perhaps parts of it are 
qubes 3.2 centric and dont work quite the same on 4.0?
Perhaps there are some other .desktop examples out there or a 4.0 guide 
on doing this?


Anyway.

I tried something like:
qvm-open-in-vm fedora-28-dvm https://startpage.com

and it worked, or the window popped up and I had to select fedora-28-dvm

I made a .desktop like instructed containing:
[Desktop Entry]
Encoding=UTF-8
Name=BrowserVM
Exec=qvm-open-in-vm fedora-28-dvm %u
Terminal=false
X-MultipleArgs=false
Type=Application
Categories=Network;WebBrowser;
MimeType=x-scheme-handler/unknown;x-scheme-handler/about;text/html;text/xml;application/xhtml+xml;application/xml;application/vnd.mozilla.xul+xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;x-scheme-handler/http;x-scheme-handler/https; 



but when I tried to use
xdg-settings set default-web-browser 
./local/share/applications/browser_vm.desktop


it tells me:
xdg-settings: invalid application name
Try 'xdg-settings --help' for more information.


You shouldn't use the full path. This should work:

xdg-settings set default-web-browser browser_vm.desktop




So. Am i doing something wrong in the .desktop or in using xdg-settings
and
is there a way to have it bypass the window that asks which target VM, 
or at least pulls that target vm up (as I already specified which target 
vm I wanted to send it to via qvm-open-in-vm fedora-28-dvm


Yes there is a way, you have to edit some dom0 RPC permissions to 
reflect your setup (it's in the doc too).


Ivan

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5a99ccec-f250-36c2-96fe-66e54e4d3286%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide

[alex . barinov]

Great guide! The whole process looks way more straightforward than I thought it 
is!

Do you mind sharing the resulting images for testing? I'll have hard time 
compiling this myself on old Core m3/8Gb machine...

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3ecfa794-26d0-487f-bb9e-f7b36c544a1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] alternative to bloated templates for faster work and minimal boot time/resources used

[Chris Laprise]

On 11/26/2018 06:56 AM, pieter lems wrote:

Hello Chris,
I was wondering, if i run a qube based on a fedora template it uses 
about 3.5GB of memory when just browsing. I decreased it to 2500 and it 
works exactly the same. Will there be any negative effects by decreasing 
the memory manually?

Thanks for the info btw!



Linux tends allocate whatever amount of RAM is given to it, even if that 
memory isn't put to use.


The only real negative to reducing VM memory is that it may start to use 
swap space if you open a lot of tabs. Light swap use isn't noticeable, 
but heavy swap use would make the browser noticeably slower.


You can check swap use from the VM's terminal with the 'free' command. 
I'm currently running Firefox with several windows and Thunderbird in 
one 2000MB VM now and swap use is still zero. I would expect slowdowns 
if swap use went much above 500MB.


--

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

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7b101323-d9ea-8d8d-a8f4-ee965f4a70df%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Fedora 27 has reached EOL

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

The Fedora Project announced today that Fedora 27 has reached EOL
(end-of-life [1]). We strongly recommend that all Qubes users upgrade
their Fedora 27 TemplateVMs and StandaloneVMs to Fedora 28 immediately.
We provide step-by-step upgrade instructions for upgrading from Fedora
27 to 28. [2] For a complete list of TemplateVM versions supported for
your specific version of Qubes, see the Supported TemplateVM Versions
page. [3]

We also provide a fresh Fedora 28 TemplateVM package through the
official Qubes repositories, which you can install in dom0 by following
the standard installation instructions. [4]

After upgrading your TemplateVMs, please remember to set all qubes that
were using the old template to use the new one. The instructions to do
this can be found in the upgrade instructions for Fedora 27 to 28. [2]

Please note that no user action is required regarding the OS version in
dom0. For details, please see our Note on dom0 and EOL. [5]


[1] 
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[2] https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/
[3] https://www.qubes-os.org/doc/supported-versions/#templatevms
[4] https://www.qubes-os.org/doc/templates/fedora/#installing
[5] https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2018/11/30/fedora-27-eol/

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlwCAlMACgkQ203TvDlQ
MDBdqxAAoSjAP36xt0Is/bJPjUifzGR65d5hYVaQFVirQIXYYA0y7Mc35ZeCuzH5
4E66s+DyR04axZj4yG6TCnoNYYD13RyX1gwZBz3RdeCdXvDRiM7vh5WJeb9nDtVI
WCoi0pkIxfgiZhoIesEPZV7Xnxkn1mE8elyFkTn0emOJn1PpZRX/fL1t+BHHbXcL
W7OjMVanRKAL2NKh/gjBLVxvueIB23dVOJBDeyWS2o1i5+0TX8LLqzuefqTPnEj8
3RFp8ekjE5tzdPh3J2seGo3q51m9NpWJhg+SGMR1P/J/Gvq7wpC2pf/fronWUgwc
CI8q9S72rJ/U7Mawnh9dTNg8sPZJwBmlr6jHpx+OiFGCuK/g4q9oBw2doQ2eAqcn
bCZyyYi9N4d5MV/XB47TCe3XEwE80OHfNZzkrP0+MdXLWSmTcMxX6Vi18AgLKQvc
XiWAJueXEIOfxd1mpCeVyro98OTsiinh0pjGM2zWHMIXD3iBDaDMThnrZ+fNwDo2
et9VgO3JgHi5B4hvOB0W+0Jvl8Ee531VtjJKbtWkXGKvXaFjTIT2cEtE8Hdcs25K
fsD7WnsqvHM2Z9XEmZNBMbZL90qZOUWUBoKo3P0Ay9MPVGDdm+hPd+VZtBsduGJR
ae1x2XQ83nsPTlR9GKMWZSo/fOPM5sd+mRnK20+zhdkH3iAT6wU=
=ynOl
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2a33b7b8-9f4b-12a1-d5dc-bc72eb8aba47%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes OS 3.2.1-rc1 has been released!

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/30/18 7:03 PM, unman wrote:
> On Thu, Nov 29, 2018 at 08:28:59PM -0800, Steve Phillips wrote:
>>> If you're currently using an up-to-date Qubes 3.2 installation,
>>> then your system is already equivalent to a Qubes 3.2.1
>>> installation. No action is needed.
>> 
>> Are you sure? I am on Qubes 3.2 and have installed all updates,
>> yet whenever I boot up I still receive a warning about using
>> Whonix 13 rather than 14. And when I go to create a new VM, my
>> options of TemplateVM include Debian 8 and Fedora 23, but not
>> Debian 9 nor Fedora 29.
>> 
>> Is there something we can do to force such an upgrade? Thanks.
>> 
> 
> If you have installed all updates, then your system has all the
> packages that a 3.2.1 install would have, but you have to
> separately install the templates. There is a comprehensive guide on
> upgrading from Whonix 13 to Whonix 14. For Debian 9 just 'sudo
> qubes-dom0-update qubes-template-debian-9'. Then update that
> template, clone and reconfigure as needed. Then change your qubes
> to use the new template instead of debian-8. You can do this easily
> using a batch script looping over relevant qube names. Once done
> you can delete the old template(s).
> 
> unman
> 

Yes. Part of updating a Qubes system is updating TemplateVMs (not just
dom0).

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlwB6q4ACgkQ203TvDlQ
MDBKoRAAg94HoryDCajQl9lIllp9lL7TvkEnG9lfycGBfjjAjAz0NkEeAlU0aejG
3+omDpS8aWvzpJ65hoTE5nP+CFMFacTxDqxgIZjS255Fdr8q+OM2eiIMZpEns35m
2Db9Avms1h2+Z0/DV3SPxilWuPAGpa0imZfPrADQxWeERXW/pusrADaNfoWcEqHY
uEakDJu9HKNpYAe9/+1pPsytFOyOlzTZZeBNZdLL3RhAOOJD1jZrM6LUoM74qUUw
+fRtCrvcvimX9ERF1/Xt2ksDwNio4yA5b4TUB605fFJqDY2YIGREOtyjPASsCzU2
84zuHbr2JGQrKnBqtzHGRN9C1lNFEzVVH/m3+AW9q2p98w6htJvfFVdPVDbXDFKB
/REh1oDWW/8GyhXnND6MKs9Odb+sRQ2wgO1FoNv5EPq5/Zy+eZ0eCmtE31xlmVaQ
58IRVaf5eDxxnfdKnWvjvJuKADv7LJ897WHt6e9EvhyKepQWJcFZa7KYjf98AG8B
vTTYkakTrOG3aFO5NNp1XEw4jbVxEfDke/Wu86e8BQymtJml0uY1df1DVaBRZ6jY
57QZCTBxWNVIJ7wki5hd76G3XfPR21K0GYpQDByUWAOziTyLs/aR2/lcFQfzXINy
c1VM0TR75c4MO6dx98nzux3ajitBsY+t/LX6JNjB0OoZ+8lJhyI=
=h4Xq
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e6ba025f-6e51-29a3-50bc-98ab84f5dc16%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Tor still doesn't work in the new Qubes 3.2.1

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/29/18 10:03 PM, elimist...@gmail.com wrote:
>> Qubes-Whonix support ending for Qubes 3.2(.1) - upgrade to Qubes R4.0 or
>> above required.
> 
> I don't think that is correct. Qubes 3.2 support is now gone, yes, but Qubes 
> 3.2.1 support is not since 3.2.1 runs Whonix 14: 
> https://www.qubes-os.org/news/2018/11/12/qubes-321/ .
> 

Whonix supporting Qubes is not the same as Qubes supporting Whonix:

https://www.qubes-os.org/news/2018/10/05/whonix-support-ending-for-qubes-32/#whonix-support-for-qubes-os

Whonix has ended support for Qubes 3.2, but Qubes 3.2 still supports
Whonix 14:

https://www.qubes-os.org/doc/supported-versions/#templatevms

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlwB6l8ACgkQ203TvDlQ
MDAj1g/+PzPQm5vg4BFP0pRwyMmefx+fhQxUdxwBVWvE2Gf9tG7rK2UqabyW6KS5
SfraRnvAS040dd14rO63OsnGTuP84EwMep9/oCC8F3tF/nuTUGIGtgpZe6YNia8j
FwpWBlwgmG9W9H3PiH0OFjUzILl0QOonKu4+KW+ev+ZubhI8O/h3PpuTmwkaUEjM
8KQPOOiNjj5eJtNbamHPVYDck+JsTBKqC+Erwl+2CxoWdNT8ZnTcOpaoSn3eJLvJ
mXSpAxnnyjZ+w4arOSW7xuBX35urI5iir5eWXdowJF+5XKOnKFcLpH3yyRw5TCt+
lDZMcdTM0pTCk0xAgMhpCG+itQPQ2mzkHLCq14QW+S2WWQiTaOH926fYaNO8W9d2
q0pVQbk5FmLSKahy2wEJswap8cFQ5d71Z5jxOLIy9I4w2D62uF69DpDZg0OEsQCL
49/LPOVjJp9QZCRdjHNWRThwtm7PRhwACXFIABP0/Jq2LSRn0sQMbhcM2F6GHhtb
wxh9vFESjcuUtTeQCiSfd3OiEanihdWjZoSoFE0H0qcLdlvSGK/Y6hgZSkJAQlNO
83gR8ZJxH2UkK+ou5gx6Dusw06MLVktmKFw/scrYSNRjBsgdgB3A2h+JRtMHJ/aq
c2xeppQejY3Ruhuh9d2YE9sUoV4M1ZLV++cph6ZsAKy+78Qce6E=
=LwV6
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6c74dc3c-5896-79bc-37e0-ffc218119399%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes OS 3.2.1-rc1 has been released!

[unman]

On Thu, Nov 29, 2018 at 08:28:59PM -0800, Steve Phillips wrote:
> > If you're currently using an up-to-date Qubes 3.2 installation, then 
> > your system is already equivalent to a Qubes 3.2.1 installation. No 
> > action is needed.
> 
> Are you sure? I am on Qubes 3.2 and have installed all updates, yet whenever 
> I boot up I still receive a warning about using Whonix 13 rather than 14. And 
> when I go to create a new VM, my options of TemplateVM include Debian 8 and 
> Fedora 23, but not Debian 9 nor Fedora 29.
> 
> Is there something we can do to force such an upgrade? Thanks.
> 

If you have installed all updates, then your system has all the packages
that a 3.2.1 install would have, but you have to separately install the
templates.
There is a comprehensive guide on upgrading from Whonix 13 to Whonix 14.
For Debian 9 just 'sudo qubes-dom0-update qubes-template-debian-9'. Then
update that template, clone and reconfigure as needed.
Then change your qubes to use the new template instead of debian-8. You
can do this easily using a batch script looping over relevant qube
names.
Once done you can delete the old template(s).

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20181201010353.q6t5imhtesw6ydmn%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Tor still doesn't work in the new Qubes 3.2.1

[unman]

On Thu, Nov 29, 2018 at 08:03:30PM -0800, elimist...@gmail.com wrote:
> > Qubes-Whonix support ending for Qubes 3.2(.1) - upgrade to Qubes R4.0 or
> > above required.
> 
> I don't think that is correct. Qubes 3.2 support is now gone, yes, but Qubes 
> 3.2.1 support is not since 3.2.1 runs Whonix 14: 
> https://www.qubes-os.org/news/2018/11/12/qubes-321/ .
> 

Since Patrick runs Whonix I think you should assume he is correct. :-)

If you read the announcement you will see that Whonix will not
support or address issues arising on 3.2(1).That is what Patrick said.
However Qubes WILL continue to support Whonix on 3.2.1 - this means that
Qubes will attempt to make sure that Whonix can run on 3.2.1. But if
there's a Whonix specific issue it wont get fixed.

If you want full Whonix and Qubes support you must upgrade to Whonix 14 on
Qubes 4.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2018120100.dezlxaid76ezmlh5%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN qubes preventing some websites from loading properly

[Chris Laprise]

On 11/26/2018 01:27 PM, Christophe Pfeifer wrote:

Yes, you are right, it is a binary.
I commented out these lines to no avail.

Then, I tried to locate the openvpn config file used by NordVPN's binary. 
Unfortunately, the file given in openvpn command line is removed just after it 
is launched...
Afterwards, I checked the NordVPN's logs. Indeed, there are hints that the 
tun-mtu has been negotiated.

Finally, I just reduced the tun-mtu to 1325, and it worked for UDP connections!
I didn't find any suitable values for TCP connections, but I'll go with this.

In my opinion, it is more a Qubes proxyVM-related issue, rather than bad 
NordVPN's config files. It seems that when the VPN is in a separate VM, it does 
not take into account ICMP packets, and therefore is unable to dynamically 
adapt some parameters.

Thanks for your help, I feel secure on the Internet when checking my encrypted 
mailbox now!

Christophe




Interesting... Thanks for the valuable feedback!

--

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

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/00351ab5-4fb3-0d23-2d03-70aac66911d6%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN-tunnels officially in Qubes. When?

[Chris Laprise]

On 11/27/2018 11:56 AM, qubes-...@tutanota.com wrote:

hi all, is there any plan to add the VPN tunnels officially into the Qubes?

https://github.com/tasket/Qubes-vpn-support 


Would be nice if less-tech people could benefit from the default setup, if 
working.

Thank you :)



This would be best asked in qubes-devel. If I had to guess I'd say we'll 
see it in R4.1.


--

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

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ad3c92a9-d3fd-f760-0b47-3755b60b62e1%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Documentation on how to setup programs or appvms to open links files in DVMs?

[Stumpy]

Are there any documents that tell how to setup either individual 
programs, or better, appvms to open links, files, etc in DVMs?
I would love to have the VM that I use for webmail to automatically open 
links or files in the webmails in a DVM, preferably with a context menu 
or something like that gives a choice of regular dvm or whonix dvm.


I found Micha Lee's page which covers this but perhaps parts of it are 
qubes 3.2 centric and dont work quite the same on 4.0?
Perhaps there are some other .desktop examples out there or a 4.0 guide 
on doing this?


Anyway.

I tried something like:
qvm-open-in-vm fedora-28-dvm https://startpage.com

and it worked, or the window popped up and I had to select fedora-28-dvm

I made a .desktop like instructed containing:
[Desktop Entry]
Encoding=UTF-8
Name=BrowserVM
Exec=qvm-open-in-vm fedora-28-dvm %u
Terminal=false
X-MultipleArgs=false
Type=Application
Categories=Network;WebBrowser;
MimeType=x-scheme-handler/unknown;x-scheme-handler/about;text/html;text/xml;application/xhtml+xml;application/xml;application/vnd.mozilla.xul+xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;x-scheme-handler/http;x-scheme-handler/https;

but when I tried to use
xdg-settings set default-web-browser 
./local/share/applications/browser_vm.desktop


it tells me:
xdg-settings: invalid application name
Try 'xdg-settings --help' for more information.


So. Am i doing something wrong in the .desktop or in using xdg-settings
and
is there a way to have it bypass the window that asks which target VM, 
or at least pulls that target vm up (as I already specified which target 
vm I wanted to send it to via qvm-open-in-vm fedora-28-dvm


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1d5583a1-9bd1-c988-e0de-d7608d1a947d%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] storing window layout? (qubes-manager for example?)

[schadensregulierung]

Am Freitag, 30. November 2018 08:00:35 UTC+1 schrieb Ivan Mitev:
> On 11/30/18 4:35 AM, n1ete wrote:
> > Is there a way to store the Window Layout from different dom0 applications? 
> > or at least for Qubes Manager? i pull pretty often the panes to the right 
> > size, just to do it after an reboot again. not that its that important 
> > tough but it would be nice to save this amount of personalisation :D
> 
> Long ago I used devilspie for that purpose.
> 
> I just checked, Fedora packages it so you can install it in dom0 with:
> 
> sudo qubes-dom0-update devilspie
> 
> See this guide for configuration (it's for ubuntu but that shouldn't 
> really matter):
> 
> https://help.ubuntu.com/community/Devilspie

thanks,didnt heard of devilspie yet. i will check it out soon and  report back 
what i archivedalthough i try to install as less as i can in dom0 and would 
prefer something what i can put in my dom0 managment script folder for instance 
;)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d9185a9d-16c3-4fba-b949-336ebabefda4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix GW & WS upgrade failed (Help)

[qubes123456]

I try to fix the errors without reinstalation, if that does not work then I'll 
be back, if anyone has something else please write;)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/856c0852-5c3e-446a-9476-df08f502132d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Problem setting up Enigmail with SplitGPG (Thunderbird 60.2.1 + Enigmail 2.0.8 + Fedora 28)

[mossy]

799:
> I have setup /rw/config/gpg-split-domain to include the Vault AppVM as
> described in the Qubes 3.2 documentation.
> It seems that Enigmail needs this setting.

hey thanks to both of you for troubleshooting this, indeed this is
required and fixed my enigmail split-gpg woes under whonix-ws-14.

go, qubes community!

-m0ssy

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f7577585-0cb9-4309-2d90-df6bbc9a32d1%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] pEp in Enigmail-Thunderbird in Whonix-14 Qubes

[mossy]

mossy:
> Patrick Schleizer:
>> qubes-...@tutanota.com:
>>> Hi, I learned that in Whonix-14 in Qubes 4.0 there is no default support 
>>> for pEp in Enigmail-Thunderbird. Is it Qubes specific or Whonix specific? 
>>> Is there any reason for not supporting pEp in Whonix? 
>>>
>>> In other templates after installing the Enigmail addon the support for pEp 
>>> jumps up automatically like Enigmail/pEp.
>>>
>>> Thank you!
>>>
>>
>> Whonix uses the same package as Debian. So Debian specific and Whonix
>> inherits this.
>>
>> This sort of question has a much higher chance of getting answered
>> timely in Whonix forums.
>>
>> Check this out:
>>
>> https://www.whonix.org/wiki/Encrypted_Email_with_Thunderbird_and_Enigmail
>>
>> This may be useful later:
>>
>> https://www.whonix.org/wiki/E-Mail#Pretty_Easy_Privacy
>>
> 
> Thanks, Patrick for all your excellent work -- I wonder if you have many
> users using qubes-split-gpg.  it used to work on my whonix-ws-14
> (in-place upgrade path from whonix 13 workstation) but since starting
> fresh with qubes 4.0.1_rc1 thunderbird in whonix seems to no longer
> recognize /usr/bin/qubes-gpg-client-wrapper as a valid GnuPG install
> (states "Could not find GnuPG" under enigmail preferences.
> 
> I believe the fresh qubes template whonix-ws-14 is the cause.  Two reasons:
> 
> 1-`qubes-gpg-client-wrapper -K` or `qubes-gpg-client -K` both
> successfully list the gpg private key stored in the offline vault appVM.
> 
> 2-qubes-split-gpg works normally in thunderbird running in a non-whonix
> (debian-9), with identical thunderbird versions 60.3.0 64-bit)
> 
> I'll cross post in Whonix forums as well, putting in here in case other
> qubes-split-gpg users have had similar experiences or ideas.
> 
> -m0ssy
> 

thanks to other (whonix or not) split-gpg users, I tried adding the file
(listing the name of my vault domain):

/rw/config/gpg-split-domain

and now all is well.

thank you again!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/be5b6155-d42a-0036-270b-3390bd39dc2b%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] pEp in Enigmail-Thunderbird in Whonix-14 Qubes

[mossy]

Patrick Schleizer:
> qubes-...@tutanota.com:
>> Hi, I learned that in Whonix-14 in Qubes 4.0 there is no default support for 
>> pEp in Enigmail-Thunderbird. Is it Qubes specific or Whonix specific? Is 
>> there any reason for not supporting pEp in Whonix? 
>>
>> In other templates after installing the Enigmail addon the support for pEp 
>> jumps up automatically like Enigmail/pEp.
>>
>> Thank you!
>>
> 
> Whonix uses the same package as Debian. So Debian specific and Whonix
> inherits this.
> 
> This sort of question has a much higher chance of getting answered
> timely in Whonix forums.
> 
> Check this out:
> 
> https://www.whonix.org/wiki/Encrypted_Email_with_Thunderbird_and_Enigmail
> 
> This may be useful later:
> 
> https://www.whonix.org/wiki/E-Mail#Pretty_Easy_Privacy
> 

Thanks, Patrick for all your excellent work -- I wonder if you have many
users using qubes-split-gpg.  it used to work on my whonix-ws-14
(in-place upgrade path from whonix 13 workstation) but since starting
fresh with qubes 4.0.1_rc1 thunderbird in whonix seems to no longer
recognize /usr/bin/qubes-gpg-client-wrapper as a valid GnuPG install
(states "Could not find GnuPG" under enigmail preferences.

I believe the fresh qubes template whonix-ws-14 is the cause.  Two reasons:

1-`qubes-gpg-client-wrapper -K` or `qubes-gpg-client -K` both
successfully list the gpg private key stored in the offline vault appVM.

2-qubes-split-gpg works normally in thunderbird running in a non-whonix
(debian-9), with identical thunderbird versions 60.3.0 64-bit)

I'll cross post in Whonix forums as well, putting in here in case other
qubes-split-gpg users have had similar experiences or ideas.

-m0ssy

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/36d543b6-3c15-ddc5-7bbb-58a49e28c1b0%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] QJackctl starting on Qubes 4.0

[Ivan Mitev]

On 11/30/18 5:41 PM, maxheadonl...@gmail.com wrote:

On Thursday, November 29, 2018 at 3:37:29 AM UTC-5, Ivan Mitev wrote:

On 11/28/18 7:01 PM, maxheadonl...@gmail.com wrote:

On Sunday, November 25, 2018 at 7:38:24 AM UTC-5, awokd wrote:

maxheadonl...@gmail.com wrote on 11/24/18 7:45 PM:

Hi all.

I've put enough time into this one where I'm finally willing to reach out for 
some help.  I wanted to see if I could create an AppVm dedicated to music 
creation, using QJackCtl and other open source software.

However, I'm having a terrible time at even getting Jack Audio off of the floor.

System: Base Qubes 4.0 installation, Fedora 28 template, Thinkpad T480 w/32Gb 
RAM.

Expected results: Pressing "Start" on the QJackCtl GUI starts the server, per 
the online manuals and Fedora's Musician documentation.

Actual results: Receive the "Could not connect to JACK server as client. - Overall 
operation failed. - Unable to connect to server." error.

Tried so far: Following online documentation (treating the AppVM as a standard 
Fedora installation), assigning the Audio PCI of the computer to that VM via 
the Qubes Manager.

I'm totally willing to have this be something simple and embarrassing as I 
learn the OS.  Any help that you can provide would be much appreciated!


If I understand Qubes' audio right, Pulseaudio inside AppVMs gets
redirected to dom0's Pulseaudio which normally controls the sound
hardware. So if you want to override that, maybe try setting up an HVM
with the audio device assigned and without Qubes Pulseaudio redirection.
Think there's a Qubes package that does it so don't install that one in
the HVM.


Thanks, awokd.  I tried passing through the audio PCI, but didn't get any 
farther than the 'Settings' tab in Qjackctl.  I could get Jack to recognize the 
sound card, but couldn't get the server to actually start.

If anyone else has success in implementing Jack Audio (or configuring an audio 
creation VM in Qubes/Xen), please don't hesitate to contact me!


Not meaning to discourage you but latency sensitive stuff will be a
hit-or-miss with virtualization (and by experience misses unfortunately
far outweigh hits). That's because of inaccuracies with the guest OS'
virtualized timer and/or how host resources are prioritized and
allocated to the guests.

With Qubes: my quality USB DAC constantly outputs audible clicks despite
being fed a data stream directly from sys-usb (ie. it's not
"pass-through'ed" to another VM). The same DAC works perfectly well on
other laptops (including a 10+ year old one) without virtualization.
It's USB though, and USB audio sucks so YMMV :)

I do hope you'll manage to have your setup working properly. If not I'd
advise that you buy/use an old laptop dedicated to your audio creation
tasks. That way you could install an audio focused distribution (like
Ubuntu Studio [1], AV Linux [2] - and probably others), as those
distributions package all the popular apps and may provide so-called
realtime kernels that help with latency and jitter.

You could also try to install such a distribution as a HVM in Qubes and
see how it works.

[1] https://ubuntustudio.org/
[2] http://www.bandshed.net/avlinux/





If this is the intended sound set up for Qubes, it makes sense and I'll instead 
try the HVM approach to create my audio VM.  I'll address the issues that I've 
found so far in that attempt in another thread.

Excellent community, thank you!

- Max



Thank you, Ivan. It's good to hear that there are other Qubes/VM musician types 
out there in the world.


:)


I would like to test to the situation described above by getting a MIDI device 
to be recognized by this HVM.

I made a HVM that boots fine, but when I attempt to pass the attached 
MIDI-device to this HVM, I received an error related to qrexec.

Do devices not pass-through to HVMs as with AppVMs, using the menu in the upper 
right of XFCE?


They should, provided the target VM *supports* it.

Did you install your HVM with an iso downloaded from the distribution's 
site ? If yes, support for qubes won't be included by default.


In case you installed Ubuntu, have a look at unman's templates and 
packages [1]. You should be able to add the proper packages (looks like 
'qubes-core-agent-qrexec' - however I have 0 experience with 
ubuntu/debian so I can't really help ; I'm sure unman will chime in if 
you have any problem though !).


You wrote you were using a laptop so I'm assuming you're trying to 
attach a USB device. You will be aiming for the the worst case though :)

- USB controllers on a different VM (resource sharing + timing issues)
- + another amount of latency/jitter/resource consumption because of 
passthrough itself
- + no guarantee that passthrough will even work (by experience it's a 
hit-or-miss for "non-storage" devices).


For your tests I think it would be much faster and easier for you to 
assign the USB controller(s) to your HVM and see how your device works. 
That way you won't spend time 

Re: [qubes-users] HVM Creation - immediate shutdown after boot

[maxheadonline]

On Friday, November 30, 2018 at 10:51:50 AM UTC-5, pieter lems wrote:
> On Fri, Nov 30, 2018, 1:58 AM unman  wrote:
> On Thu, Nov 29, 2018 at 09:35:58PM +0100, pieter lems wrote:
> 
> > Hello max,
> 
> > I think i know the answer to both questions but if there is something wrong
> 
> > please correct me. (to the people that know a lot about qubes)
> 
> > Regarding your first question. The download did indeed fail  because there
> 
> > was not enough disk space on your qube. I've had the same problem multiple
> 
> > times but increasing the available disk space should solve the problem.
> 
> > This can be done by increasing the private storage size in the qubes
> 
> > settings manager.
> 
> > As far as i know is the /rw folder the folder which is persistent after a
> 
> > restart of the qube. The rw folder contains configuration files concerning
> 
> > the specific qube. Did you maybe point the iso download to the rw folder?
> 
> > this could be the reason why its 100% full.
> 
> > 
> 
> > Regarding your second question, Ive had the same problem while installing a
> 
> > kali iso. Increasing the max memory to 8GB solved the problem for me. This
> 
> > can be done under the advanced tab in the qubes settings manager.
> 
> > I hope some of this info can help you out.
> 
> > Goodluck!
> 
> > 
> 
> > Op do 29 nov. 2018 om 21:19 schreef :
> 
> > 
> 
> > > Next in my qubes learning is the creation of a HVM.  I noticed a couple
> 
> > > things through the process and wanted to get comments on some of the
> 
> > > hang-ups.
> 
> > >
> 
> > > First step was to download an .iso into one of my AppVMs.  During this
> 
> > > process, the  AppVMs were failing downloads after a couple of minutes. I
> 
> > > suspected it was because that they were filling up their disk space, even
> 
> > > with no other files on the AppVM.
> 
> > >
> 
> > > After running a 'df -h' I noticed that the "rw" drive was at 100% (is this
> 
> > > something Qubes specific?), even after expanding the AppVMs through Qubes
> 
> > > Manager.
> 
> > >
> 
> > > 1.  What might be causing this?  What is the "rw" drive?
> 
> > >
> 
> > > I circumvented this holdup by creating a new AppVM with enough space to
> 
> > > download the .iso.  After creating the StandadloneVM and pointing its boot
> 
> > > 'cdrom' to the .iso file in the AppVM mentioned above, the opening screen
> 
> > > of the OS appears and is interactive.  However, after choosing to boot the
> 
> > > OS, the screen quickly closes and the StandaloneVM shuts down.
> 
> > >
> 
> > > 2.  What do you suspect causes this?  The StandaloneVM has been allocated
> 
> > > 15GB of space and left the default 4GB RAM.
> 
> > >
> 
> > >
> 
> > > System: Base Qubes 4.0 installation, Fedora 28 template, Thinkpad T480
> 
> > > w/32Gb RAM.
> 
> > >
> 
> > > Expected results: StandaloneVM boots into basic OS configuration wizard
> 
> > > for the .iso and installation can proceed.
> 
> > >
> 
> > > Thanks again for any help in advance!
> 
> > >
> 
> > > - Max
> 
> > >
> 
> 
> 
> Pieter - can you remember not to top post please?
> 
> 
> 
> You're partly right about /rw - it contains configuration, /usr/local
> 
> and /home.
> 
> That's why the download ran out of space because /rw is created by
> 
> default at 2G. You can change this under settings. /home/user is stored
> 
> there so Downloads can rapidly fill that space.
> 
> 
> 
> As to booting StandaloneVM, 4GB should be fine, depending on the OS -
> 
> certainly enough for kali.
> 
> Also worth checking that you have kernel set to '', (and maybe virt_mode
> 
> hvm)
> 
> 
> 
> unman
> 
> 
> Hi , im sorry im kinda new to this google-groups feature.
> 
>     About the initial question. Iknow 4gb should be enough but it only worked 
> after setting the max value to 8GB.
> 
> 
> -- 
> 
> You received this message because you are subscribed to the Google Groups 
> "qubes-users" group.
> 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to qubes-users...@googlegroups.com.
> 
> To post to this group, send email to qubes...@googlegroups.com.
> 
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/20181130005824.bfm35u4ue6b4adhk%40thirdeyesecurity.org.
> 
> For more options, visit https://groups.google.com/d/optout.

You were right!  The .iso needed more RAM initially allocated to it beyond the 
default values.

As for /rw, that was not only reading the Qubes introductory information but 
also seeing it in action that helped me understand.

Thank you both so much.

- Max

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 

Re: [qubes-users] HVM Creation - immediate shutdown after boot

[pieter lems]

On Fri, Nov 30, 2018, 1:58 AM unman  wrote:

> On Thu, Nov 29, 2018 at 09:35:58PM +0100, pieter lems wrote:
> > Hello max,
> > I think i know the answer to both questions but if there is something
> wrong
> > please correct me. (to the people that know a lot about qubes)
> > Regarding your first question. The download did indeed fail  because
> there
> > was not enough disk space on your qube. I've had the same problem
> multiple
> > times but increasing the available disk space should solve the problem.
> > This can be done by increasing the private storage size in the qubes
> > settings manager.
> > As far as i know is the /rw folder the folder which is persistent after a
> > restart of the qube. The rw folder contains configuration files
> concerning
> > the specific qube. Did you maybe point the iso download to the rw folder?
> > this could be the reason why its 100% full.
> >
> > Regarding your second question, Ive had the same problem while
> installing a
> > kali iso. Increasing the max memory to 8GB solved the problem for me.
> This
> > can be done under the advanced tab in the qubes settings manager.
> > I hope some of this info can help you out.
> > Goodluck!
> >
> > Op do 29 nov. 2018 om 21:19 schreef :
> >
> > > Next in my qubes learning is the creation of a HVM.  I noticed a couple
> > > things through the process and wanted to get comments on some of the
> > > hang-ups.
> > >
> > > First step was to download an .iso into one of my AppVMs.  During this
> > > process, the  AppVMs were failing downloads after a couple of minutes.
> I
> > > suspected it was because that they were filling up their disk space,
> even
> > > with no other files on the AppVM.
> > >
> > > After running a 'df -h' I noticed that the "rw" drive was at 100% (is
> this
> > > something Qubes specific?), even after expanding the AppVMs through
> Qubes
> > > Manager.
> > >
> > > 1.  What might be causing this?  What is the "rw" drive?
> > >
> > > I circumvented this holdup by creating a new AppVM with enough space to
> > > download the .iso.  After creating the StandadloneVM and pointing its
> boot
> > > 'cdrom' to the .iso file in the AppVM mentioned above, the opening
> screen
> > > of the OS appears and is interactive.  However, after choosing to boot
> the
> > > OS, the screen quickly closes and the StandaloneVM shuts down.
> > >
> > > 2.  What do you suspect causes this?  The StandaloneVM has been
> allocated
> > > 15GB of space and left the default 4GB RAM.
> > >
> > >
> > > System: Base Qubes 4.0 installation, Fedora 28 template, Thinkpad T480
> > > w/32Gb RAM.
> > >
> > > Expected results: StandaloneVM boots into basic OS configuration wizard
> > > for the .iso and installation can proceed.
> > >
> > > Thanks again for any help in advance!
> > >
> > > - Max
> > >
>
> Pieter - can you remember not to top post please?
>
> You're partly right about /rw - it contains configuration, /usr/local
> and /home.
> That's why the download ran out of space because /rw is created by
> default at 2G. You can change this under settings. /home/user is stored
> there so Downloads can rapidly fill that space.
>
> As to booting StandaloneVM, 4GB should be fine, depending on the OS -
> certainly enough for kali.
> Also worth checking that you have kernel set to '', (and maybe virt_mode
> hvm)
>
> unman
>
> Hi , im sorry im kinda new to this google-groups feature.
>
About the initial question. Iknow 4gb should be enough but it only
worked after setting the max value to 8GB.

> --
> You received this message because you are subscribed to the Google Groups
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/20181130005824.bfm35u4ue6b4adhk%40thirdeyesecurity.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAK8vAnV0-_FCsungKn7ew%2BuMFuE8x3m1usRC01t0zjiNXbk%3DUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: The state of the HiDPI display support in Qubes

[Ivan Mitev]

On 11/30/18 11:22 AM, Achim Patzner wrote:

Am Donnerstag, den 29.11.2018, 09:16 +0200 schrieb Ivan Mitev:

The following might help to work around your issues:

https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dpi-scaling.md


It is solving a few of the issues but you definitely need more (like
HiDPI themes in several sizes). Or moving new Xresources into templates
(or VMs) if they change in dom0. And dealing with xsettingsd.


As a side note the doc is meant to be a "workaround" guide until issue 
#1951 is closed/fixed. My screen isn't HiDPI but has a resolution large 
enough that I have to scale things up, however I never had a need for 
such themes. A PR to the doc with a section about those could be a 
welcome addition...



Especially xsettingsd -- it would be an ideal point of attack if Qubes
had a dedicated UI (or UX in techno hipster speak) team. Just give it
another database backend for its settings that was maintained in dom0
and accessible to all running VMs and you could easily change settings
in everything running on your system.


I don't use/have xsettings on my fedora vms. Did you install it ? If 
yes, what for ? Or is it maybe something that Debian uses by default ?


As to how to solve that, Qubes' policy is to keep the distribution 
settings as close as possible to upstream but HiDPI is an important 
issue so it could trump that rule. But if it does, the changes would 
have to be minimal. AFAICT the common denominator is Xresources' Xft.dpi 
so that'd mean relying on that + making sure gnome settings isn't running.
Also, any "HiDPI configuration" dom0-vm communication would likely be 
implemented through QubesDB keys and/or dedicated qrexec service.


But none of the above solves the problem for OSes that don't use an X 
server.


(Anecdote: I sometimes have to use a program in a windows HVM that 
supports only an older version of JRE which doesn't have support for 
font/dpi scaling. I literally have to be 10cm close to the screen to be 
able to read something if I don't change my monitor's resolution 
*globally* to a lower one (in dom0 with xrandr). I even have a keyboard 
shortcut to switch between the lower resolution and the default one.)




Granted, having a "scale everything by a factor X" option in dom0
would be way better


It is necessary unless you like using a microscope for HVMs. In a few
months we will see the first 12" mobile computers running at mobile
phone resolutions...


but it'd be nearly impossible to implement/support if the
config has to be passed down to the VMs.


Not at all. The currently implemented mechanisms for the virtual X
servers are not working perfectly yet but that could be changed. It
just won't solve the problem of xsettingsd messing everything up
(including Xft settings which are coming from Xresources and
.xresources) if it does not have the correct parameters in its
database. So all we have to take care of was getting the databases in
all VMs right -- or implement a central one. If one was mad enough he
could use the qubesdb which is already accessible everywhere.


No need to be mad to use qubesdb :)


I'm wondering if it couldn't be solved at a lower level

[...]

That could also end up being very CPU intensive.


You should let the GPU handle that; applying transformations is a
standard feature today.


In theory yes but I'm not sure it is feasible given Qubes' architecture.

BTW, my "low level" suggestion is more or less what xrandr does, except 
that xrand is "global", so no per-vm customization is possible.


Ivan

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d09f76c5-8356-acf2-3c32-0486e5576994%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anyone bought a Dell laptop recently that works with V4

[Chris]

Thank you all for your advice.

Regards,

Chris


-
Chris Willard
ch...@meliser.co.uk

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/pNiX4FU0D2Ma-9AWrdvTPtNpa3kewVuWOqKfN-i7TdSQZtVyYwIg0CfzCCkeZIXwjxBXvZ6YIodSCuMpT57LFhwb-OGVzIkWL2MY5wA-SRo%3D%40meliser.co.uk.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] QJackctl starting on Qubes 4.0

[maxheadonline]

On Thursday, November 29, 2018 at 3:37:29 AM UTC-5, Ivan Mitev wrote:
> On 11/28/18 7:01 PM, maxheadonl...@gmail.com wrote:
> > On Sunday, November 25, 2018 at 7:38:24 AM UTC-5, awokd wrote:
> >> maxheadonl...@gmail.com wrote on 11/24/18 7:45 PM:
> >>> Hi all.
> >>>
> >>> I've put enough time into this one where I'm finally willing to reach out 
> >>> for some help.  I wanted to see if I could create an AppVm dedicated to 
> >>> music creation, using QJackCtl and other open source software.
> >>>
> >>> However, I'm having a terrible time at even getting Jack Audio off of the 
> >>> floor.
> >>>
> >>> System: Base Qubes 4.0 installation, Fedora 28 template, Thinkpad T480 
> >>> w/32Gb RAM.
> >>>
> >>> Expected results: Pressing "Start" on the QJackCtl GUI starts the server, 
> >>> per the online manuals and Fedora's Musician documentation.
> >>>
> >>> Actual results: Receive the "Could not connect to JACK server as client. 
> >>> - Overall operation failed. - Unable to connect to server." error.
> >>>
> >>> Tried so far: Following online documentation (treating the AppVM as a 
> >>> standard Fedora installation), assigning the Audio PCI of the computer to 
> >>> that VM via the Qubes Manager.
> >>>
> >>> I'm totally willing to have this be something simple and embarrassing as 
> >>> I learn the OS.  Any help that you can provide would be much appreciated!
> >>
> >> If I understand Qubes' audio right, Pulseaudio inside AppVMs gets
> >> redirected to dom0's Pulseaudio which normally controls the sound
> >> hardware. So if you want to override that, maybe try setting up an HVM
> >> with the audio device assigned and without Qubes Pulseaudio redirection.
> >> Think there's a Qubes package that does it so don't install that one in
> >> the HVM.
> > 
> > Thanks, awokd.  I tried passing through the audio PCI, but didn't get any 
> > farther than the 'Settings' tab in Qjackctl.  I could get Jack to recognize 
> > the sound card, but couldn't get the server to actually start.
> > 
> > If anyone else has success in implementing Jack Audio (or configuring an 
> > audio creation VM in Qubes/Xen), please don't hesitate to contact me!
> 
> Not meaning to discourage you but latency sensitive stuff will be a 
> hit-or-miss with virtualization (and by experience misses unfortunately 
> far outweigh hits). That's because of inaccuracies with the guest OS' 
> virtualized timer and/or how host resources are prioritized and 
> allocated to the guests.
> 
> With Qubes: my quality USB DAC constantly outputs audible clicks despite 
> being fed a data stream directly from sys-usb (ie. it's not 
> "pass-through'ed" to another VM). The same DAC works perfectly well on 
> other laptops (including a 10+ year old one) without virtualization. 
> It's USB though, and USB audio sucks so YMMV :)
> 
> I do hope you'll manage to have your setup working properly. If not I'd 
> advise that you buy/use an old laptop dedicated to your audio creation 
> tasks. That way you could install an audio focused distribution (like 
> Ubuntu Studio [1], AV Linux [2] - and probably others), as those 
> distributions package all the popular apps and may provide so-called 
> realtime kernels that help with latency and jitter.
> 
> You could also try to install such a distribution as a HVM in Qubes and 
> see how it works.
> 
> [1] https://ubuntustudio.org/
> [2] http://www.bandshed.net/avlinux/
> 
> 
> 
> 
> > If this is the intended sound set up for Qubes, it makes sense and I'll 
> > instead try the HVM approach to create my audio VM.  I'll address the 
> > issues that I've found so far in that attempt in another thread.
> > 
> > Excellent community, thank you!
> > 
> > - Max
> >

Thank you, Ivan. It's good to hear that there are other Qubes/VM musician types 
out there in the world.

I would like to test to the situation described above by getting a MIDI device 
to be recognized by this HVM.

I made a HVM that boots fine, but when I attempt to pass the attached 
MIDI-device to this HVM, I received an error related to qrexec.

Do devices not pass-through to HVMs as with AppVMs, using the menu in the upper 
right of XFCE?

- Max

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ccd7c12a-a843-4e12-be6b-cd11f17a035e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Android-x86 7.1-r2 with GAPPS installation guide

[alex . jones . 4416]

I've successfully build android-x86 7.1-r2 with gapps in whonix-14-ws AppVM.

1. Install packages in whonix-14-ws template:

sudo apt-get install openjdk-8-jdk git-core gnupg flex bison gperf 
build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 
lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev libgl1-mesa-dev 
libxml2-utils xsltproc unzip gettext python-pip libyaml-dev dosfstools syslinux 
syslinux-utils xorriso mtools makebootfat lunzip

2. Create builder AppVM based on whonix-14-ws in which you'll build android-x86:
You'll need 120GB for android-x86 sources and temp build files and 30GB for 
swap.
Extend private storage size to 160GB via GUI or in dom0:
qvm-volume extend android-builder:private 160g

Add 30GB swap in builder VM:

sudo dd if=/dev/zero of=/rw/swapfile bs=1024 count=31457280
sudo chown root:root /rw/swapfile
sudo chmod 0600 /rw/swapfile
sudo mkswap /rw/swapfile
sudo swapon /rw/swapfile

In builder VM run:

sudo ln -s /sbin/mkdosfs /usr/local/bin/mkdosfs
sudo pip install prettytable Mako pyaml dateutils --upgrade
export _JAVA_OPTIONS="-Xmx8G"
echo 'export _JAVA_OPTIONS="-Xmx8G"' >> ~/.profile
echo "sudo swapon /rw/swapfile" >> /rw/config/rc.local

Download android-x86 sources:

mkdir android-x86
cd android-x86
curl https://storage.googleapis.com/git-repo-downloads/repo > repo
chmod a+x repo
sudo install repo /usr/local/bin
rm repo
git config --global user.name "Your Name"
git config --global user.email "y...@example.com"
repo init -u git://git.osdn.net/gitroot/android-x86/manifest -b 
android-x86-7.1-r2

To add GAPPS to your build you need to add the build system, and the wanted 
sources to your manifest.
Edit .repo/manifests/default.xml and add the following towards the end:

https://github.com/opengapps/;  />





Download sources:
repo sync --no-tags --no-clone-bundle --force-sync -j$( nproc --all )

If you choose to add GAPPS, then edit file device/generic/common/device.mk and 
add at the beginning:

#OpenGAPPS

GAPPS_VARIANT := pico

GAPPS_PRODUCT_PACKAGES += Chrome \
KeyboardGoogle \
LatinImeGoogle \
GoogleTTS \
YouTube \
PixelIcons \
PixelLauncher \
Wallpapers \
PixelLauncherIcons \
WebViewGoogle \
GoogleServicesFramework \
GoogleLoginService \

GAPPS_FORCE_BROWSER_OVERRIDES := true
GAPPS_FORCE_PACKAGE_OVERRIDES := true

GAPPS_EXCLUDED_PACKAGES := FaceLock \
AndroidPlatformServices \
PrebuiltGmsCoreInstantApps \

And at the end add:

#OpenGAPPS
$(call inherit-product, vendor/opengapps/build/opengapps-packages.mk)

Edit android-x86 sources for XEN compatibility:
sed -i -e 's|/sys/block/\[shv\]d\[a-z\]|/sys/block/\[shv\]d\[a-z\] 
/sys/block/xvd\[a-z\]|g' bootable/newinstaller/install/scripts/1-install
sed -i -e 's|/sys/block/\[shv\]d\$h/\$1|/sys/block/\[shv\]d\$h/\$1 
/sys/block/xvd\$h/\$1|g' bootable/newinstaller/install/scripts/1-install
sed -i -e 's|hmnsv|hmnsvx|g' bootable/newinstaller/initrd/init

Edit android-x86 sources for Debian build environment:
sed -i -e 's|genisoimage|xorriso -as mkisofs|g' bootable/newinstaller/Android.mk

Configure build target:
. build/envsetup.sh
lunch android_x86_64-eng

Configure kernel:
make -C kernel O=$OUT/obj/kernel ARCH=x86 menuconfig
You need to edit these parameters:
XEN=yes
XEN_BLKDEV_BACKEND=yes
XEN_BLKDEV_FRONTEND=yes
XEN_NETDEV_BACKEND=no
XEN_NETDEV_FRONTEND=no
SECURITY_SELINUX_BOOTPARAM=yes
SECURITY_SELINUX_BOOTPARAM_VALUE=1
SECURITY_SELINUX_DISABLE=yes
DEFAULT_SECURITY_SELINUX=yes

The kernel config will be in out/target/product/x86_64/obj/kernel/.config

Also, you can edit the config to set the device type from tablet to phone.
Edit device/generic/common/device.mk and change PRODUCT_CHARACTERISTICS from 
tablet to default:
PRODUCT_CHARACTERISTICS := default

Start the build:
m -j$( nproc --all ) iso_img

After you got the iso, create the android network VM. If you choose the android 
VM's netvm as sys-whonix directly, the network won't work. You need to have 
intermediate netvm between android VM and sys-whonix. Create new AppVM 
sys-android based on fedora template with netvm sys-whonix and set "provides 
network".

Create android VM in dom0:
qvm-create --class StandaloneVM --label green --property virt_mode=hvm android
qvm-prefs android kernel ''
qvm-prefs android 'sys-android'
qvm-prefs android memory '2048'
qvm-prefs android maxmem '2048'
qvm-volume extend android:root 20g

Start the android VM with iso:
qvm-start android 
--cdrom=android-builder:/home/user/android-x86/out/target/product/x86_64/android_x86_64.iso

Install android-x86 on xvda and reboot.

Start android VM without iso:
qvm-start android
When it'll start, kill the VM and wait for it to halt.
Configure android VM to use the mouse in dom0:
sudo mkdir -p /etc/qubes/templates/libvirt/xen/by-name/
sudo cp /etc/libvirt/libxl/android.xml 
/etc/qubes/templates/libvirt/xen/by-name/android.xml
sudo sed -i -e 's/tablet/mouse/g' 
/etc/qubes/templates/libvirt/xen/by-name/android.xml

Start android 

Re: [qubes-users] Anyone bought a Dell laptop recently that works with V4

[Chris]

Hello Taiidan,

‐‐‐ Original Message ‐‐‐
On Thursday, 29 November 2018 21:01, taii...@gmx.com  wrote:

> IMO buy a W520 and install a quad core ivy bridge CPU - 32GB RAM and you
> can use open source and open cpu/ram hw init coreboot[1] firmware and
> also me cleaner to nerf the ME. (disabling ME is impossible)
>
> It is easy to find components to refurb it yourself with a new
> battery/keyboard/palmrest/lid etc for not much money.
>

Thanks for this. I will have a look.

Regards,

Chris

-
Chris Willard
ch...@meliser.co.uk

Sent with ProtonMail Secure Email.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7nJj_uJWk-3lIQZaA-y66RWtPVQVFX607iZJPy7rYyVxmzrPCyFFATFUjkM8vWVIP-B6tnY69frfUsvblewSw_Vr--ijAuz5s3dxxY-I5ig%3D%40meliser.co.uk.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: The state of the HiDPI display support in Qubes

[Ivan Mitev]

On 11/30/18 3:47 PM, Jonathan Proulx wrote:

Edit ~/.Xresources and add

Xft.dpi: 200

(or whatever your dpi is) then restart VM.  I've several Linux HoDPI
systems and this is most general fix I've found.


Except that it won't work if gnome settings daemon is running.



Only been Qubesing for a couple days but works there on my X1.

Should be able to put this in /etc/X11/Xresources in template (where it's
set to 96) but for some reason that doesn't seemnto do it for me & I've not
looked for why that is yet...


Yes ; how to do that is described in the doc I've linked to.

Achim's main gripes are that there's no easy config and that everything 
is static.






On Fri, Nov 30, 2018, 4:23 AM Achim Patzner 
Am Donnerstag, den 29.11.2018, 09:16 +0200 schrieb Ivan Mitev:

The following might help to work around your issues:



https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dpi-scaling.md

It is solving a few of the issues but you definitely need more (like
HiDPI themes in several sizes). Or moving new Xresources into templates
(or VMs) if they change in dom0. And dealing with xsettingsd.

Especially xsettingsd -- it would be an ideal point of attack if Qubes
had a dedicated UI (or UX in techno hipster speak) team. Just give it
another database backend for its settings that was maintained in dom0
and accessible to all running VMs and you could easily change settings
in everything running on your system.


Granted, having a "scale everything by a factor X" option in dom0
would be way better


It is necessary unless you like using a microscope for HVMs. In a few
months we will see the first 12" mobile computers running at mobile
phone resolutions...


but it'd be nearly impossible to implement/support if the
config has to be passed down to the VMs.


Not at all. The currently implemented mechanisms for the virtual X
servers are not working perfectly yet but that could be changed. It
just won't solve the problem of xsettingsd messing everything up
(including Xft settings which are coming from Xresources and
.xresources) if it does not have the correct parameters in its
database. So all we have to take care of was getting the databases in
all VMs right -- or implement a central one. If one was mad enough he
could use the qubesdb which is already accessible everywhere.


I'm wondering if it couldn't be solved at a lower level

[...]

That could also end up being very CPU intensive.


You should let the GPU handle that; applying transformations is a
standard feature today.


Achim


--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/7e1f199f6cb9b469d37858c293b7e374a0bd791f.camel%40noses.com
.
For more options, visit https://groups.google.com/d/optout.





--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a9b0aea0-1a29-aa56-8a7b-ef268e0ee8c5%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: The state of the HiDPI display support in Qubes

[Achim Patzner]

Am Donnerstag, den 29.11.2018, 09:16 +0200 schrieb Ivan Mitev:
> The following might help to work around your issues:
> 
> https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dpi-scaling.md

It is solving a few of the issues but you definitely need more (like
HiDPI themes in several sizes). Or moving new Xresources into templates
(or VMs) if they change in dom0. And dealing with xsettingsd.

Especially xsettingsd -- it would be an ideal point of attack if Qubes
had a dedicated UI (or UX in techno hipster speak) team. Just give it
another database backend for its settings that was maintained in dom0
and accessible to all running VMs and you could easily change settings
in everything running on your system.

> Granted, having a "scale everything by a factor X" option in dom0
> would be way better

It is necessary unless you like using a microscope for HVMs. In a few
months we will see the first 12" mobile computers running at mobile
phone resolutions...

> but it'd be nearly impossible to implement/support if the 
> config has to be passed down to the VMs.

Not at all. The currently implemented mechanisms for the virtual X
servers are not working perfectly yet but that could be changed. It
just won't solve the problem of xsettingsd messing everything up
(including Xft settings which are coming from Xresources and
.xresources) if it does not have the correct parameters in its
database. So all we have to take care of was getting the databases in
all VMs right -- or implement a central one. If one was mad enough he
could use the qubesdb which is already accessible everywhere.

> I'm wondering if it couldn't be solved at a lower level
[...]
> That could also end up being very CPU intensive.

You should let the GPU handle that; applying transformations is a
standard feature today.


Achim


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7e1f199f6cb9b469d37858c293b7e374a0bd791f.camel%40noses.com.
For more options, visit https://groups.google.com/d/optout.