Bug#825833: libkms
Well, the fact that it's enabled by default upstream, and that at least one very recent piece of software requires it could weight a bit :) - Mail original - > De: "Julien Cristau"> À: ydir...@free.fr, 825...@bugs.debian.org > Cc: 825833-submit...@bugs.debian.org > Envoyé: Vendredi 15 Juillet 2016 22:33:41 > Objet: Re: Bug#825833: libkms > > On Wed, Jul 6, 2016 at 18:46:32 +0200, ydir...@free.fr wrote: > > > In fact, it looks like libkms was built in the past, but is > > explicitely > > disabled now. There is probably a reason for this, but there is no > > more > > information than that in the changelog, and no README.Debian. > > > > Could we please have more insight about why this decision was made > > ? > > > libkms wasn't used/useful then, I'd need some convincing to re-enable > it. > > Cheers, > Julien >
Bug#830151: xorgs: Do not have a human maintainer/uploader listed
Control: severity -1 normal On Wed, Jul 6, 2016 at 19:02:53 +0200, Tobias Frost wrote: > Package: xorg > Version: 1:7.7+15 > Severity: serious > Justification: Policy 3.3 / 5.6.3 > https://release.debian.org/stretch/rc_policy.txt doesn't list this as release critical. If you want to be listed in xorg's Uploaders, feel free. Cheers, Julien
Processed: Re: Bug#830151: xorgs: Do not have a human maintainer/uploader listed
Processing control commands: > severity -1 normal Bug #830151 [xorg] xorgs: Do not have a human maintainer/uploader listed Severity set to 'normal' from 'serious' -- 830151: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830151 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#825833: libkms
On Wed, Jul 6, 2016 at 18:46:32 +0200, ydir...@free.fr wrote: > In fact, it looks like libkms was built in the past, but is explicitely > disabled now. There is probably a reason for this, but there is no more > information than that in the changelog, and no README.Debian. > > Could we please have more insight about why this decision was made ? > libkms wasn't used/useful then, I'd need some convincing to re-enable it. Cheers, Julien
Re: Release of Mesa 12 for Debian Testing/Unstable
On Tue, Jul 12, 2016 at 00:39:33 +, Dylam De la torre wrote: > Hi, > > > I just wanted to know when the packages of the version of Mesa (12.0.1) will > arrive to the official repositories, i want to test out the new Vulkan driver. > > > Is there a exact release date for Debian? > No, there isn't. Cheers, Julien
Bug#831420: RM: xserver-xorg-input-vmmouse -- RoQA; obsolete and conflicts with kernel
Package: ftp.debian.org Severity: normal This is a driver for the VMware virtual mouse device. We now enable the Linux kernel driver for this device, so Xorg will support it through its generic libinput or evdev driver. Further, the kernel and Xorg vmmouse drivers cannot be used at the same time so the current linux-image packages break this package. Although this package might conceivably be useful on non-Linux kernels, it is currently only built for Linux so I don't think that's a reason to keep it.
Bug#831405: xserver-xorg-video-openchrome: please make the build reproducible
Source: xserver-xorg-video-openchrome Version: 1:0.3.3+git20160310-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi, Whilst working on the "reproducible builds" effort [0], we noticed that xserver-xorg-video-openchrome could not be built reproducibly. Patch attached. Please send it upstream if possible. [0] https://wiki.debian.org/ReproducibleBuilds Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/src/Makefile.am 2016-07-15 17:56:15.066700891 +0200 --- b/src/Makefile.am 2016-07-15 18:22:08.362042386 +0200 @@ -113,6 +113,9 @@ if [ -d .svn ]; then \ echo '#define BUILDCOMMENT "(development build, at revision '\ "`svnversion -nc .. | sed -e s/^[^:]*://`"')"' > $@.tmp; \ +elif [ "$$SOURCE_DATE_EPOCH" ]; then \ + printf '#define BUILDCOMMENT "(compiled with SOURCE_DATE_EPOCH: %s)"' $$SOURCE_DATE_EPOCH \ + > $@.tmp; \ else \ date +'#define BUILDCOMMENT "(development build, compiled on %c)"' \ > $@.tmp; \
Bug#827905: Character U+2028 can yield file corruption when edited in xterm
On 2016-07-15 05:02 -0400, Thomas Dickey wrote: > On Thu, Jul 14, 2016 at 07:27:52PM +0200, Sven Joachim wrote: >> On 2016-07-13 18:24 -0700, Vincent Lefevre wrote: >> >> > On 2016-07-13 20:15:49 -0400, Thomas Dickey wrote: >> >> I don't see the behavior which is described, and haven't seen any >> >> suitable justification for marking this as a "grave" issue, rather >> >> than "normal". Keep in mind that this is a rarely used line-break >> >> character. >> > >> > This is not common, but this was sufficient to *silently* corrupt one >> > of my files (what makes things really worse is that the corruption >> > doesn't seem to appear immediately, and one notices it when it may be >> > too late). >> > >> >> What I see on the screen is a box-outline for the nonprintable >> >> character (no space). >> > >> > Could this depend on some library version or on the font? >> >> On the latter. With the default font I see no corruption, but with the >> 9x15 font, for instance. See the attached screenshot. > > 9x15 is an ISO-8859-1 font, and can't show U+2028 Surely it should just replace it with a space then, like for other non-latin characters? Besides, the problem also shows up with terminus-18 which is an ISO-10646 font. Cheers, Sven
Bug#827651: vulkan: FTBFS on mips64el -- relocation truncated to fit: R_MIPS_CALL16
Hi, I have created and attached a patch that adds -mxgot flag for mips64 in layers/CMakeLists.txt. The flag is used only for compilation of core_validation.cpp. With this patch I was able to build vulkan successfully for mips64el. Regards, Dejan--- vulkan-1.0.8.0+dfsg1.orig/layers/CMakeLists.txt +++ vulkan-1.0.8.0+dfsg1/layers/CMakeLists.txt @@ -96,6 +96,12 @@ if (NOT WIN32) set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wpointer-arith") endif() +if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "mips64") +if("${CMAKE_SIZEOF_VOID_P}" EQUAL "8") +set_source_files_properties(core_validation.cpp PROPERTIES COMPILE_FLAGS -mxgot) +endif() +endif() + add_custom_command(OUTPUT vk_dispatch_table_helper.h COMMAND ${PYTHON_CMD} ${PROJECT_SOURCE_DIR}/vk-generate.py ${DisplayServer} dispatch-table-ops layer > vk_dispatch_table_helper.h DEPENDS ${PROJECT_SOURCE_DIR}/vk-generate.py ${PROJECT_SOURCE_DIR}/vulkan.py)
Bug#827905: Character U+2028 can yield file corruption when edited in xterm
On Thu, Jul 14, 2016 at 07:27:52PM +0200, Sven Joachim wrote: > On 2016-07-13 18:24 -0700, Vincent Lefevre wrote: > > > On 2016-07-13 20:15:49 -0400, Thomas Dickey wrote: > >> I don't see the behavior which is described, and haven't seen any > >> suitable justification for marking this as a "grave" issue, rather > >> than "normal". Keep in mind that this is a rarely used line-break > >> character. > > > > This is not common, but this was sufficient to *silently* corrupt one > > of my files (what makes things really worse is that the corruption > > doesn't seem to appear immediately, and one notices it when it may be > > too late). > > > >> What I see on the screen is a box-outline for the nonprintable > >> character (no space). > > > > Could this depend on some library version or on the font? > > On the latter. With the default font I see no corruption, but with the > 9x15 font, for instance. See the attached screenshot. 9x15 is an ISO-8859-1 font, and can't show U+2028 -- Thomas E. Dickeyhttp://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature