Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Lars Wirzenius]

On Tue, Jul 12, 2016 at 02:45:49PM +0900, Mike Hommey wrote:
> It's just probably that your config didn't have palm detection enabled
> with the synaptics driver. `synclient | grep PalmDetect` would tell you.

I've been using the following script, with variations on the
parameters to find a working setup. The values below are the best I
could manage, and they aren't any good.

#!/bin/sh

synclient \
TapButton1=1 \
TapButton2=2 \
TapButton3=3 \
PalmDetect=1 \
PalmMinWidth=50 \
PalmMinZ=10 \
VertSCrollDelta=-41 \
HorizScrollDelta=-41 \
TouchpadOff=0 \
"$@"


-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: PGP signature

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Lars Wirzenius]

On Tue, Jul 12, 2016 at 03:52:56PM +1000, Russell Stuart wrote:
> Maybe libinput does the typing detection syndaemon does, but I can't
> find any evidence for it.

I remember trying the typing detection some years ago. It didn't help
me much, since the order of events, for me, tend to be that the mouse
events happen first, and typing events only later, so that by the time
the typing prevents the touchpad from working it's already too late,
as the mouse has moved and sometimes clicked. (Which is a recipe for
very confusing IRC dicussions, btw.)

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: PGP signature

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Russell Stuart]

On Tue, 2016-07-12 at 10:07 +0300, Lars Wirzenius wrote:
> I've been using the following script, with variations on the
> parameters to find a working setup. The values below are the best I
> could manage, and they aren't any good.
> 
> #!/bin/sh
> 
> synclient \
>   TapButton1=1 \
>   TapButton2=2 \
>   TapButton3=3 \
>   PalmDetect=1 \
>   PalmMinWidth=50 \
>   PalmMinZ=10 \
>   VertSCrollDelta=-41 \
>   HorizScrollDelta=-41 \
>   TouchpadOff=0 \
> "$@"

For what it's worth, for me on stretch synclient isn't too reliable.
 Eg, "synclient TapButton1=0" has no effect - it should disable one
fingered taps.  The libxinput equivalent (xinput --set-prop) doesn't
work for libxinput either.

The only thing that has proved reliable is putting a file in
/etc/X11/xorg.conf.d/touchpad.conf:

Section "InputClass"
  Identifier"Touchpad twofinger scroll"
  MatchIsTouchpad "yes"
  Driver"synaptics"
  Option"ZAxisMapping"  "4 5"
  Option"HorizTwoFingerScroll"  "true"
  Option"VertTwoFingerScroll"   "true"
  Option"FastTaps"  "on"
  Option"PalmDetect""on"
  Option"AccelFactor"   "0.1028806" #2x
  Option"AdaptiveDeceleration"  "10"
  Option"MinSpeed"  "0.5"
  Option"MaxSpeed"  "4.75"
  Option"TapButton1""1"
  Option"TapButton2""3"
  Option"TapButton3""2"
EndSection

I would happily use libxinput if it extricated me from this mess, but
right now it seems to be bugs all the way down.

signature.asc
Description: This is a digitally signed message part

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Guus Sliepen]

On Mon, Jul 11, 2016 at 04:34:22PM +0200, Raphael Hertzog wrote:

> it has been some time that GNOME 3.20 users have been unable to configure
> their touchpad[1] because:
> 1/ xserver-xorg-input-synaptics cherry-picked an upstream commit[2]
>that gives the priority to the synaptics driver to handle touchpads
> 2/ xserver-xorg-input-synaptics is always installed as a dependency
>of xserver-xorg-input-all
> 3/ gnome-control-center 3.20 uses libinput and no longer support synaptics

I'm using XFCE, and recently when an apt-get upgrade caused the X server
to use libinput instead of the synaptics driver, I had a very difficult
time getting my touchpad configured correctly, in the end causing me to
move back to the synaptics driver. There are several issues with moving
from synaptics to libinput:

1) The defaults are different. Depending on your touchpad, that might
   make things better or worse. This will cause people to be taken by
   surprise and then they will have to figure out how to configure it with
   the new system.

2) Configuring your touchpad in a desktop environment independent way is
   harder with libinput than with synclient. Although far from perfect, the
   synclient tool is much easier to use than either xinput --set-prop or
   editing the Xorg.conf file.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Raphael Hertzog]

On Mon, 11 Jul 2016, Raphael Hertzog wrote:
> > We thought about backporting synaptics support back for Stretch, to give 
> > more
> > time to libinput to mature and to other DEs to add support for it. Not sure 
> > how
> > much work that would be though.
> 
> Ok, let's try to convince upstream then, I filed this:
> https://bugzilla.gnome.org/show_bug.cgi?id=768682

Upstream rejected the request. At the same time, someone pointed
out that KDE supports libinput. Russel Stuart in
<1468280176.5449.20.ca...@stuart.id.au> told us that LXDE supports
libinput as well. I checked the git history of XFCE and also
found indication that libinput was supported.

I don't know about others DE, but I believe that we're sufficiently
covered here with GNOME/KDE/XFCE/LXDE to be able to go ahead with the release of
xserver-xorg-input-all dropping the synaptics/evdev driver.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[殷啟聰]

Hi everyone,

I don't know if this as a feedback from a user helps. If you login GNOME in
Wayland session, the touchpad settings comes back to the control panel. I
have been using GNOME on Wayland for several weeks and nothing is bad.

Probably making Wayland the default GNOME session is the simplest (but
impractical, probably) solution to this?

Cheers,
Kai-Chung Yan

Raphael Hertzog  於 2016年7月12日 星期二寫道：

> On Mon, 11 Jul 2016, Raphael Hertzog wrote:
> > > We thought about backporting synaptics support back for Stretch, to
> give more
> > > time to libinput to mature and to other DEs to add support for it. Not
> sure how
> > > much work that would be though.
> >
> > Ok, let's try to convince upstream then, I filed this:
> > https://bugzilla.gnome.org/show_bug.cgi?id=768682
>
> Upstream rejected the request. At the same time, someone pointed
> out that KDE supports libinput. Russel Stuart in
> <1468280176.5449.20.ca...@stuart.id.au > told us that LXDE
> supports
> libinput as well. I checked the git history of XFCE and also
> found indication that libinput was supported.
>
> I don't know about others DE, but I believe that we're sufficiently
> covered here with GNOME/KDE/XFCE/LXDE to be able to go ahead with the
> release of
> xserver-xorg-input-all dropping the synaptics/evdev driver.
>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: http://www.freexian.com/services/debian-lts.html
> Learn to master Debian: http://debian-handbook.info/get/
>
>

-- 
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Undergraduate student in National Taichung University of Education
* LinkedIn: 
* Blog: 
*/

Bug#830861: ITP: libfastjson -- fast json library for C

[Michael Biebl]

Package: wnpp
Severity: wishlist
Owner: Michael Biebl 

* Package name: libfastjson
  Version : 0.99.3
  Upstream Author : Rainer Gerhards 
* URL : https://github.com/rsyslog/libfastjson
* License : Expat
  Programming Lang: C
  Description : fast json library for C

The libfastjson library is a fork from json-c with a focus on
being small and performant.

Newer version of liblognorm and rsyslog require libfastjson.

Re: Replacing web assets with symlinks to packaged versions

[Thomas Goirand]

On 07/09/2016 07:21 PM, Enrico Zini wrote:
> On Sat, Jul 09, 2016 at 02:06:36PM +0100, Ian Jackson wrote:
> 
>> As I understand it, your problem is that:
>>
>>  * Upstream wants the upstream tarball to contain a copy of bootstrap
>>  * Debian wants the copy of bootstrap removed from the source package
>>  * But none of our source formats can replace files with symlinks ?
>>
>> ?
> 
> It turns out that Debian does not want the copy of bootstrap removed
> from the source package, and that it's ok to just replace them with
> symlinks using dh_link.
> 
> That lowers massively the bar, and my level of despair.

The usual way to do things here, is to delete the files from the tree
before building the package, just to make sure that you're not using it.
But my understanding is that it's otherwise fine to just leave it there,
even though it'd be better to repack it and remove the .min.js files if
you have enough time to spare doing so.

Cheers,

Thomas Goirand (zigo)

Re: Thinking about a "jessie and a half" release

[Jeffrey Walton]

> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
>
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)
>
> all rolled up with a small installer image build (netinst, maybe DVD#1).
>
> A lot of arm64 machine users would benefit from this, and maybe owners
> of very recent amd64 machines too, with better support for things on
> the Skylake platform. Those are the only two architectures I'm
> thinking of supporting at this point.
>
> Is anybody else interested in helping? Thoughts/comments?

I think it would benefit more than Skylake users. The last few
processors are missing support. Below is from a Core i5-5300U (5th
gen) and a 3.19.0-64-generic kernel.

**

$ dmesg | egrep -i '(error|failed)'
...
[35679.953137] mce: [Hardware Error]: Machine check events logged
[35980.749723] mce: [Hardware Error]: Machine check events logged
[36280.594838] mce: [Hardware Error]: Machine check events logged
[36580.439940] mce: [Hardware Error]: Machine check events logged
[37029.202190] mce: [Hardware Error]: Machine check events logged
[37179.118743] mce: [Hardware Error]: Machine check events logged
[37629.831878] mce: [Hardware Error]: Machine check events logged
[37779.748453] mce: [Hardware Error]: Machine check events logged
[38229.510127] mce: [Hardware Error]: Machine check events logged

$ sudo mcelog
mcelog: Family 6 Model 3d CPU: only decoding architectural errors

Bug#830874: ITP: python-osc-lib -- OpenStackClient Library

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-osc-lib
  Version : 0.3.0
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/osc-lib
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStackClient Library

 OpenStackClient (aka OSC) is a command-line client for OpenStack. osc-lib is a
 package of common support modules for writing OSC plugins.

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Simon McVittie]

On Tue, 12 Jul 2016 at 12:52:08 +0200, 殷啟聰 wrote:
> Probably making Wayland the default GNOME session is the simplest (but
> impractical, probably) solution to this?

I think GNOME 3.20 on Wayland still has too many "papercuts" to be
something we can support as a long-term default. I'm using it myself,
and I've been fixing some of them (mainly those that have an impact on
gnome-terminal), but others are more involved and are beyond my ability
to fix.

Many of the remaining issues with Wayland are not things we can
realistically fix downstream, because they need new protocol development
that has to be coordinated with Wayland and/or GNOME upstream developers
(depending whether it's a standardized protocol or something that can
reasonably be GNOME-specific).

GNOME 3.22 will be released before squeeze freezes, and will hopefully do
Wayland better (each GNOME 3 release so far has done Wayland significantly
better than the last). The Fedora developers are aiming to default
to Wayland for their release that uses GNOME 3.22 - but I'm not sure
how much weight to put on that, because they've been hoping to default
to Wayland for several Fedora releases now, and so far they've always
decided closer to their release that it wasn't ready.

If you test GNOME Shell on Wayland, please usertag your bug reports
to appear in

so we can keep track of how numerous and severe the issues are.

S

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Ian Jackson]

Guus Sliepen writes ("Re: synaptics vs libinput and GNOME 3.20 no longer 
supporting synaptics"):
> I'm using XFCE, and recently when an apt-get upgrade caused the X server
> to use libinput instead of the synaptics driver, I had a very difficult
> time getting my touchpad configured correctly, in the end causing me to
> move back to the synaptics driver. There are several issues with moving
> from synaptics to libinput:
> 
> 1) The defaults are different. Depending on your touchpad, that might
>make things better or worse. This will cause people to be taken by
>surprise and then they will have to figure out how to configure it with
>the new system.

At the very least I don't think this change should be made to any
existing systems.

People learn how their touchpad works, and they learn to work around
(or how to configure away) whatever things irritate them personally.

We should not be asking people to redo that on upgrades.  At least if
they reinstall they maybe have the old install as a reference.

Thanks,
Ian.

(who uses a home-modified xserver-xorg-input-mtrack)

preferred form for modification (was: Bug#817092: this browserified)

[Marvin Renich]

[please do not CC me]

* Ian Jackson  [160711 11:17]:
> Marvin Renich writes ("Re: [Pkg-javascript-devel] Bug#817092:  Bug#817092: 
> this browserified"):
> > One fundamental purpose...
> 
> I have no idea why you think this is relevant.

I apologize for not changing to subject to make it clear that I am not
in disagreement with the general discussion about this bug nor am I in
disagreement that the original source used to generate the
"browserified" file (along with the program used to generate it) must be
in Debian.  My point was that I disagreed with the general application
of one specific statement made by Jonas.

Upon re-reading Jonas' statement, it has become clear to me that he was
discussing what Debian is willing to distribute, not what the license
says Debian is allowed to distribute.  Jonas, I apologize for
misconstruing your meaning, and I retract my objection to your statement
in this context.  This distinction is important, and I should have seen
it in that message.

My message was triggered by the phrasing of Jonas' statement that was
very similar to past discussions over the meaning of "preferred form for
modification", especially in the context of the GPL.  In these
discussions it is sometimes asserted that, for purposes of the GPL and
other similar licenses, the phrase must be interpreted in terms of
upstream's preferred form.  However, neither the GPL itself, nor GNU's
published philosophy[1] support this; rather they contradict this
interpretation.  That part of the GPL is entirely about what a recipient
must give to a second level recipient.  Nowhere does the GPL mention
anything about giving changes back to upstream.

...Marvin

[1] https://www.gnu.org/philosophy/free-sw.html

Re: Replacing web assets with symlinks to packaged versions

[Jakub Wilk]

* Thomas Goirand , 2016-07-12, 14:54:
The usual way to do things here, is to delete the files from the tree 
before building the package, just to make sure that you're not using 
it. But my understanding is that it's otherwise fine to just leave it 
there,


ACK

even though it'd be better to repack it and remove the .min.js files if 
you have enough time to spare doing so.


I wouldn't remove .min.js stuff just because I have enough free time.
We should use pristine upstream tarballs whenever we can.

--
Jakub Wilk

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Adam D. Barratt]

On Tue, 2016-07-12 at 16:34 +0100, Simon McVittie wrote:
> GNOME 3.22 will be released before squeeze freezes

That seems a little unlikely. :)

Regards,

Adam

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Adam Borowski]

On Tue, Jul 12, 2016 at 06:39:28PM +0100, Adam D. Barratt wrote:
> On Tue, 2016-07-12 at 16:34 +0100, Simon McVittie wrote:
> > GNOME 3.22 will be released before squeeze freezes
> 
> That seems a little unlikely. :)

Yeah, it was a mistake to name two close releases such similar names.
We should have gone with zurg. :þ

-- 
An imaginary friend squared is a real enemy.

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Dimitri John Ledkov]

On 12 July 2016 at 19:29, Adam Borowski  wrote:
> On Tue, Jul 12, 2016 at 06:39:28PM +0100, Adam D. Barratt wrote:
>> On Tue, 2016-07-12 at 16:34 +0100, Simon McVittie wrote:
>> > GNOME 3.22 will be released before squeeze freezes
>>
>> That seems a little unlikely. :)
>
> Yeah, it was a mistake to name two close releases such similar names.
> We should have gone with zurg. :ş
>

Yeap, zurg is the best. And the next two are close as well: buster & bullseye

-- 
Regards,

Dimitri.

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[Marc Haber]

On Mon, 11 Jul 2016 22:29:20 +0200, Philipp Kern 
wrote:
>On Mon, Jul 11, 2016 at 08:07:20PM +0200, Marc Haber wrote:
>> [1] I remember the day when a Debian stable point release introduced a
>> new version of an ethernet driver that broke an entire class of IBM
>> blade servers' networks and I also remember being scolded for relying
>> on Debian stable instead of doing extensive tests myself
>
>And there is truth to that.

Of course. But, alas, introducing a new driver to a stable kernel is
IMO a violation of the stable principle. But I do understand that
those things are necessary from time to time.

>Compared to other vendors (and even companies)
>Debian does not have an extensive test lab to try to guard ourselves against
>regressions. There is only so much you can do about drivers that people
>who rely on stable in a mission critical environment should do their own
>acceptance testing before deploying changes.

Yes. Unfortunately, in this case, I was just the one doing the
debugging and getting yelled at for debugging, not the one who
deployed the update.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Thinking about a "jessie and a half" release

[Nicholas D Steeves]

Hi Jeffrey,

On 12 July 2016 at 09:28, Jeffrey Walton  wrote:
>
> I think it would benefit more than Skylake users. The last few
> processors are missing support. Below is from a Core i5-5300U (5th
> gen) and a 3.19.0-64-generic kernel.
>
> **
>
> $ dmesg | egrep -i '(error|failed)'
> ...
> [35679.953137] mce: [Hardware Error]: Machine check events logged
> [35980.749723] mce: [Hardware Error]: Machine check events logged
> [36280.594838] mce: [Hardware Error]: Machine check events logged
> [36580.439940] mce: [Hardware Error]: Machine check events logged
> [37029.202190] mce: [Hardware Error]: Machine check events logged
> [37179.118743] mce: [Hardware Error]: Machine check events logged
> [37629.831878] mce: [Hardware Error]: Machine check events logged
> [37779.748453] mce: [Hardware Error]: Machine check events logged
> [38229.510127] mce: [Hardware Error]: Machine check events logged
>
> $ sudo mcelog
> mcelog: Family 6 Model 3d CPU: only decoding architectural errors
>

Out of curiosity, what does the mcelog version in jessie-backports
output when running this kernel version?

Cheers,
Nicholas

Bug#830946: ITP: onedrive -- folder synchronization with OneDrive

[Norbert Preining]

Package: wnpp
Severity: wishlist
Owner: Norbert Preining 

* Package name: onedrive
  Version : 1.1~20160713
  Upstream Author : skilion 
* URL : http://skilion.github.io/onedrive/
* License : GPLv3
  Programming Lang: D
  Description : folder synchronization with OneDrive

OneDrive is the cloud storage system of Microsoft. This package provides
the command line client specialising in synchronizing with OneDrive cloud 
storage.