Bug#964849: Re: 回复:Bug#964849: "Invalid data found when processing input" got when using ffmpeg

2020-07-11 Thread wglxy

Thanks for your suggest. I got the reason which another software was installed 
with another ffmpeg, and set PATH point to it. Now I solved it. Thank you again!


Best regards,
Gulfstream



> -原始邮件-
> 发件人: "Jonas Smedegaard" 
> 发送时间: 2020-07-11 15:11:54 (星期六)
> 收件人: 964...@bugs.debian.org, "王钢林" 
> 抄送: 
> 主题: Re: 回复:Bug#964849: "Invalid data found when processing input" got when 
> using ffmpeg
> 
> Quoting 王钢林 (2020-07-11 09:01:33)
> > I am glad to receive your reply.  But the ffmpeg was installed from debian
> > source by apt-get without any other ffmpeg version was installed. 
> 
> Please provide the output of each of these commands:
> 
> echo $PATH
> 
> which ffmpeg
> 
> ffmpeg
> 
> 
> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private


Bug#954203: Re: Bug#954203: Client splash and exit after login in

2020-03-24 Thread wglxy

Thanks for your reply! My next question is How to connect the xrdp server using 
remmina client? I don't find where to set the glyph cache. And When will the 
bug be resolve?


Thank again!


Best regards,
Gulfstream



> -原始邮件-
> 发件人: "Bernhard Übelacker" 
> 发送时间: 2020-03-21 19:07:38 (星期六)
> 收件人: 954...@bugs.debian.org, gulfstream 
> 抄送: 
> 主题: Re: Bug#954203: Client splash and exit after login in
> 
> Hello,
> this seems to be caused by xrdp using glyph cache even
> when the client does not advertise it.
> Additionally freerdp does now stricter checks.
> 
> Upstream bugs are here [1].
> 
> A workaround could be to use xfreerdp like this:
> 
> xfreerdp +glyph-cache /relax-order-checks /v:hostname
> 
> Kind regards,
> Bernhard
> 
> 
> [1]
> https://github.com/neutrinolabs/xrdp/issues/1266
> 
> https://gitlab.com/Remmina/Remmina/issues/1770
> 
> https://github.com/FreeRDP/FreeRDP/issues/5072
> https://github.com/FreeRDP/FreeRDP/issues/5207


Bug#952506: Re: Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when reboot

2020-02-26 Thread wglxy



> -原始邮件-
> 发件人: "Ritesh Raj Sarraf" 
> 发送时间: 2020-02-27 01:56:04 (星期四)
> 收件人: wg...@china.com, 952...@bugs.debian.org
> 抄送: 925...@bugs.debian.org
> 主题: Re: Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name 
> maybe changed when reboot
> 
> Control: serverity -1 important
> 
> 
> I am lowering the severity as this is common reflection of problems
> elsewhere disguising as a problem with laptop-mode-tools.
> 
> 
> Couple of things to mention:
> 
> * If you know of the persistent name for your interface, can you
> populate that into the /etc/laptop-mode/conf.d/ethernet.conf and see if
> that helps



I think it is not useful because that the first name of wired interface is 
eth0, and systemd change it to enpXXX soon. So laptop may set the interface by 
eth0 or enpXXX.





> 
> * From the logs that you've shared on the bug report, I'm lost. That
> log is huge. laptop-mode-tools will apply power savings to ethernet
> device. On boot, this happens quite early on. And probably that is
> causing the problem. But I'd still like to see what holds the device so
> long that NetworkManager fails to rename it. Does disabling the
> `ethernet` module in laptop-mode-tools solve your problem ? If so, as a
> workaround you can start with disabling it. And then try to investigate
> what may be causing the device to remain busy for so long.
> 
> * There's a valid bug report #925944, where a side-effect of enabling
> power savings on the ethernet device results in NetworkManager not
> considering the device. I am not sure how that should be solved because
> how other tools (like NetworkManager, avahi etc) behave is beyond the
> scope. But, if the integration of these tools do not work proper,
> disabling one of the tools (like laptop-mode-tools) or a particular
> hardware power savings (like ethernet module), could be a viable
> option.
> 
> 
> Coming up with an ideal default is challenging and I struggle to find a
> balance. We do have /etc/laptop-mode/conf.d/board-specific/ . It is
> documented in the manpage.
> 
> 
> For the case of #925944, I think we should remove eth0 from the default
> list. Because most devices these days have a unique persistent name and
> it is best left to the user to find out the name and populate it in the
> configuration file. That is what my upload today, 1.73.1-2 does.
> 
> 
> On Wed, 2020-02-26 at 23:32 +0800, wg...@china.com wrote:
> > OK, thank you very much! I will wait for all things are fine again!
> > Thank you again!
> > 
> > 
> > 
> > > -原始邮件-
> > > 发件人: "Michael Biebl" 
> > > 发送时间: 2020-02-26 23:09:22 (星期三)
> > > 收件人: wg...@china.com, 952...@bugs.debian.org, 
> > > laptop-mode-to...@packages.debian.org
> > > 抄送: 
> > > 主题: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe
> > > changed when reboot
> > > 
> > > Control: reassign -1 laptop-mode-tools
> > > Control: retitle -1 lmt breaks network interface renaming
> > > Control: severity -1 serious
> > > 
> > > Am 26.02.20 um 16:01 schrieb wg...@china.com:
> > > > As your recommendation, I removed the laptop-mode-tools, it seems
> > > > that wired interface' name is correct for several boot. But if
> > > > there is no laptop-mode-tools, how I using its function for
> > > > saving power to laptop?
> > > 
> > > Don't use laptop-mode-tools. The kernel does it sufficiently well
> > > on
> > > it's own these days. I'm not actually sure what business
> > > laptop-mode-tools has with your network interfaces.
> > > 
> > > I'm going to reassign this bug report to laptop-mode-tools and
> > > bumping
> > > the severity to RC.
> > > 
> > > Michael
> > > 
> > > 
> > > 
> > > 
> -- 
> Ritesh Raj Sarraf | http://people.debian.org/~rrs
> Debian - The Universal Operating System


Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when reboot

2020-02-26 Thread wglxy
OK, thank you very much! I will wait for all things are fine again! Thank you 
again!



> -原始邮件-
> 发件人: "Michael Biebl" 
> 发送时间: 2020-02-26 23:09:22 (星期三)
> 收件人: wg...@china.com, 952...@bugs.debian.org, 
> laptop-mode-to...@packages.debian.org
> 抄送: 
> 主题: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when 
> reboot
> 
> Control: reassign -1 laptop-mode-tools
> Control: retitle -1 lmt breaks network interface renaming
> Control: severity -1 serious
> 
> Am 26.02.20 um 16:01 schrieb wg...@china.com:
> > As your recommendation, I removed the laptop-mode-tools, it seems that 
> > wired interface' name is correct for several boot. But if there is no 
> > laptop-mode-tools, how I using its function for saving power to laptop?
> 
> Don't use laptop-mode-tools. The kernel does it sufficiently well on
> it's own these days. I'm not actually sure what business
> laptop-mode-tools has with your network interfaces.
> 
> I'm going to reassign this bug report to laptop-mode-tools and bumping
> the severity to RC.
> 
> Michael
> 
> 
> 
> 


Bug#952497: Wired network interface can not be managed by Network-Manager

2020-02-24 Thread wglxy
Hi, I notice that the wired interface's name maybe be changed while rebooting. 
Sometimes the wired interface's name is "enp0s31f6", sometimes it is "eth0". 
The Network Manager can manage the wired interface if wired interface's name is 
"enp0s31f6". The Network Manager can not manage the wired interface if wired 
inteface's name is "eth0".






Best regards,
Gulfstream


Bug#939489: Cannot access secondary GPU - error: [XORG] (EE)

2019-09-07 Thread wglxy
more information:


After I install package xserver-xorg-input-mouse, I got another error message.


If I run optirun, the error message is:






$ optirun glxgears
[  502.952517] [ERROR]Cannot access secondary GPU - error: [XORG] (EE)

[  502.952549] [ERROR]Aborting because fallback start is disabled.







if I run primusrun, the error message is:




$ primusrun glxgears
/usr/bin/primusrun: line 41: warning: command substitution: ignored null byte 
in input
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE)










Best regards,
Gulfstream


Bug#939505: Cannot access secondary GPU - error: [XORG] (EE)

2019-09-07 Thread wglxy
more information:


After I install package xserver-xorg-input-mouse, I got another error message.


If I run optirun, the error message is:






$ optirun glxgears
[  502.952517] [ERROR]Cannot access secondary GPU - error: [XORG] (EE)

[  502.952549] [ERROR]Aborting because fallback start is disabled.







if I run primusrun, the error message is:




$ primusrun glxgears
/usr/bin/primusrun: line 41: warning: command substitution: ignored null byte 
in input
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE)










Best regards,
Gulfstream


Bug#939489: more information

2019-09-05 Thread wglxy
When I run opengl program with optirun or primusrun, the program can not run 
and I got a error message as below:


$ optirun freecad
[  614.056579] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed 
to load module "mouse" (module does not exist, 0)

[  614.056596] [ERROR]Aborting because fallback start is disabled.


$ primusrun freecad
/usr/bin/primusrun: line 41: warning: command substitution: ignored null byte 
in input
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) Failed to load 
module "mouse" (module does not exist, 0)




Best regards,
Gulfstream

Bug#939505: more information

2019-09-05 Thread wglxy
When I run opengl program with optirun or primusrun, the program can not run 
and I got a error message as below:




$ optirun freecad
[  614.056579] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed 
to load module "mouse" (module does not exist, 0)

[  614.056596] [ERROR]Aborting because fallback start is disabled.





$ primusrun freecad
/usr/bin/primusrun: line 41: warning: command substitution: ignored null byte 
in input
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) Failed to load 
module "mouse" (module does not exist, 0)









Best regards,
Gulfstream


Bug#930563: Re: Bug#930563: Can not start freecad

2019-06-16 Thread wglxy
Hello Bernhard,

Thanks for your reply!

I have install the proprietary nvidia drivers and it runs well.

The output of commands which you list as below,

> ldd /usr/bin/freecad
linux-vdso.so.1 (0x7ffe69ae5000)
libhdf5_openmpi.so.103 => /lib/x86_64-linux-gnu/libhdf5_openmpi.so.103 
(0x7f2032967000)
libmpi.so.40 => /lib/x86_64-linux-gnu/libmpi.so.40 (0x7f203285e000)
libmpi_cxx.so.40 => /lib/x86_64-linux-gnu/libmpi_cxx.so.40 
(0x7f203284)
libFreeCADGui.so => /usr/lib/freecad-python2/lib/libFreeCADGui.so 
(0x7f2031a96000)
libFreeCADApp.so => /usr/lib/freecad-python2/lib/libFreeCADApp.so 
(0x7f2031744000)
libFreeCADBase.so => /usr/lib/freecad-python2/lib/libFreeCADBase.so 
(0x7f20315ae000)
libpython2.7.so.1.0 => /lib/x86_64-linux-gnu/libpython2.7.so.1.0 
(0x7f203123f000)
libxerces-c-3.2.so => /lib/x86_64-linux-gnu/libxerces-c-3.2.so 
(0x7f2030e94000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f2030c76000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f2030c71000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2030c6c000)
libzipios.so.0 => /lib/x86_64-linux-gnu/libzipios.so.0 
(0x7f2030a3f000)
libQt5Xml.so.5 => /lib/x86_64-linux-gnu/libQt5Xml.so.5 
(0x7f20309fe000)
libCoin.so.80c => /lib/x86_64-linux-gnu/libCoin.so.80c 
(0x7f2030166000)
libboost_filesystem.so.1.67.0 => 
/lib/x86_64-linux-gnu/libboost_filesystem.so.1.67.0 (0x7f2030148000)
libboost_program_options.so.1.67.0 => 
/lib/x86_64-linux-gnu/libboost_program_options.so.1.67.0 (0x7f20300c1000)
libboost_regex.so.1.67.0 => 
/lib/x86_64-linux-gnu/libboost_regex.so.1.67.0 (0x7f202ffac000)
libboost_system.so.1.67.0 => 
/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f202ffa5000)
libboost_thread.so.1.67.0 => 
/lib/x86_64-linux-gnu/libboost_thread.so.1.67.0 (0x7f202ff77000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f202ff56000)
libboost_chrono.so.1.67.0 => 
/lib/x86_64-linux-gnu/libboost_chrono.so.1.67.0 (0x7f202ff4b000)
libboost_date_time.so.1.67.0 => 
/lib/x86_64-linux-gnu/libboost_date_time.so.1.67.0 (0x7f202ff37000)
libboost_atomic.so.1.67.0 => 
/lib/x86_64-linux-gnu/libboost_atomic.so.1.67.0 (0x7f202ff32000)
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x7f202fc89000)
libQt5OpenGL.so.5 => /lib/x86_64-linux-gnu/libQt5OpenGL.so.5 
(0x7f202fc2d000)
libQt5PrintSupport.so.5 => 
/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5 (0x7f202fbb6000)
libQt5Svg.so.5 => /lib/x86_64-linux-gnu/libQt5Svg.so.5 
(0x7f202fb6)
libQt5Network.so.5 => /lib/x86_64-linux-gnu/libQt5Network.so.5 
(0x7f202f9bf000)
libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 
(0x7f202f368000)
libQt5X11Extras.so.5 => /lib/x86_64-linux-gnu/libQt5X11Extras.so.5 
(0x7f202f361000)
libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 
(0x7f202edd4000)
libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 
(0x7f202e8d9000)
libspnav.so.0 => /lib/libspnav.so.0 (0x7f202e6d5000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x7f202e594000)
libshiboken2-python2.7.x86_64-linux-gnu.so.5.11 => 
/lib/x86_64-linux-gnu/libshiboken2-python2.7.x86_64-linux-gnu.so.5.11 
(0x7f202e568000)
libpyside2-python2.7.x86_64-linux-gnu.so.5.11 => 
/lib/x86_64-linux-gnu/libpyside2-python2.7.x86_64-linux-gnu.so.5.11 
(0x7f202e52e000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f202e3a8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f202e225000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f202e20b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f202e04a000)
libsz.so.2 => /lib/x86_64-linux-gnu/libsz.so.2 (0x7f202de47000)
libopen-rte.so.40 => /lib/x86_64-linux-gnu/libopen-rte.so.40 
(0x7f202dd8f000)
libopen-pal.so.40 => /lib/x86_64-linux-gnu/libopen-pal.so.40 
(0x7f202dce)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f202dcd6000)
libhwloc.so.5 => /lib/x86_64-linux-gnu/libhwloc.so.5 
(0x7f202dc94000)
libevent-2.1.so.6 => /lib/x86_64-linux-gnu/libevent-2.1.so.6 
(0x7f202da3e000)
libevent_pthreads-2.1.so.6 => 
/lib/x86_64-linux-gnu/libevent_pthreads-2.1.so.6 (0x7f202d83b000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f202d82)
libcurl-gnutls.so.4 => /lib/x86_64-linux-gnu/libcurl-gnutls.so.4 
(0x7f202d792000)
libicui18n.so.63 => /lib/x86_64-linux-gnu/libicui18n.so.63 
(0x7f202d4b7000)
libicuuc.so.63 => /lib/x86_64-linux-gnu/libicuuc.so.63 
(0x7f202d2e8000)
libicudata.so.63 => /lib/x86_