On 20190913 at 22:03 +0200 Marek Marczykowski-Górecki wrote:
> On Fri, Sep 13, 2019 at 06:08:39PM +0200, Achim Patzner wrote:
> > Hi!
> >
> > Is the setup script for builder.conf in qubes-builder still maintained?
> > If so, adding fc30
>
> In fact, setup s
Hi!
Is the setup script for builder.conf in qubes-builder still maintained?
If so, adding fc30 and getting rid of the forced use of the MIT PGP key
server might be necessary. If not: Can it be extended to tell users not
to use it?
Achim
--
You received this message because you are subscribed
Hi!
As I've had three spontaneous reboots (at least it's what it is looking
like to me) during the last three nights I really would like to get a
guideline for collecting all usable evidence for submitting a bug
report that might be usable for whoever wants to deal with it. The web
site is not
On 20190114 at 22:28 -0600 Andrew David Wong wrote:
We're getting to a point that is bringing up quite painful memories of
decades past...
> In case anyone reading this is not aware, the documentation is a
> community effort, and everyone is welcome to contribute. (That's how
> things like this
Hi!
Would whoever is currently doing the maintenance on the web pages add a
hint for Evolution users that the "legal" method of changing the path
to the external tool doing the PGP work requires modifying
the key "camel-gpg-binary" in org.gnome.evolution-data-server as in
gsettings set
On 20190112 at 15:00 +0200 Ivan Mitev wrote:
> That'd be a good solution IMO (I've suggested the same in a post some
> time ago [1]).
I didn't see that when you posted it. Seems I'm not alone there...
> > I tried using Xpra as intermediate for scaling windows but DISPLAY=x.y
> > qvm-start seems
Hi!
Would it be possible to modify their environment to run them with
smaller virtual screen size and scale their output on the way to their
X window? A lot of things that need to run in a HVM is not necessarily
able to scale very well (or not at all) in HiDPI environments (e. g. a
lot of Windows
Am Freitag, den 28.12.2018, 11:19 +0100 schrieb Marek Marczykowski-
Górecki:
> It's not about getting the device working properly at dom0 level - this
> is already handled by qubes.InputTablet and qubes.InputMouse. The issue
> is about getting all the extra info (besides just x+y and button
On 20181227 at 02:01 +0100 Marek Marczykowski-Górecki wrote:
> I'm not entirely sure if generic support such devices in GUI protocol
> is a good idea - it will get more and more complex. But also I'm not
> saying I'd refuse nice design+patches for it ;)
Maybe you should just permit sys-usb to
On 20181223 at 02:48 +0100 Marek Marczykowski-Górecki wrote:
> Can you point at the documentation of encryption scheme used by
> Time Machine backups?
You use an encrypted volume. It would probably be nicer if you could
use APFS with its multiply encrypted files but we're not there yet:
Hi!
After reorganizing my working environment (e. g. putting certain
security-related services in separate machines) I would like to start
them at system startup but the current autostart feature is waiting or
all machines to come up. Would it be possible to add another class of
deferred
Am Freitag, den 09.11.2018, 06:35 -0800 schrieb ser...@da.matta.nom.br:
> Em quinta-feira, 8 de novembro de 2018 23:42:10 UTC-2, Achim Patzner
> escreveu:
> > Xresources (or .xsettingss) I'll end up with problems if I connect a
> > different display to my machine. Getting rid o
Hi!
I've come back to using Qubes on a HiDPI device again and getting into
the same trap as always; even if I set the real resolution using
Xresources (or .xsettingss) I'll end up with problems if I connect a
different display to my machine. Getting rid of xsettingsd seems to be
the wrong way,
Am Donnerstag, den 08.11.2018, 11:38 +0100 schrieb eh...@posteo.net:
> This windows-gaming passthrough thread isn't isolated to the Qubes
> mailing list, other OS projects have seen the same manipulative
> argumentation.
Which was the reason for my (admittedly annoyed) reaction; even more
Am Mittwoch, den 07.11.2018, 13:17 -0800 schrieb John Mitchell:
> > TL;DR: Yes, but from a security point of view it's not a good idea.
>
> I sense the qubes team isn't really interested and I would be better off
> using Debian for my primary OS.
> I've had this vision since the 90's of booting
Am Montag, den 05.11.2018, 20:29 -0600 schrieb Andrew David Wong:
> Until now, the two members of the QST have been Joanna and Marek. With
> Joanna's new role at the Golem Project, she will no longer have time to
> function as a QST member. Therefore, Joanna will officially transfer
> ownership of
Am 17.04.2017 um 06:01 schrieb Chris Laprise:
> On 04/16/2017 08:29 PM, 'David Shleifman' via qubes-devel wrote:
>> - keep the original name; give user an ability to trigger
>> resolution of all names associated with a given VM Firewall.
> A more usable variation of that may be to detect
Hi!
I've asked this question before (but cannot find the answer anymore):
1) Is there a way to specify that more than three kernel versions are
kept using qubes-dom0-update?
2) Could this be made configurable?
3) Could this be separated from the number of domU kernels being kept?
Reason:
Hi!
As I don't see a good solution for HVMs on HiDPI devices in the near
future it might be a good idea to think about the necessary additions to
the current setup to enable the optional generation of a sys-VNC domain
that should serve as endpoint for internal VNC consoles provided by Xen.
This
19 matches
Mail list logo
