Bug#681051: xpra: menus pop up off-screen
> When you use a custom resolution or multiple screens a nearest larger > resolution is used in Xdummy resulting in menus still showing > off-screen. The rest of this bug should now be filed against Xorg/dummy driver as there is nothing left to do in Xpra itself. 1) the dummy driver should handle adding new resolutions on the fly via Randr 2) Xorg should allow us to add new dummy screens on the fly so we could ensure that the virtual display layout matches the client's precisely The support code for this already exists in recent versions of xpra: we expose not just the total display dimensions but one for each screen, and I have randr code to try to add the resolution to the server then set it. Unfortunately, dummy does not support "full" Randr. In late 2011, I had asked for help on how to provide the patches against Xorg but have not received any answer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681051: xpra: menus pop up off-screen
On 11/07/12 00:21, Michal Suchanek wrote: Excerpts from Antoine Martin's message of Tue Jul 10 17:11:02 +0200 2012: On 10/07/12 21:18, Michal Suchanek wrote: Excerpts from Antoine Martin's message of Tue Jul 10 13:46:34 +0200 2012: On 10/07/12 18:37, Michal Suchanek wrote: Excerpts from Antoine Martin's message of Tue Jul 10 11:29:03 +0200 2012: Please see here: https://www.xpra.org/Xdummy.html This is the only workable fix for this problem. These are packaged in Debian. Why is the bug happening still? Because you are using the default Xvfb and not Xdummy. See the bottom of the page on how to setup xpra to use Xdummy using the "--xvfb=" switch. Then the part of the man page saying xpra start This command starts a new xpra server, including any necessary setup. is misleading at best if not outright wrong. I don't understand what you are saying. It does what it says, it is just that for an optimal setup you should use Xdummy instead of Xvfb. The man page is not the place to start writing a novel about the best way to setup your x11 server (Xdummy vs Xvfb, dbus, various agents and whatnot) Indeed, it is not. However, the SEE ALSO section is meant to provide pointers to more exhaustive documentation. Only the BUGS section mentions Xdummy but no information on how it is used. I've updated it as it was out of date, and added a link to the Xdummy page: https://www.xpra.org/trac/changeset/1082 I guess README.Debian would be suitable place for articles at least. A novel would be somewhat excessive in this case. I don't think there's anything specific to Debian here. This is mostly a dependency and packaging issue though: at present xpra depends on Xvfb. Making Xdummy the default is a long term goal, but until most distributions start packaging recent versions of Xorg (1.12 or later) and of the dummy driver (0.3.5), Xvfb will remain the default. Debian is one of such distribution but still defaults to Xvfb. There is a ticket for providing global xpra defaults in a config file: https://www.xpra.org/trac/ticket/123 Once that is implemented, it should be pretty easy to provide a different config file for each distribution, one which would use Xdummy if available (and include the xorg.conf for it too) Feel free to provide this better wording you speak of. Looking at Debian Xsession man page, the wiki, and the Xvfb defaults from the xpra man page you could possibly start a somewhat workable X session with xpra --xvfb="Xorg -nolisten tcp -noreset +extension GLX +extension RANDR +extension RENDER -logfile ./10.log -config ./xorg.conf" --start-child="/etc/X11/Xsession true" start :10 Note the -noreset option which is omitted on the wiki and without which the session setup will not work. I've added "-noreset" and a note on that: https://www.xpra.org/trac/changeset/1081 (although it's not strictly required, it's much better to have it, thanks) Note also that the true command exits immediately so any dbus, ssh-agent, and similar daemons started by the session will exit immediately as well. You could run a non-ending process instead but then the session daemons would stay even after the X server exits. A client that connects to the X server and waits for it to terminate would be ideal but I know of none that does just this. Odd, because it would be trivial to write. Perhaps some sample script in documentation, or perhaps even a xorg.conf.dummy and a script in /usr/bin using it could be installed with xpra so that everyone does not have to figure out how the hell is that thing supposed to work. A sample script using xorg.conf.dummy could look like this: xpra --xvfb="Xorg -nolisten tcp -config xorg.conf.dummy -noreset +extension GLX +extension RANDR +extension RENDER -logfile ~/.xpra/xserver-$DISPLAY.log" --start-child="/etc/X11/Xsession true" start :$DISPLAY It is sad that you can't know what display xpra picks when starting it but without actually patching xpra you can't do more than that. I think the config file option above is the easiest way to improve things quickly? Cheers Antoine Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681051: xpra: menus pop up off-screen
Perhaps some sample script in documentation, or perhaps even a xorg.conf.dummy and a script in /usr/bin using it could be installed with xpra so that everyone does not have to figure out how the hell is that thing supposed to work. A sample script using xorg.conf.dummy could look like this: xpra --xvfb="Xorg -nolisten tcp -config xorg.conf.dummy -noreset +extension GLX +extension RANDR +extension RENDER -logfile ~/.xpra/xserver-$DISPLAY.log" --start-child="/etc/X11/Xsession true" start :$DISPLAY It is sad that you can't know what display xpra picks when starting it but without actually patching xpra you can't do more than that. I think the config file option above is the easiest way to improve things quickly? It requires that the xorg.conf linked on the wiki is installed at /etc/X11/xorg.conf.dummy Otherwise full path to the file is required. Sure, I was thinking of putting it in: /etc/xpra/xorg.conf.dummy Next to xpra's config. Saves potential clashes with Xorg paths/packages and keeps it more self-contained. But your suggested location also works. Are there any guidelines on things like this? Cheers Antoine Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680244: xpra: consider adding bug fixes from the upstream stable branch 0.3.x before release?
On 07/19/2012 05:36 PM, أحمد المحمودي wrote: On Thu, Jul 19, 2012 at 01:03:45PM +0300, Timo Juhani Lindfors wrote: I see you uploaded 0.3.3 to unstable. I have been using it for a week now without problems. Thanks! ---end quoted text--- Please do. FYI: there is one patch in there which will be partially reverted for 0.3.4 as it breaks compatibility with MS Windows clients. The fix is in trunk and will be applied to 0.3.x branch soon-ish. Antoine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681051: xpra: menus pop up off-screen
Please see here: https://www.xpra.org/Xdummy.html This is the only workable fix for this problem. Cheers Antoine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681051: xpra: menus pop up off-screen
On 10/07/12 18:37, Michal Suchanek wrote: Excerpts from Antoine Martin's message of Tue Jul 10 11:29:03 +0200 2012: Please see here: https://www.xpra.org/Xdummy.html This is the only workable fix for this problem. These are packaged in Debian. Why is the bug happening still? Because you are using the default Xvfb and not Xdummy. See the bottom of the page on how to setup xpra to use Xdummy using the "--xvfb=" switch. Cheers Antoine Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681051: xpra: menus pop up off-screen
On 10/07/12 21:18, Michal Suchanek wrote: Excerpts from Antoine Martin's message of Tue Jul 10 13:46:34 +0200 2012: On 10/07/12 18:37, Michal Suchanek wrote: Excerpts from Antoine Martin's message of Tue Jul 10 11:29:03 +0200 2012: Please see here: https://www.xpra.org/Xdummy.html This is the only workable fix for this problem. These are packaged in Debian. Why is the bug happening still? Because you are using the default Xvfb and not Xdummy. See the bottom of the page on how to setup xpra to use Xdummy using the "--xvfb=" switch. Then the part of the man page saying xpra start This command starts a new xpra server, including any necessary setup. is misleading at best if not outright wrong. I don't understand what you are saying. It does what it says, it is just that for an optimal setup you should use Xdummy instead of Xvfb. The man page is not the place to start writing a novel about the best way to setup your x11 server (Xdummy vs Xvfb, dbus, various agents and whatnot) This is mostly a dependency and packaging issue though: at present xpra depends on Xvfb. Making Xdummy the default is a long term goal, but until most distributions start packaging recent versions of Xorg (1.12 or later) and of the dummy driver (0.3.5), Xvfb will remain the default. Feel free to provide this better wording you speak of. Cheers Antoine Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683133: xpra: robustify cython version parsing: otherwise would fail to build against beta releases of cython
(snip) ValueError: invalid literal for int() with base 10: 'beta1' You did not post the version string that Debian uses (the one that contains 'beta1') so the patch I have merged was only tested against the following version strings: * 0.16.0 * 0.16.0.beta1 * 0.16.beta1 * 0.16.0beta1 etc Please let me know if this works for you and I'll apply it to the stable 0.3.x (which is what debian uses) and 0.4.x branches. https://www.xpra.org/trac/changeset/1204 Cheers Antoine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683133: robust cython version comparisons Was: [Python-apps-team] Bug#683133: xpra: robustify ...
(snip)
$> python -c 'from distutils.version import LooseVersion as LV; print LV("0.17") <
LV("0.17.beta1")'
True
it is ignorant about suffixes like .beta (thus above result) but is robust
enough in general and should work for your case I guess with min 0.14 version.
I've re-done the change using LooseVersion:
https://www.xpra.org/trac/changeset/1205
The diff against the previous code (instead of what I had merged since)
is here:
https://www.xpra.org/trac/changeset?old_path=%2Ftrunk%2Fsrc%2Fsetup.py&old=1203&new_path=%2Ftrunk%2Fsrc%2Fsetup.py&new=1205
Let me know if this works/looks ok to you and I'll apply to the stable
0.3.x and 0.4.x branches.
Thanks
Antoine
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681051: xpra: menus pop up off-screen
On 07/13/2012 08:43 PM, Michal Suchanek wrote: Excerpts from Antoine Martin's message of Thu Jul 12 16:00:48 +0200 2012: Perhaps some sample script in documentation, or perhaps even a xorg.conf.dummy and a script in /usr/bin using it could be installed with xpra so that everyone does not have to figure out how the hell is that thing supposed to work. A sample script using xorg.conf.dummy could look like this: xpra --xvfb="Xorg -nolisten tcp -config xorg.conf.dummy -noreset +extension GLX +extension RANDR +extension RENDER -logfile ~/.xpra/xserver-$DISPLAY.log" --start-child="/etc/X11/Xsession true" start :$DISPLAY It is sad that you can't know what display xpra picks when starting it but without actually patching xpra you can't do more than that. I think the config file option above is the easiest way to improve things quickly? It requires that the xorg.conf linked on the wiki is installed at /etc/X11/xorg.conf.dummy Otherwise full path to the file is required. Sure, I was thinking of putting it in: /etc/xpra/xorg.conf.dummy Next to xpra's config. Saves potential clashes with Xorg paths/packages and keeps it more self-contained. But your suggested location also works. Are there any guidelines on things like this? I guess it would be better to get the file into xserver-xorg-video-dummy package in this case. Until that happens, current xpra trunk (what will become the 0.5.0 release) now uses a default per-install config file in: /etc/xpra/xpra.conf which can be overriden with a per-user ~/.xpra/xpra.conf or via the command line. It also ships with a: /etx/xpra/xorg.conf Which is the dummy config Xorg needs. Then at build time, one can use: ./setup.py --enable-Xdummy install To make it install the default xpra.conf with Xdummy support. If the "--enable-Xdummy" flag is not specified, it will try to run "Xorg -version" to figure out if support can be enabled (v>=1.12). If that fails (for whatever reason), it will use the standard config file with "Xvfb", as before. The beta packages I have just made depend on Xvfb for distros with old versions of Xorg (squeeze, precise, etc) and build with Xdummy dependencies and config file for the newer ones (wheezy, sid, quantal) https://www.xpra.org/beta/ So, as far as I am concerned (barring any bugs or packaging issues I've missed), this issue is closed. Cheers Antoine Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678409: xpra: mouse position out of sync
On 08/18/2012 06:56 PM, أحمد المحمودي wrote: Hello, On Thu, Jun 21, 2012 at 04:27:48PM +0200, Hramrach wrote: I tried running firefox in xpra, and I could not click most UI elements. Examining closely I found that the mouse pointer is way more to the right (like 50~100px) than what xpra thinks. Minimizing the firefox window and restoring seems to fix the issue. ---end quoted text--- According to http://xpra.org/trac/ticket/158, upstream might have been able to fix your issue, could you try to see if xpra 0.3.6 fixes your problem ? The upstream tarball can be found at: http://winswitch.org/src/xpra-0.3.6.tar.bz2 FYI, You can find the source tarballs here (xpra only - nothing else): https://www.xpra.org/src/ I don't think this bug is fixed either in 0.3.x, 0.4.x or even trunk. But please do give it a try to confirm. Since I am not able to reproduce it and the questions have not been answered, I will probably have to close this bug as 'needinfo'. Cheers Antoine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654924: Fwd: Re: TigerVNC 1.0.90 src debs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Joachim's work is much better than the hacked packages I have put together. Sorry I still haven't been able to use this as a base to provide better/newer versions. The reason is that despite a number of important shortcomings in the packages I have put out, they do what I need them to do... so there isn't much of an incentive for me to spend more time fighting with packaging issues. You probably want to keep the tigervnc list informed so that the newer/better packages can be linked from their homepage instead of mine. Cheers Antoine On 02/22/2012 04:50 AM, Joachim Falk wrote: > Hey Mike, > > fyi, regarding your ITP for tigervnc. I don't think that Antoine > has done anything in this regard. But you might ask or use my > package as basis for yours. I have already applied some fixes from > redhat ontop of the original tigervnc sources. The stuff is all > versioned via git so you can tell what changes I have applied. > > Regards, Joachim > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654924 > > Original-Nachricht Betreff: Re: TigerVNC 1.0.90 > src debs Datum: Sat, 17 Sep 2011 20:10:30 +0700 Von: Antoine Martin > An: Joachim Falk > > Hi, > > Thanks for this, I was meant to do this ages ago and really > dropped the ball on this one. I'll take a look asap. > > Cheers Antoine > > On 09/17/2011 07:40 PM, Joachim Falk wrote: >> Am 23.05.2011 10:19, schrieb Antoine Martin: >>> Hi Joachim, > >>> Joachim Falk wrote: >>>> Dear Antoine, you provide some binary debs >>>> >>>> "http://winswitch.org/dists/squeeze/main/"; >>>> >>>> for debian-squeeze for TigerVNC 1.0.90. However, I seem to >>>> be incapable of finding the corresponding src debs for the >>>> binaries. Could you point me in the correct direction? I >>>> want to tinker a bit with the built options for Xvnc4. > >>> I am afraid that those builds are hacked using bash scripts >>> and are probably wrong. See the recent discussion about how >>> Xvnc should be build against the host headers rather than using >>> the build-xorg script which is in the source. I keep meaning to >>> do things right, but I just don't have the time at present... >> Hi Antoine, > >> it took me some time, but I finally got around to make some debs >> of my own. They should build tigervnc properly. Maybe you can use >> them as basis for some semi official version. > >> http://xiao.jfalk.de/~joachim/tigervnc <= Look here > >> Cheers, Joachim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Esk4ACgkQGK2zHPGK1rufUgCffaUR/uNbb5nOrcvx1jFcScpH 0NoAniLKA96cIlcYdpp1k+pYnJTFlxG3 =icof -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628773: new version fixes keyboard trouble
Hi, Following the off-list discussion, I have now released a new version which seems to fix the non-us keyboard issues. Since this is becoming more like a fork, I have now put in place a domain to host the code, svn repository and info: http://xpra.devloop.org.uk/ There's a bug tracker (trac) and I can grant svn commit access as needed. As for the issue of packaging it for debian, I have done some work to tidy up the code/man page, etc. And I have been making DEBs available for over a year here: http://winswitch.org/downloads/ Let me know if there's anything else that is required. I would gladly hand over the packaging burden to someone else. Also, a number of users will not install the software because it comes from an "untrusted" source, which hinders the project unnecessarily. Cheers Antoine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628773: xpra keyboard layout trouble
On 06/01/2011 04:21 PM, Timo Juhani Lindfors wrote: > Hi, > > [ Antoine, I'm sending a copy of my mails to > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628773 since your > version of xpra does not have bug tracking system. If you wish to reply > there you can just mail 628...@bugs.debian.org and Cc: me.] It will have a bug tracking system by the end of today. (once the source is re-imported properly with full change history) > Antoine Martin writes: >> That's interesting, the solution we were thinking of using involved >> using setxkbmap: >> "setxkbmap -print" on the client (but not in an xpra window) >> then piping this data to "| xkbcomp - $DISPLAY" on the server. > > Like this? (snip) > which is an improvement but still not very usable (I really need the > pipe character). Unless someone can come up with a better scheme, I think we will merge this simple code as it seems to improve things somewhat. What do you think? It seems such a trivial thing to do, I can't believe there isn't a way to make this all work. It will probably take someone with a better understanding of X11 keyval/keymap/xkbcomp to get it done though :( Cheers Antoine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#956959: #956959 can no longer connect after dist-upgrading server
On 24/04/2020 05:45, Dmitry Smirnov wrote: > On Thursday, 23 April 2020 4:53:08 PM AEST Steinar H. Gunderson wrote: >> Were you able to reproduce it on 3.0.8? (Ie., is there any reason to >> believe that 3.0.9 would fix this specific issue?) > > Since I could not reproduce on 3.0.9, I did not try to test 3.0.8. The Solution has been posted here over 3 weeks ago: https://lists.devloop.org.uk/pipermail/shifter-users/2020-April/002555.html > Based on upstream changelog and the correction of another bug (that I've > thought to be related) in 3.0.9 I assumed this problem to be fixed. You should have subscribed to the xpra mailing list to receive announcements like the one above. Then you could have released 3.0.8 with the correct trivial patch, and avoided all these problems in the first place. Antoine signature.asc Description: OpenPGP digital signature
Bug#795877: missing os import
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/08/15 07:34, Dmitry Smirnov wrote: > Hi Jamie, > > On Monday 17 August 2015 16:14:30 Jamie Heilman wrote: >> This is something of a show stopper: > > Sorry about that. This is a reminder to me to never ever upload Xpra without > comprehensive testing due to frequent regressions even in minor bugfix > releases... :( I normally keep quiet. But not this time. Enough is enough about claiming "frequent regressions" from upstream. I've heard it before, and I have provided statistics on those so called "frequent regressions" and where they actually come form vs the need to fix things. So let's get some facts straight. First, some context: everyone can take a long hard look at the 0.14.10 "stable" version found in Debian and decide if "stable" really means what they think it means: http://xpra.org/trac/wiki/Packaging There's a large number of serious issues in 0.14.10, people will hit them despite the fact that those issues are known and have an easy fix upstream. What percentage will bother filing a Debian ticket for those? Probably no more than a low single digit (and that's for the very obvious ones, not the odd crashes), but until they do things don't get fixed at all. This is a fundamentally flawed process and I just don't buy that "this is the Debian" way. I know for fact packages get fixed, not always just reactively. Second, this fix has been committed exactly 2 weeks ago, because *we* do test things and find such issues very quickly: http://xpra.org/trac/changeset/10214 We even document what goes in each branch, and what will go in and when - where you could have found this fix from day one in this branch's commit log: http://xpra.org/trac/wiki/Versions/PendingFixes But if you want to make us look bad because you did not test and did not notice this in *your* package for 2 weeks, fine. At least we're clear on that. Third, AFAIK this bug did not affect anyone using the packages we provide at xpra.org - only the packages provided by Debian. Just like very many of the bugs we encounter. libav anyone? webp versioning? Debian only bugs in sound subsystem? packaging differences? shipping an old version? (see above) questionable patches applied? etc Although we do end up dealing with those as well, despite the pain. >> Trivial to fix though, xpra/client/window_backing_base.py just needs >> to import os. > > Thank you. I'll upload ASAP... > Lastly, please tell me how to unsubscribe from Debian's bug system for xpra, as I cannot find any way of doing this myself from here (it says I am not registered): https://tracker.debian.org/pkg/xpra I no longer wish to read disparaging comments like the one above. I will no longer try to help support the outdated versions found in Debian. Cheers Antoine -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlXSuMwACgkQGK2zHPGK1rsD1QCeP1v6EbFF5LCFSMRLRqnTvRE0 NSsAn1xfIRL0Ie2CMU9n7RlaC24PBckD =zH21 -END PGP SIGNATURE-
Bug#740395: crashes: "TypeError: not all arguments converted during string formatting"
On 01/03/14 06:47, Christoph Egger wrote:
> warn("cannot load webp: " % e)
> TypeError: not all arguments converted during string formatting
This is fixed in trunk:
http://xpra.org/trac/changeset/5641/xpra
And in v0.11.x:
http://xpra.org/trac/changeset/5642/xpra
V0.11.4 should be released later today.
Cheers
Antoine
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#703585: wrong fix?
Correct me if I'm wrong, but the suggested fix in comment 15 looks wrong to me: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703585#15 PyOpenGL already has a loader for numpy, this only slots numpy where "python-numeric" used to go, effectively loading it twice under two names. It avoids the warning, but I don't think that's right. The more fundamental problem is twofold: * it tries to import libraries which are highly unlikely to be found on the system (with "python-numeric" being replaced by "numpy" everywhere) * when it fails to load, it spits out those huge stacktraces that scare users, simply saying "accelerator module XYZ not installed" would be just as correct and far less likely to cause so many false problems -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741023: xpra attach :100 leads to 'segmentation fault'
On 07/03/14 23:59, Dmitry Smirnov wrote: > I'm unable to reproduce this. > > On Fri, 7 Mar 2014 16:16:15 Wenceslao González-Viñas wrote: >> I tried also with versions 0.11.2 and 0.12.0 > 0.12.0 is not in Debian and not even released yet so my guess is that you > might have broken/incompatible Xpra configuration files in "/etc/xpra" or in > "~/.xpra"... That's quite unlikely to lead to a "segfault" which is in the title of this bug, but not in the logs provided. >From the log files that are provided, the poster's error is that there is an X11 server already running on the display he is trying to start. That's what the error message says, almost word for word: "Make sure an X server isn't already running" There might be other problems too, but they are occluded by this one. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741023: xpra attach :100 leads to 'segmentation fault'
On 10/03/14 17:53, Wenceslao González-Viñas wrote: > /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: > could not open display The client application requires access to your local display. You are either trying to run it from a non graphical login, or you have changed the DISPLAY environment variable. (more than likely the latter)
Bug#741023: xpra attach :100 leads to 'segmentation fault'
On 10/03/14 18:34, Wenceslao González-Viñas wrote: > 2014-03-10 12:28:52,699 cannot import csc_opencl (OpenCL colorspace > conversion): /usr/lib/python2.7/dist-packages/pyopencl/_cl.so: symbol > clRetainDevice, version OPENCL_1.2 not defined in file libOpenCL.so.1 with > link time reference This looks suspicious and could be the cause. It looks like the version the opencl module was compiled against is not the same as the version you have installed. You could verify this by (temporarily) deleting xpra's xpra/codecs/csc_opencl directory. If that doesn't do it, please get a gdb backtrace.
Bug#741023: xpra attach :100 leads to 'segmentation fault'
On 11/03/14 07:15, Dmitry Smirnov wrote: > Hi Wenceslao, > > Please avoid using HTML formatting (it doesn't look good in bug report) and > use only plain-text emails. > > On Mon, 10 Mar 2014 14:05:23 Wenceslao González-Viñas wrote: >> It works!!! How can the problem be fixed (not temporarily)? > Please try with "--opengl=no" (it will probably work). No, that's unlikely. OpenGL and OpenCL are totally different things. It looks to me like the opencl package installed is not the one that the module was built against. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708505: xpra: altgr + lessthan does not produce pipe anymore
There was nothing even remotely related to keyboard handling between 0.9.1 and 0.9.2, see: svn diff -r 3326:3379 Xpra/tags/v0.9.x/src So the "fix" is likely to be a side effect of you upgrading/restarting your sessions. Cheers Antoine On 16/05/13 14:08, Timo Juhani Lindfors wrote: > Package: xpra > Version: 0.9.1+dfsg-1 > Severity: normal > > With my finnish keyboard layout I use "Alt Gr" and "<" (lessthan) to > produce "|" (pipe). > > In xpra 0.9.1+dfsg-1 this broke and started producing only "<". > > However, while I started debugging this issue I noticed that xpra > 0.9.2+dfsg-1 again fixes this, thanks a lot for uploading it! > > You can close this bug report right away but I hope it still has some > informational value :) > > -- System Information: > Debian Release: jessie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/6 CPU cores) > Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages xpra depends on: > ii libavcodec53 6:0.8.6-1 > ii libc6 2.17-2 > ii libswscale2 6:0.8.6-1 > ii libvpx1 1.1.0-1 > ii libwebp2 0.1.3-3+nmu1 > ii libx11-6 2:1.5.0-1 > ii libx264-123 2:0.123.2189+git35cf912-1 > ii python2.7.3-5 > ii python-gtk2 2.24.0-3+b1 > ii python-wimpiggy 0.9.2+dfsg-1 > ii x11-xserver-utils 7.7~3 > ii xserver-xorg-input-void 1:1.4.0-1+b1 > ii xserver-xorg-video-dummy 1:0.3.5-2+b1 > > Versions of packages xpra recommends: > ii openssh-client 1:6.2p1-3 > ii python-imaging 1.1.7-4 > ii ssh-askpass 1:1.2.4.1-9 > > Versions of packages xpra suggests: > ii gstreamer0.10-plugins-bad 0.10.23-7.1 > ii gstreamer0.10-plugins-good 0.10.31-3+nmu1 > ii gstreamer0.10-plugins-ugly 0.10.19-2+b2 > pn openssh-server > ii pulseaudio 2.0-6.1 > ii pulseaudio-utils2.0-6.1 > ii python-dbus 1.2.0-1 > ii python-gst0.10 0.10.22-3 > pn python-gtkglext1 > > -- no debconf information > > -- System Information: > Debian Release: jessie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/6 CPU cores) > Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages xpra depends on: > ii libavcodec53 6:0.8.6-1 > ii libc6 2.17-2 > ii libswscale2 6:0.8.6-1 > ii libvpx1 1.1.0-1 > ii libwebp2 0.1.3-3+nmu1 > ii libx11-6 2:1.5.0-1 > ii libx264-123 2:0.123.2189+git35cf912-1 > ii python2.7.3-5 > ii python-gtk2 2.24.0-3+b1 > ii python-wimpiggy 0.9.2+dfsg-1 > ii x11-xserver-utils 7.7~3 > ii xserver-xorg-input-void 1:1.4.0-1+b1 > ii xserver-xorg-video-dummy 1:0.3.5-2+b1 > > Versions of packages xpra recommends: > ii openssh-client 1:6.2p1-3 > ii python-imaging 1.1.7-4 > ii ssh-askpass 1:1.2.4.1-9 > > Versions of packages xpra suggests: > ii gstreamer0.10-plugins-bad 0.10.23-7.1 > ii gstreamer0.10-plugins-good 0.10.31-3+nmu1 > ii gstreamer0.10-plugins-ugly 0.10.19-2+b2 > pn openssh-server > ii pulseaudio 2.0-6.1 > ii pulseaudio-utils2.0-6.1 > ii python-dbus 1.2.0-1 > ii python-gst0.10 0.10.22-3 > pn python-gtkglext1 > > -- no debconf information > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709008: xpra: PDFs appear very tiny in evince under xpra at 100% zoom
> I think I am but how can I be sure? "ps axuf" lists To figure out what xvfb you are using (Xvfb or Xdummy): grep xvfb /etc/xpra/xpra.conf > [ 78392.078] (II) DUMMY(0): Chipset is a DUMMY You are using Xdummy. I think I've seen this bug, can you please file a ticket? (this is an upstream bug, not a debian/packaging bug) Thanks Antoine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#759202: xpra: client under GNOME Shell spins at 100% CPU if --no-tray not used
On 25/08/14 20:24, Dmitry Smirnov wrote: > Hi Simon, > > I'm just wondering if it is a regression? Did you experience this issue on > Xpra 0.13.*? FWIW: the code has not changed at all in this area between 0.13.x and 0.14.x (and maybe even further back, quite easy to diff). That's not to say that the bug is not in xpra, just worth mentioning. We are aware of a problem with the systray with Debian distros running gnome-shell: http://xpra.org/trac/ticket/657 But with absolutely no idea of how to fix it. The system tray implementation in gnome-shell is already so close to unusable that figuring out breakage in such a setup is not going to be a high priority I am afraid. Cheers Antoine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721898: please backport xpra
> Only opengl is reported as > unsupported on the server side (which is a KVM running SID + xpra from > experimental). Server side does not use OpenGL, maybe you are referring to this client side message: ImportError: No Numeric module present: No module named Numeric Note: Debian does not ship python-gnumeric (which is superseded by numpy) which makes PyOpenGL spit out a warning when we load it. AFAIK, silencing this warning would silence other more useful warnings. Perhaps Debian should consider patching PyOpenGL to remove this warning instead - or provide python-numeric packages for backwards compatibility. > I attach the output from gl_check.py. The output looks fine, and OpenGL should have been enabled OK on this system. You can check in your tray menu or in the Session-Info's Statistics window. > This ticket (and the linked mail) seems > related to the missing OpenGL support: http://xpra.org/trac/ticket/330 The ticket you are pointing to has nothing to do with GL... Antoine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721898: [winswitch] Bug#721898: please backport xpra
On 06/09/13 16:54, Dmitry Smirnov wrote: > On Fri, 6 Sep 2013 16:29:08 Antoine Martin wrote: >> Server side does not use OpenGL, maybe you are referring to this client >> side message: >> >> ImportError: No Numeric module present: No module named Numeric >> >> >> Note: Debian does not ship python-gnumeric (which is superseded by >> numpy) which makes PyOpenGL spit out a warning when we load it. >> AFAIK, silencing this warning would silence other more useful warnings. > I wonder if logging is unnecessary verbose by default. For example the > following command > > python -c 'import logging; logging.root.setLevel(logging.DEBUG); import > OpenGL; from OpenGL.GL import GL_VERSION, GL_EXTENSIONS;' > > merely print > > No handlers could be found for logger "OpenGL.acceleratesupport" > > and somehow don't complain about "No module named Numeric"... > That's a different message caused by the fact that the logging system is not configured before use. You need a call to "logging.basicConfig() or similar before importing OpenGL: python -c 'import logging; logging.basicConfig(); logging.root.setLevel(logging.DEBUG); import OpenGL; from OpenGL.GL import GL_VERSION, GL_EXTENSIONS;' Antoine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722974: xpra constantly crashing
On 15/09/13 07:25, Neil Young wrote: > Package: xpra > Version: 0.10.4+dfsg-2 > Severity: important > > I'm finding a lot of trouble running applications on the local system via xpra > (I do this as I want to run those same apps remotely on a Windows workstation) > When running the application through Winswitch, the application will appear on > screen for anywhere from a few seconds to a few minutes and then disappear, > the > application continues to run in the background, the crash can happen at any > time for any or no reason. What is crashed in this case is the xpra client right? Since you stated that the app is still running. Can you re-attach to it afterwards? You could attach gdb to the xpra client to get a backtrace from it. With the limited information available, my best guess is that opengl client rendering is causing the crash. Try turning that off, either from the systray or in your xpra.conf > There are no messages in Winswitch and I don't kn ow where to look for error > information. If I google "winswitch debugging", the first hit is what you want: http://winswitch.org/dev/session-debugging.html > > Please note that I don't have this problem on the remote workstation however > the remote workstation is running Windows.
Bug#723059: xpra: crashes on attach to remote server with active client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > When I try to attach to this running server from my local machine, it > seems to attach, and the client appears briefly, then it crashes with > the following backtrace: > > servo:~ 7$ xpra attach ssh:music@cyrano:100 > xpra client version 0.9.8 > 2013-09-15 15:38:16,909 failed to locate the dbus notification service > 2013-09-15 15:38:18,017 Attached to ssh:music@cyrano:100 (press Control-C to detach) > > [NULL @ 0x7f842c013a40] Value 4686111960511545344.00 for parameter 'b' out of range (...) > /usr/lib/python2.7/dist-packages/xpra/x264/codec.so(do_clean_decoder+0x12)[0x7f843fe28702] > /usr/lib/python2.7/dist-packages/xpra/x264/codec.so(set_decoder_csc_format+0x1a)[0x7f843fe2899a] > /usr/lib/python2.7/dist-packages/xpra/x264/codec.so(+0x70d3)[0x7f843fe1e0d3] OTOH, a few possibilities: * the libav and/or x264 libraries that you have installed are not the same ones that were used for building xpra * the build you have used the wrong libav patches * there is a compatibility problem between xpra and the version of libav you have (I seem to recall this was the case when I tested 0.10.x builds with sid) - so maybe we need yet-another-libav-patch -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI2g6MACgkQGK2zHPGK1ruS1ACfYneaFryn5BWL/ZGaGesHxYoi 7XYAn0Fi9bALSEgC/wM3ddFTD/ElOaY6 =ezrb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723058: xpra: fails to start remote server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I am currently unable to start a remote server: > > servo:~ 0$ xpra start ssh:music@cyrano:100 > 2013-09-15 15:23:36,404 failed to locate the dbus notification service > 2013-09-15 15:23:37,373 Connection lost > 2013-09-15 15:23:37,373 connection closed after 0 packets received (0 bytes) and 1 packets sent (7579 bytes) > servo:~ 0$ Looks like a bug. Assuming this is not a Debian packaging bug (looks unlikely), can you please file a ticket upstream with more details. > > The result of this apparently-successful operation (note the return > code is 0) is no running xpra server on the remote host (cyrano). I > can otherwise connect to the remote server via ssh fine, and once > there I can start a session just fine: Please check the server log file (clearing it before testing). It may also be something to do with your login shell. > I'm unclear where the console messages (such as "failed to locate the > dbus notification service") are coming from (local or remote host?). > In either case, dbus is available on both machines. See the man page. You need a dbus server running for the xpra server to use. Having dbus installed is not sufficient. If you want dbus available in your xpra server, use: dbus-launch xpra start ... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI2g7EACgkQGK2zHPGK1ruG8QCfW2gqCOLsbgJZXau3PIT6K92r hPQAnjunFAzOdhYNFLM+lvScasQRfiCD =kqy5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693481: Bug#713017: Bug#693481: Processed: block 713017 with 693481
Note: upstream python-webm has not received a single update since March 2012, and it is now behind our in-tree copy which now supports lossless compression. I have created an upstream ticket with my patch: https://code.google.com/p/python-webm/issues/detail?id=2 As for the hard-coded library names, this is unfortunate but was needed to make it work on all the platforms we support (I can't remember for sure, but I think "find_library" did not work on OSX for example). We *could* use "find_library" once it has been proven to work everywhere (takes time). Please also note that in the upcoming xpra 0.10 release, the loading of codecs has changed: we now use the __import__ construct to "soft load" these dependencies. Your patches will need to get updated for that. Also, in Debian speak this means "libwebp" should be a "Suggests" or at most a "Recommends" rather than a hard dependency. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693481: find_library() in python-webm
> xpra's webm module does it almost right: > 1) It shouldn't try to open "libwebp.so"; Oops, fixed. > 2) It should treat gnu* (Hurd, kFreeBSD) platforms in the same way as > linux2. > Also done. http://xpra.org/trac/changeset/3709/xpra (will backport to v0.9.x) Thanks! Antoine
Bug#369202: randomly activated 'access keys'
>Now, this is _nothing_ compared to how annoying this is when you are >currently filling in a web form I second that. PITA. This happens on 3.5.2 and 3.5.3. I wished there was a way to turn the whole thing off completely. I do not want access keys at all - EVER! Antoine signature.asc Description: This is a digitally signed message part
