Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
El miércoles, 28 de noviembre de 2018 12:17:22 -03 Julien Cristau escribió: > [dropping -devel, adding mesa and kde maintainers instead] ACK. > On 11/27/18 5:42 PM, Steve Langasek wrote: > > On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote: > >> Steve Langasek writes: > >>> Long ago I heard rumors of development work on mesa that would allow it > >>> to > >>> function as a proxy library, so that apps would link against libGL as > >>> needed and the GL implementation would use a hardware-accelerated GLES > >>> driver where possible, falling back to software GL where necessary. > >> > >> This seems unlikely -- I believe GLES and GL have different semantics in > >> a few places which makes implementing GL on GLES inefficient; mostly > >> that GLES is missing stuff that GL applications often use, but I think > >> there are places where GLES is just different, including in how GLSL > >> works. > > > > Perhaps that explains why no one ever actually succeeded in implementing > > it, then? > > > > Thanks for the context. > > > >> I haven't tried, but I would expect that applications could use both GL > >> and GLES APIs at the same time, even to the same window. If this does > >> work with Mesa, then linking Qt against GLES wouldn't restrict > >> applications using free drivers at least? > > > > My recollection is that this becomes a practical problem of applications > > that want to use both Qt and GL being unbuildable due to namespace > > collisions at build time. > > Do you know if there have been attempts at resolving those collisions > upstream (either Qt or mesa / khronos)? > > I seem to remember a couple of bug reports against mesa on the Debian > side but am curious about any escalations. The only thing I remember that sounds like this is: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798408> "[arm] libgles2-mesa-dev and libglew-dev disagree over GLsizeiptr" But maybe it was something else :-/ -- Ud. está viendo a la persona que ven nuestros clientes. Leyenda pegada en el espejo de una empresa. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#900352: Reassigning
reassign 900316 xorg-server forcemerge 900352 900316 thanks Merging with 900352, where the bug currently is.
Bug#893433: libegl1-mesa-dev: File conflicts with libwayland-dev:amd64 1.14.91-1
Package: libegl1-mesa-dev Version: 18.0.0~rc4-1 Severity: serious Justification: File conflicts Hi! While trying to build qtwayland I ran across: dpkg: error processing archive /tmp/apt-dpkg-install-VBKAMl/062-libegl1-mesa-dev_18.0.0~rc4-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/pkgconfig/wayland-egl.pc', which is also in package libwayland-dev:amd64 1.14.91-1 Admitedly I'm using a build against experimental using aspcud as dep resolver, as I need to build Qt in experimental, so maybe this is related. Thanks, Lisandro. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'buildd-unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libegl1-mesa-dev depends on: ii libdrm-dev2.4.91-1 ii libglvnd-dev 1.0.0-2 pn libwayland-dev ii libwayland-egl1-mesa 17.3.6-1 ii libx11-dev2:1.6.4-3 ii libx11-xcb-dev2:1.6.4-3 ii libxcb-dri2-0-dev 1.13-1 ii libxcb-dri3-dev 1.13-1 ii libxcb-glx0-dev 1.13-1 ii libxcb-present-dev1.13-1 ii libxcb-sync-dev 1.13-1 ii libxdamage-dev1:1.1.4-3 ii libxext-dev 2:1.3.3-1+b2 ii libxfixes-dev 1:5.0.3-1 ii libxshmfence-dev 1.2-1+b2 ii libxxf86vm-dev1:1.1.4-1+b2 ii x11proto-dri2-dev 2.8-2 ii x11proto-gl-dev 1.4.17-1 libegl1-mesa-dev recommends no packages. libegl1-mesa-dev suggests no packages.
Re: Bug#832452: twinkle: Crashes during call when switching desktop
reassign 832452 libgl1-mesa-dri thanks On sábado, 30 de julio de 2016 2:43:22 A. M. ART Peter Colberg wrote: > Dear Qt Maintainers, > > The jessie backport of twinkle has been found to abort with a > segmentation fault in the DRI driver under certain circumstances. > > Since the segfault has been produced with both the nouveau and the > i965 driver, and since noone has reported a similar issue with twinkle > in stretch, it is likely triggered by the version of Qt5 in jessie. > > Please refer to the bug log for a stack trace of twinkle. Hi Peter! Looking at the not complete backtraces (the i965_dri one misses the i965_dri 's debugging symbols and there is not a complete nouveau backtrace) it really seems a bug on those two drivers, not in Qt itself. Googling a little it seems that the [bug] is in libgl1-mesa-dri, at least for the intel case. There might be a separate issue with nouveau. [bug] <https://bugs.freedesktop.org/show_bug.cgi?id=86281> I'm so reassigning this one to libgl1-mesa-dri and CCing Debian's X strike force. Kinds regards, Lisandro. -- "With great power comes great responsibility." Peter Parker's uncle. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#827939: Please consider marking mesa-utils as Multi-Arch: allowed
On viernes, 24 de junio de 2016 11:08:32 A. M. ART Julien Cristau wrote: > On Thu, Jun 23, 2016 at 10:11:45 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > Question: if a user has a video card wich is OpenGL2 or more capable but > > does not has libgl1-mesa-dri installed: does glxinfo informs "OpenGL > > version string:" with value 2 or more? > > They could be using a non-mesa driver. OK, now I'm beggining to understand how this works. Depending on each video card implementation it might require an associated -dri package. Also glxutils will output the current OpenGL version supported depending wether the video card supports it and the required software is installed. If this is the case then this bug is indeed still valid, and now a more important as before, as we can warn users wether they video card with their current setup does supports OepnGL2+ or not. Of course, if I missinterpreted something then please do not hasitate in remarking it :) Thanks in advance, Lisandro. -- 16: De quien es Internet * De DIOS dado que todas las cosas del mundo le pertenecen Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#827939: Please consider marking mesa-utils as Multi-Arch: allowed
On viernes, 24 de junio de 2016 10:56:42 A. M. ART Michel Dänzer wrote: > On 23.06.2016 22:11, Lisandro Damián Nicanor Pérez Meyer wrote: > > Question: if a user has a video card wich is OpenGL2 or more capable but > > does not has libgl1-mesa-dri installed: does glxinfo informs "OpenGL > > version string:" with value 2 or more? > > It shouldn't, because without libgl1-mesa-dri it should fall back to GLX > indirect rendering, which only supports up to OpenGL 1.4. Now this alone makes filing this bug worthwhile. Thanks a lot! We clearly need to suggest libgl1-mesa-dri then. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#827939: Please consider marking mesa-utils as Multi-Arch: allowed
On jueves, 23 de junio de 2016 11:18:45 P. M. ART Julien Cristau wrote: > On Wed, Jun 22, 2016 at 21:50:35 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > Package: mesa-utils > > Version: 8.3.0-1 > > Severity: wishlist > > > > tl;dr: make mesa-utils M-A: allowed in order to be able to depend on it as > > mesa-utils:any > > > > Hi! libqt5gui5 now ships a script in order to detect wether users have an > > OpenGL2 compatible video card. It case they don't it sets up an > > environment > > variable to let Qt now that it should use rasterization instead. > > > > The script uses mesa-utils' glxinfo package for this. > > Why do that in a script instead of in qt directly? That seems like a > pretty weird implementation choice... That's a good question and yes, it would have been better if it would be checked directly. The fact is that upstream does really not support using Qt with OpenGL less than 2. But Fedora packagers asked for an exception with a patch that checks for an env variable, and as upstream knows that we distros sometimes need to support this kind of setups and they accepted it. Considering the low amount of users with such a setup I don't think it's worth to work on a patch. -- My favourite poem is the one that starts 'Thirty days hath September' because it actually tells you something. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#827939: Please consider marking mesa-utils as Multi-Arch: allowed
Question: if a user has a video card wich is OpenGL2 or more capable but does not has libgl1-mesa-dri installed: does glxinfo informs "OpenGL version string:" with value 2 or more? This is a very important thing: if this is true then we should maybe recommend libgl1-mesa-dri in libqt5gui5, as Qt heavily relies on OpenGL. Thanks in advance! -- Lo que me sorprende de las mujeres es que se arrancan los pelos desde la raíz con cera caliente y aún así le temen a las arañas. Jerry Seinfeld lis: comentario sobre tu frase yo soy mujer, yo me arranco los pelos y VOS le tenes miedo a las arañas María Luján Pérez Meyer (mi hermana) Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#827939: Please consider marking mesa-utils as Multi-Arch: allowed
Hi Michel! On jueves, 23 de junio de 2016 10:02:30 A. M. ART Michel Dänzer wrote: [snip] > > If mesa-utils gets marked as M-A: allowed then we can make libqt5gui5 > > depend upon mesa-utils:any, ie, any arch' version of mesa-utils will > > satisfy the dependency. > > One problem with that is: If libqt5gui5 and mesa-utils aren't the same > architecture, what glxinfo reports doesn't necessarily apply to > libqt5gui5. For example: glxinfo from mesa-utils:amd64 reports that > OpenGL 2 hardware acceleration is working, because libgl1-mesa-dri:amd64 > is installed. However, OpenGL 2 hardware acceleration still doesn't work > for libqt5gui5:i386, because libgl1-mesa-dri:i386 isn't installed. Good catch. libqt5gui5 depends upon libgl1-mesa-glx but not -dri. I guess that most users will get it through recommends, but this probably makes the whole excercise futile. Except you happen to have another idea I would say this bug can be closed. Thanks *a lot* for your quick reply. -- perezmeyer: Gus no tiene inet :-( PabloOdorico: oh perezmeyer: te mando una copia de lo que hagamos esta noche PabloOdorico: de ultima mandame un loro del parque con una flash en la pata ;) Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#827939: Please consider marking mesa-utils as Multi-Arch: allowed
Package: mesa-utils Version: 8.3.0-1 Severity: wishlist tl;dr: make mesa-utils M-A: allowed in order to be able to depend on it as mesa-utils:any Hi! libqt5gui5 now ships a script in order to detect wether users have an OpenGL2 compatible video card. It case they don't it sets up an environment variable to let Qt now that it should use rasterization instead. The script uses mesa-utils' glxinfo package for this. Problem arises that libqt5gui5 is M-A: same, but ends up depending on mesa-utils:. If mesa-utils gets marked as M-A: allowed then we can make libqt5gui5 depend upon mesa-utils:any, ie, any arch' version of mesa-utils will satisfy the dependency. I would highly appreciate if you can at least reply if you are OK or not with the idea, as we currently have a broken M-A libqt5gui5 and would like to take the necessary steps to solve this. Thanks a lot in advance, Lisandro. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages mesa-utils depends on: ii libc6 2.22-12 ii libgl1-mesa-glx [libgl1] 11.2.2-1 ii libglew1.13 1.13.0-2 ii libglu1-mesa [libglu1]9.0.0-2.1 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 mesa-utils recommends no packages. mesa-utils suggests no packages. -- no debconf information
Bug#798408: Bug#825354: mudlet: FTBFS on armel/armhf: glu development package not found
On Tuesday 07 June 2016 10:42:21 Craig Small wrote: > On Sun, Jun 5, 2016 at 8:23 AM Lisandro Damián Nicanor Pérez < > > perezme...@gmail.com> wrote: > > First of all things from the Qt side. Qt5 relies heavily on Desktop OpenGL > > *xor* GLES. Take only one of them. > > So what happens to packages that need Qt and OpenGL on the arm > architectures? To the best of our experience the problem happens only with Qt+GLU, not OpenGL itself. [snip] > Reading #798408 seems to justify removing mudlet from arm. I'm afraid so, yes. -- Cuando tenga duda, utilice la solución mas simple. Principio de William Occam, también llamado "la navaja de Occam" Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#798408: Bug#825354: mudlet: FTBFS on armel/armhf: glu development package not found
On Saturday 04 June 2016 21:45:05 Craig Small wrote: > However there is a libglu1-mesa-dev package for armel. So why isn't it used > so its the same across the architectures? > > The two options for this but are: > * shrug about qt5base-dev not depending libglu1-mesa-dev and include it > explicitly; or > * not have mudlet in armel because the glu support is really not there Hi everyone! Allow me to explain what's happening on the Qt side. It might probably happen that things changes since I last checked out this stuff, so if you have any tip I'll happy to read it. This is realted to #798408, so CCing it. First of all things from the Qt side. Qt5 relies heavily on Desktop OpenGL *xor* GLES. Take only one of them. On archs != arm* users normally have the choice to have a Desktop OpenGL video card. In those cases the card's OpenGL acceleration will be used. For those who don't have hardware acceleration software emulation will be used. Of course, this is *slw*. Now on arm* there is almost none (if any) hardware Desktop OpenGL support, but most of the boards with hardware acceleration use GLES. So we checked with ARM maintainers and decided to switch Qt5's builds to use GLES in those archs, so people with the appropriate hardware would be able to use it. In other words: instead of confining arm* users to software emulation we give them the choice to have hardware acceleration (for those who have the proper hardware, of course). The problem came with GLU: we didn't knew that there was no GLES-based GLU on those archs when we made the decision, so things ported from Qt4 to Qt5 started to FTBFS. As the problems appeared later (ie, not when we uploaded Qt5 to the archive) and the decision was already made we decided that the real fix would be to have a proper GLES-based GLU implementation. It is worth to note that the amount of packages with this issue is not too big (read below). We actually missed to switch arm64 where GLES support is definitely the way to go, so we will be probably filing new bugs at some point in the future (#799113). Timo Jyrinki did the switch in Ubuntu already and could only find a handfull of problematic packages. Of course if at some point we have a GLES-based GLU implementation in the archive this will easily be fixed. For the moment and as far as I know, we don't have such a thing. Hope this clears things up :) Kinds regards, Lisandro. -- Lo que me sorprende de las mujeres es que se arrancan los pelos desde la raíz con cera caliente y aún así le temen a las arañas. Jerry Seinfeld lis: comentario sobre tu frase yo soy mujer, yo me arranco los pelos y VOS le tenes miedo a las arañas María Luján Pérez Meyer (mi hermana) Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#798408: Bug#797816: openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h
I'm tempted to remove libqt5gui5 from the list of packages that hold this bug. It is not a bug at all from our side, arm* uses GLES (except arm64 for now) and GLU is not ported to it. If at some point glu gets ported to GLES and the bug still exists then we might have a bug. -- 1: Una computadora sirve: * Para tratar de dominar el mundo, un caso conocido de esto fue el de Skinet Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Not a VLC bug but a radeon one.
reassign 807604 xserver-xorg-video-radeon thanks The bug was not in VLC itself, so I'm reassign it. X maintainers: the bug is the radeon driver crashing when VLC is pointed to a specific stream, present in the original bug report. Please do not heasitate to ask for more details as you see suitable. I'll ad more info in a couple of minutes. [ 1976.421686] [drm:cypress_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed [ 1986.592063] radeon :01:00.0: ring 5 stalled for more than 1msec [ 1986.592079] radeon :01:00.0: GPU lockup (current fence id 0x0002 last fence id 0x0008 on ring 5) [ 1987.092053] radeon :01:00.0: ring 0 stalled for more than 10124msec [ 1987.092069] radeon :01:00.0: GPU lockup (current fence id 0x0003173b last fence id 0x00031744 on ring 0) [ 1987.092080] radeon :01:00.0: ring 5 stalled for more than 10500msec [ 1987.092086] radeon :01:00.0: GPU lockup (current fence id 0x0002 last fence id 0x0008 on ring 5) [ 1987.380171] [drm:rv770_stop_dpm [radeon]] *ERROR* Could not force DPM to low. [ 1987.387114] radeon :01:00.0: couldn't schedule ib [ 1987.387114] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD (-22)! [ 1987.389279] radeon :01:00.0: Saved 311 dwords of commands on ring 0. [ 1987.389294] radeon :01:00.0: GPU softreset: 0x0088 [ 1987.389297] radeon :01:00.0: GRBM_STATUS = 0xA0003828 [ 1987.389299] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 1987.389302] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 1987.389304] radeon :01:00.0: SRBM_STATUS = 0x20084AC0 [ 1987.389307] radeon :01:00.0: SRBM_STATUS2 = 0x [ 1987.389309] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 1987.389312] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x0001 [ 1987.389314] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x0002 [ 1987.389317] radeon :01:00.0: R_008680_CP_STAT = 0x80010243 [ 1987.389320] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 1987.406730] radeon :01:00.0: GRBM_SOFT_RESET=0x4001 [ 1987.406784] radeon :01:00.0: SRBM_SOFT_RESET=0x8100 [ 1987.407930] radeon :01:00.0: GRBM_STATUS = 0x3828 [ 1987.407933] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 1987.407935] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 1987.407938] radeon :01:00.0: SRBM_STATUS = 0x200800C0 [ 1987.407940] radeon :01:00.0: SRBM_STATUS2 = 0x [ 1987.407943] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 1987.407945] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [ 1987.407948] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [ 1987.407951] radeon :01:00.0: R_008680_CP_STAT = 0x [ 1987.407953] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 1987.407968] radeon :01:00.0: GPU reset succeeded, trying to resume [ 1987.428909] [drm] PCIE GART of 1024M enabled (table at 0x0025E000). [ 1987.428986] radeon :01:00.0: WB enabled [ 1987.428990] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x8800bb3c9c00 [ 1987.428992] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x8800bb3c9c0c [ 1987.429964] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xc9c1c418 [ 1987.445975] [drm] ring test on 0 succeeded in 1 usecs [ 1987.445981] [drm] ring test on 3 succeeded in 2 usecs [ 1987.641630] [drm] ring test on 5 succeeded in 1 usecs [ 1987.641641] [drm] UVD initialized successfully. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Bug#807604: Not a VLC bug but a radeon one.
On Wednesday 16 December 2015 21:04:02 Lisandro Damián Nicanor Pérez Meyer wrote: [snip] > I'll ad more info in a couple of minutes. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Nov 17 2010 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Oct 27 20:43 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] [1002:68f9] /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 4.2.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-8) ) #1 SMP Debian 4.2.6-3 (2015-12-06) Xorg X server log files on system: -- -rw-r--r-- 1 root root 19031 Jul 24 19:37 /var/log/Xorg.3.log -rw-r--r-- 1 root root 19030 Jul 24 19:37 /var/log/Xorg.2.log -rw-r--r-- 1 root root 416334 Aug 20 18:45 /var/log/Xorg.1.log -rw-r--r-- 1 root root 51816 Dec 16 21:05 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [36.048] X.Org X Server 1.17.3 Release Date: 2015-10-26 [36.048] X Protocol Version 11, Revision 0 [36.048] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [36.048] Current Operating System: Linux luna 4.2.0-1-amd64 #1 SMP Debian 4.2.6-3 (2015-12-06) x86_64 [36.048] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-1-amd64 root=UUID=78cb5efd-5ed7-4d61-9beb-6cb55e9d0e53 ro drm.edid_strict=0 quiet [36.048] Build Date: 27 October 2015 11:41:02PM [36.048] xorg-server 2:1.17.3-2 (http://www.debian.org/support) [36.048] Current version of pixman: 0.33.4 [36.048]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [36.048] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [36.049] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Dec 16 20:59:49 2015 [36.265] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [36.592] (==) No Layout section. Using the first Screen section. [36.592] (==) No screen section available. Using defaults. [36.592] (**) |-->Screen "Default Screen Section" (0) [36.592] (**) | |-->Monitor "" [36.706] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [36.706] (==) Automatically adding devices [36.706] (==) Automatically enabling devices [36.706] (==) Automatically adding GPU devices [36.957] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [36.957]Entry deleted from font path. [37.299] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [37.299] (==) ModulePath set to "/usr/lib/xorg/modules" [37.299] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [37.299] (II) Loader magic: 0x55ff8791bde0 [37.299] (II) Module ABI versions: [37.299]X.Org ANSI C Emulation: 0.4 [37.299]X.Org Video Driver: 19.0 [37.299]X.Org XInput driver : 21.0 [37.299]X.Org Server Extension : 9.0 [37.303] (EE) systemd-logind: failed to get session: PID 1017 does not belong to any known session [37.304] (II) xfree86: Adding drm device (/dev/dri/card0) [37.307] (--) PCI:*(0:1:0:0) 1002:68f9:1682:3030 rev 0, Mem @ 0xd000/268435456, 0xfdcc/131072, I/O @ 0xde00/256, BIOS @ 0x/131072 [37.353] (II) LoadModule: "glx" [37.505] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [38.341] (II) Module glx: vendor="X.Org Foundation" [38.342]compiled for 1.17.3, module version = 1.0.0 [38.342]ABI class: X.Org Server Extension, version 9.0 [38.342] (==) AIGLX enabled [38.342] (==) Matched ati as autoconfigured driver 0 [38.342] (==) Matched ati as autoconfigured driver 1 [38.342] (==) Matched modesetting as autoconfigured driver 2 [38.342] (==) Matched fbdev as autoconfigured driver 3 [38.342] (==) Matched vesa as autoconfigured driver 4 [38.342]
Bug#798408: Bug#797816: openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h
On Monday 14 September 2015 10:06:54 chrysn wrote: [snip] > On Wed, Sep 02, 2015 at 04:31:03PM -0300, Tiago Stürmer Daitx wrote: > > openscad 2015.03-1+dfsg-2ubuntu1 FTBFS on armhf due to conflicting > > headers. > > as openscad upstream currently doesn't support gles, this will need > resolution from #798408. if gl and gles are mutually exclusive to that > extent, i'd prefer a solution where it is still possible to build qt > apps that use gl on armhf, for otherwise packages like openscad can't > work at all on that architecture. Qt5 links against GLES in arm*, Desktop GL otherwise. The reason is simple: most arm* boards have native GLES support, thus benefit from using it. As far as I remember GLEW does not supports GLES, so you basically can't use it on arm* with Qt5. Hope that helps, Lisandro. -- My favourite poem is the one that starts 'Thirty days hath September' because it actually tells you something. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#798408: Bug#797816: openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h
On Tuesday 15 September 2015 19:39:26 Lisandro Damián Nicanor Pérez Meyer wrote: > On Monday 14 September 2015 10:06:54 chrysn wrote: > [snip] > > > On Wed, Sep 02, 2015 at 04:31:03PM -0300, Tiago Stürmer Daitx wrote: > > > openscad 2015.03-1+dfsg-2ubuntu1 FTBFS on armhf due to conflicting > > > headers. > > > > as openscad upstream currently doesn't support gles, this will need > > resolution from #798408. if gl and gles are mutually exclusive to that > > extent, i'd prefer a solution where it is still possible to build qt > > apps that use gl on armhf, for otherwise packages like openscad can't > > work at all on that architecture. > > Qt5 links against GLES in arm*, Desktop GL otherwise. The reason is simple: > most arm* boards have native GLES support, thus benefit from using it. > > As far as I remember GLEW does not supports GLES, so you basically can't use > it on arm* with Qt5. > > Hope that helps, Lisandro. Make that armel armhf, somehow we missed arm64. We might change that though. -- ¿Qué vamos a hacer esta noche Cerebro? -Lo mismo que todas las noches Pinky... ¡¡¡tratar de conquistar el mundo!!! Pinky y Cerebro. Narf. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#757174: Please provide a backport for wheezy
Source: libxkbcommon Version: 0.4.1-2 Severity: wishlist Hi! I don't know if it's technically feasible, but a backport for Wheezy would help to backport Qt5 without using embedded libs. Thanks for considering it, Lisandro. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806001204.20172.18457.report...@luna.lisandropm.com.ar
GL/gl.h, Qt5 and arm: FTBFS
Hi! I'm trying to find a solution for the FTBFS of qantenna on arm* [0][1] that fits the best to everyone. This issue seems to be very similar to a older thread including both GL/gl.h and cogl/cogl.h fails on armel and armhf [2], but I failed to see how that was resolved. The FTBFSs are due to conflicting declarations for GLdouble, GLsizeiptr and GLintptr. Basically the problem might boild down to the fact that Qt5 is built using es2 instead of the desktop opengl which, to the best of my knowledge, it's standard OpenGL 2.0. These are the possible solutions I think could be taken: a) Switch Qt5 to use desktop OpenGL on arm*. I have tested this on harris.d.o and works OK. As a pro, it means that other apps will not have porting issues like this. As a con, it might mean that all the OpenGL stuff will be done by software though, am I correct? b) (supossing it's possible) provide es2 versions of mesa-common-dev, libglu1- mesa-dev et al. and build against that on arm* d) (also supossing it's possible) do not consider the FTBFS not RC (or allow it's transition even if it's RC) until a better fix could be done. Please note that I did not include porting the app because, as I understand it, there is no es2-enabled GLU available, or at least on Debian. I'm inclined for option a, but maybe you can provide alternative solutions. As a fallback (if it's possible at all) I would take option d, but that might be needed for other apps in the no-so-distant future, when we will start to see massive porting from Qt4 to Qt5. Kinds regards, Lisandro. [0] https://buildd.debian.org/status/fetch.php?pkg=qantennaarch=armelver=0.3.0-1stamp=1394341348 [1] https://buildd.debian.org/status/fetch.php?pkg=qantennaarch=armhfver=0.3.0-1stamp=1394341126 [2] https://lists.debian.org/debian-arm/2011/12/msg00134.html -- Bebe a bordo (pero con moderación) Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: GL/gl.h, Qt5 and arm: FTBFS
Thank you all for your fast replies! -- You don’t marry someone you can live with – you marry the person who you cannot live without. Anonymous Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Reassign
reassign 686157 xserver-xorg-video-intel thanks Hi Debian X team! This bug has been reported to us and then upstream in [0]. Then upstream concluded that it must be a bug in the intel driver [1], and so I'm reassigning it. [0] https://bugs.kde.org/show_bug.cgi?id=307348 [1] https://bugs.kde.org/show_bug.cgi?id=307348#c6 Please do not heasitate in asking us more info if needed. Kinds regards, Lisandro. -- I am two fools, I know, for loving, and for saying so. John Donne Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Bug#660940: usbfs error causes kdm to not load on startup or reboot
On Sat 25 Aug 2012 04:19:50 Julien Cristau escribió: On Fri, Aug 24, 2012 at 15:31:12 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: [snip] Hi debian-x people! I was looking trough our RC bugs and stumbled upon this one. It is not clear to me if this is or not a bug in kdm or xserver-xorg. Anyway, for solving this RC bug for Wheezy, we can: - Add the hack in kdm. Ugly and punishes other users with a 1 second delay, but it still can work. - Add the aforementioned commit to xserver-xorg and reassign this bug. - Any other ideas? This bug was fixed in wheezy ages ago. Thank you very much Julien! I'm so closing this RC bug :-) -- 20:57 * m4rgin4l patento el proceso de invencion 20:57 m4rgin4l de aqui en mas cualquier inventor me tiene que pagar regalias por inventar algo 20:57 * m4rgin4l tiene la patente pendiente del metodo cientifico Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Bug#660940: usbfs error causes kdm to not load on startup or reboot
On Wed 04 Jul 2012 16:34:18 Julien Cristau escribió: On Tue, Jul 3, 2012 at 17:42:22 +0200, Pino Toscano wrote: Hi debian-x people, Alle giovedì 23 febbraio 2012, david mckisick ha scritto: Update to this. The issue is related to - xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/441653 For now I have inserted a sleep 1 just before the kdm start line. This (bug #660940) would seem a xserver-xorg issue, fixed with upstream commit 88c4622b594a1725d0cee86bc82ad640d241c520 (part of 1.10.99.901 and onward). Would you be able to confirm that could be indeed the case, or anyway provide hints about the issue? The EINTR from VT_WAITACTIVE indeed should go away with this commit. It's still not clear to me why it happened in the first place, but I guess if the system is busy on cold startup things being slower than usual might trigger it. Hi debian-x people! I was looking trough our RC bugs and stumbled upon this one. It is not clear to me if this is or not a bug in kdm or xserver-xorg. Anyway, for solving this RC bug for Wheezy, we can: - Add the hack in kdm. Ugly and punishes other users with a 1 second delay, but it still can work. - Add the aforementioned commit to xserver-xorg and reassign this bug. - Any other ideas? Kinds regards, Lisandro. -- 6 - ¿Cuál es el botón del mouse que permite acceder a las acciones más comunes de archivos? a- El derecho b- El izquierdo c- El central ... ¿PORQUÉ no puedo ver la cara de un usuario de Macintosh?, ¿EH? Guillermo Marraco http://mx.grulic.org.ar/lurker/message/20080307.112156.460149a2.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Bug#677291: KWin crashes when gwenview enters full-screen mode
On Mié 13 Jun 2012 15:05:19 Julien Cristau escribió: On Wed, Jun 13, 2012 at 12:01:45 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: Hi Debian X maintainers! It might have been a good idea to actually send your mail to the people you're talking to. Otherwise all they (we) get is the 'processed' mail from the BTS. Indeed, my mistake. Sorry and thanks for noticing it :) -- firmaware: soft cuya licencia pagas enviando un autografo StucKman en #grulic, irc.freenode.net Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
