Re: [Spice-devel] Identifying and removing potentially divisive language

2020-07-01 Thread Julien Rope
I agree with the approach.
I actually ran the same "grep" command after the talk and was happy to find
there should not be too much work involved to do it :-)


Side note : I've always thought SVN's "trunk" was nice as it fits with the
idea of "branches" growing out of it. But there is a discussion going on at
Gitlab [1] that shows "main" is probably better.


[1] https://gitlab.com/gitlab-org/gitlab/-/issues/221164





Le mer. 1 juil. 2020 à 16:15, Victor Toso  a écrit :

> Hi,
>
> On Wed, Jul 01, 2020 at 10:03:10AM +0200, Kevin Pouget wrote:
> > Hello SPICE community,
> >
> > following Chris Wright (Red Hat CTO) blog post on "Making open
> > source more inclusive by eradicating problematic language" [1],
> > I would like to suggest that we have a look at SPICE source
> > code to find out if/where such language is used and how to
> > remove it.
> >
> > To illustrate the motivations of this move, consider the phrase
> > "the final solution". I am quite sure you would agree that
> > these words cannot be used inside a project. You would agree
> > because the WWII events are still in minds and not so ancient
> > yet.  Git "master", or the "master/slave" pattern may not
> > trigger similar thoughts if your ancestors didn't suffer
> > slavery; "whitelist/blacklist" neither, if the color of your
> > skin doesn't get you into trouble (white=allow, black=deny).
> > Overall, I would advise, when thinking about these questions,
> > not to forget on which side your history/country/skin
> > color/sexual orientation sits you. If it's the oppressor side,
> > you're not at the right place to say it's not relevant.
> >
> > ---
> >
> > I had a quick `grep` look at SPICE code base, searching for
> > `blacklist/whitelist/slave` and I could only find very few
> > occurrences of these words, which is nice. Can you find other
> > problem words?
> >
> > `master` is used for git default's branch, but not much
> > elsewhere. Let's discuss if we could get rid of this one, for
> > instance changing it to `main` (just a suggestion). I don't
> > think that it can break that many things (only the CI comes to
> > my mind, where the `master` branch may be treated differently)
> > as git name default branch's name is often omitted in the usual
> > workflows.
> >
> > Please share your thoughts about this
>
> Not a native english speaker but I've read a few discussions
> around the user of master as git as in master copy instead of
> master/slave. Another examples of the use of master from native
> speakers included master as in school teacher or someone that is
> in charge of something (the offense being where the subject of
> control is the slave).
>
> Still, I don't really mind to changing it to main, even more if
> there are people that feel this can really be offensive in some
> way..
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>


-- 

Julien ROPÉ

Senior Software Engineer - SPICE

jr...@redhat.com

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel


Re: [Spice-devel] Identifying and removing potentially divisive language

2020-07-02 Thread Julien Rope
Well... Your examples are contradicting: the "master/slave" relation used
in electronics or psychology are re-using the slavery concepts too... This
doesn't make it right :-)
Now I'm not working in electronics or psychology, so I'm not going to try
and change their wording.

Regarding changing it now rather than waiting: Daniel is mentioning two
hints - git, or github. As our code is hosted in gitlab, I would add that
one too :)
The idea being that if they choose a new word, it will become the new
default, and we could align with them for consistency, rather than arguing
among us and picking a potentially different name

This doesn't prevent us from changing words that are in our code (like
blacklist/whitelist?). I think there's not a lot of them.

Regards,
Julien


Le jeu. 2 juil. 2020 à 16:09, Frediano Ziglio  a écrit :

>
> > On Wed, Jul 01, 2020 at 04:15:07PM +0200, Victor Toso wrote:
> > > Hi,
> > >
> > > On Wed, Jul 01, 2020 at 10:03:10AM +0200, Kevin Pouget wrote:
> > > > Hello SPICE community,
> > > >
> > > > following Chris Wright (Red Hat CTO) blog post on "Making open
> > > > source more inclusive by eradicating problematic language" [1],
> > > > I would like to suggest that we have a look at SPICE source
> > > > code to find out if/where such language is used and how to
> > > > remove it.
> > > >
> > > > To illustrate the motivations of this move, consider the phrase
> > > > "the final solution". I am quite sure you would agree that
> > > > these words cannot be used inside a project. You would agree
> > > > because the WWII events are still in minds and not so ancient
> > > > yet.  Git "master", or the "master/slave" pattern may not
> > > > trigger similar thoughts if your ancestors didn't suffer
> > > > slavery; "whitelist/blacklist" neither, if the color of your
> > > > skin doesn't get you into trouble (white=allow, black=deny).
> > > > Overall, I would advise, when thinking about these questions,
> > > > not to forget on which side your history/country/skin
> > > > color/sexual orientation sits you. If it's the oppressor side,
> > > > you're not at the right place to say it's not relevant.
> > > >
> > > > ---
> > > >
> > > > I had a quick `grep` look at SPICE code base, searching for
> > > > `blacklist/whitelist/slave` and I could only find very few
> > > > occurrences of these words, which is nice. Can you find other
> > > > problem words?
> > > >
> > > > `master` is used for git default's branch, but not much
> > > > elsewhere. Let's discuss if we could get rid of this one, for
> > > > instance changing it to `main` (just a suggestion). I don't
> > > > think that it can break that many things (only the CI comes to
> > > > my mind, where the `master` branch may be treated differently)
> > > > as git name default branch's name is often omitted in the usual
> > > > workflows.
> > > >
> > > > Please share your thoughts about this
> > >
> > > Not a native english speaker but I've read a few discussions
> > > around the user of master as git as in master copy instead of
> > > master/slave. Another examples of the use of master from native
> > > speakers included master as in school teacher or someone that is
> > > in charge of something (the offense being where the subject of
> > > control is the slave).
> > >
> > > Still, I don't really mind to changing it to main, even more if
> > > there are people that feel this can really be offensive in some
> > > way..
> >
> > I think the primary downside in changing the branch name is if we
> > end up with different branch names chosen by each project. There is
> > value in the fact that essentially every project uses the same
> > branch name for their latest development branch, as it gives end
> > users consistent expectations.
> >
> > I'm in favour of changing the branch name, but my inclination is
> > to wait and see a little longer, in order to identify what the
> > new defacto standard ends up being. "main" is a good bet as a new
> > standard, but it would be nice to see it "in action".
> >
> > I'd be looking for two possible signs
> >
> > Whether the Git maintainers themselves decide to standardize
> > on a new term.
> >
> > What GitHub actually decide upon & roll out.
> >
> > Either of those two decisions will set a defacto standard across a
> > vast number of projects, and thus it will be beneficial to have
> > alignment with those decisisons.
> >
> > Regards,
> > Daniel
>
> Hi,
>I have different feeling about these changes. On one side I agree with
> Michal that these changes appears positive but they are potentially
> aggravating the real issue just hiding the problem.
> About the words I think "master" have multiple meaning, removing blindly
> because some meaning could remember some bad memories looks excessive.
> And even if this word is used in the "master&slave" reference hinting
> human slavery there are on the other side many uses (like master&slave
> relationship in electronic circuit or master&slave used in communication
> or in 

[Spice-devel] ANNOUNCE spice-vdagent 0.21.0 release

2021-01-14 Thread Julien Rope
Hi all,

spice-vdagent 0.21.0 is now available.

In case of bugs or requests, please file them at our issue
tracker:

  https://gitlab.freedesktop.org/groups/spice/-/issues

Release:
   https://www.spice-space.org/download/releases/spice-vdagent-0.21.0.tar.bz2
   
https://www.spice-space.org/download/releases/spice-vdagent-0.21.0.tar.bz2.sha256sum
   
https://www.spice-space.org/download/releases/spice-vdagent-0.21.0.tar.bz2.sig

And also:

https://gitlab.freedesktop.org/spice/linux/vd_agent/-/tags/spice-vdagent-0.21.0

These releases are signed with GPG key:

 3D01 51CD 86CB 514B A776  7EDA 72A9 CCB6 7FDA B9AF

Major changes in 0.20.0
===

* Security fixes:  CVE-2020-25650, CVE-2020-25651, CVE-2020-25652,
CVE-2020-25653* Fix shutdown issue due to incompatible thread/fork
uses with GLib* Fix mouse pointer issues under Wayland* Fix a crash
when running without dbus (e.g: within containers)* !9  - Introduce
optional GTK4 support for monitor management* !13 - Enable copying
files from client using webdav* Bump spice-protocol dependency to
v0.14.3

Best regards,

Julien
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel


Re: [Spice-devel] Multiple monitors at 4K, in virt-manager?

2021-03-23 Thread Julien Rope
> I still am offered only 2952 x 1781 in the guest. With those settings
except 'heads="2"', it is exactly
> the same--that resolution, and only one display, "Virtual-0".
>
> As mentioned in my original message, when I use the Virtio instead of the
QXL device, I do get 4K,
> though again choosing 'heads="2"' doesn't give me an additional display
in the guest. (Curiously
> the one display I get is "Virtual-1" rather than "Virtual-0".) With this
device there's no option for
> changing the video memory in the XML.

The numbering (Virtual-0 vs Virtual-1) is expected - this is not an issue.

Do you actually get the choice of additional displays in virt-viewer (not
in the guest) ?
Under the top menu "View -> Displays" you should have a list of available
displays. Do you see them ? Are they enabled or grayed out ?

Best regards,
Julien


Le mar. 23 mars 2021 à 08:24, Dr. Jennifer Nussbaum  a
écrit :

> On Monday, March 22, 2021, 01:35:46 PM EDT, Uri Lublin 
> wrote:
>
> >  Hi,
> >
> >  It seems 64MB is not enough.
> >
> >  4096 * 2160 * 4 * 2 > 64MB
> >
> >  Can you try replacing all those 64MB below with 128MB ?
> >  Please try with 1 head first. Possibly 2 heads need
> >  more (but not for all params).
>
> I'm afraid there's no change.
>
> With the settings
>
> 
>heads="1" primary="yes"/>
>function="0x0"/>
>  
>
> I still am offered only 2952 x 1781 in the guest. With those settings
> except 'heads="2"', it is exactly
> the same--that resolution, and only one display, "Virtual-0".
>
> As mentioned in my original message, when I use the Virtio instead of the
> QXL device, I do get 4K,
> though again choosing 'heads="2"' doesn't give me an additional display in
> the guest. (Curiously
> the one display I get is "Virtual-1" rather than "Virtual-0".) With this
> device there's no option for
> changing the video memory in the XML.
>
> Thank you for sticking with this.
>
> Jen
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>


-- 

Julien ROPÉ

Senior Software Engineer - SPICE

jr...@redhat.com

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel