Bug#825833: libkms

[ydirson]

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

[Julien Cristau]

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

[Debian Bug Tracking System]

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

[Julien Cristau]

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

[Julien Cristau]

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

[Ben Hutchings]

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

[Chris Lamb]

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

[Sven Joachim]

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

[Dejan Latinovic]

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

[Thomas Dickey]

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. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature