SV: where to report translation bugs?

[Joe Dalton]

Hi Jonas,
you can find the different addresses here (for bug reports to short and long 
descriptions)
https://lists.debian.org/i18n.html

For Danish
debian-l10n-dan...@lists.debian.org

I'll will open one there and end this tread on debian-devel
bye
Joe



Den fre 15/7/16 skrev Jonas Smedegaard :

 Emne: where to report translation bugs?
 Til: debian-devel@lists.debian.org
 Dato: fredag 15. juli 2016 12.06
 
 Hi,
 
 Where should I most appropriately report bugs in
 translations of long 
 descriptions?
 
 Concretely the danish translation for
 android-platform-tools-base has 
 its command names translated which renders the long
 description pretty 
 useless.
 
 If I investigate further and come up with a fix for such
 bug, it maybe 
 makes sense to report it to the package, but really I
 wouldn't even know 
 what to do myself if one of the packages I maintain got a
 bugreport 
 (without proposed solution) for a language I cannot speak
 myself.
 
 Hence my general question: Where is the ideal place for l10n
 bugs for 
 package descriptions?
 
 
  - Jonas
 
 -- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 
  [x] quote me freely  [ ] ask before reusing  [ ]
 keep private

Re: SV: where to report translation bugs?

[Jonas Smedegaard]

Hi Joe,

Quoting Joe Dalton (2016-07-16 09:22:11)
> you can find the different addresses here (for bug reports to short and long 
> descriptions)
> https://lists.debian.org/i18n.html
> 
> For Danish
> debian-l10n-dan...@lists.debian.org
> 
> I'll will open one there and end this tread on debian-devel

Thanks!

Since my previous post, I remembered that in reportbug there's a flag 
for l10n - is that flag only an aid for the package maintainer, or do 
bugreports then get forwarded to the localization team?

My concern here is if bugreporters need to know special contact 
addresses for localization issues.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: SV: where to report translation bugs?

[Joe Dalton]

 Since my previous post, I remembered that in  reportbug there's a flag  for 
l10n - is that flag only an aid for the package maintainer, or do bugreports 
then get forwarded to the localization team?

- i have never received any bug reports (perhaps just no bug reports) that way 
around, so no forwarding. (only on individuel basis, someone now to send Danish 
issues to me or a reference to the Danish translations groups).

 
 My concern here is if bugreporters need to know special contact addresses for 
localization issues.

- I think a discussion about this took place some years ago. There is no 
automatic system for package descriptions (as I recall).

bye
Joe






-

Re: SV: where to report translation bugs?

[Jonas Smedegaard]

Quoting Joe Dalton (2016-07-16 10:16:52)
[ Jonas wrote: ]
>> Since my previous post, I remembered that in reportbug there's a flag 
>> for l10n - is that flag only an aid for the package maintainer, or do 
>> bugreports then get forwarded to the localization team?
>
> - i have never received any bug reports (perhaps just no bug reports) 
> that way around, so no forwarding. (only on individuel basis, someone 
> now to send Danish issues to me or a reference to the Danish 
> translations groups).
>
> 
>> My concern here is if bugreporters need to know special contact 
>> addresses for localization issues.
>
> - I think a discussion about this took place some years ago. There is 
> no automatic system for package descriptions (as I recall).

Thanks for clarifying.

I am not surprised you get no bugreports, when not tied to our common 
issue tracker but requires "hunting you down" :-(

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Reg: Website for Debian with Keen Interest

[Laura Arjona Reina]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Pradeep

El 13/07/16 a las 09:17, Pradeep Kumar S escribió:
> Hi Team,
> 
> I have been a great user of debian OS and I like to make a big 
> change on Debian Branding. If you don't mind I can work on the 
> Debian site by being a fan. Please consider my interest and
> allow me to develop a brand new website for Debian. Waiting for
> the positive reply. Have a great day!

Thank you for your interest.
The Debian website is big and complicated.

It includes many content that it's automatically generated using wml
and Perl scripts.

It includes a system that tracks translations very well.

We try to make it without running Javascript.

Our wide and extremely diverse audience makes us be maybe more
verbose in content that what is usual nowadays.

For all this, any overhaul or migration becomes quite a difficult task
.

But that doesn't mean we should keep things as is, "just becasuse it
works", if there is a group of people determined to help making the
website better! Indeed the most important thing we need is people
interested in working on the website, so your mail and proposal is
really appreciated.

In my case, I'm member of the website team but not a coder nor a
designer, so my main contributions are translations and some patch
here and there to renew contect or small fixes.

I can point you, however, to some areas where you can start to work
in the website, and then, get used to its current state, and then,
make specific proposals for updates or changes.

Please have a look at:

* How it works, currently, the Debian website:
https://www.debian.org/devel/website/

* The Debian Design team:
https://wiki.debian.org/Design

* The bugs or open tasks for the website:
https://wiki.debian.org/Design
(maybe you can pick something there to start with)

I'll send you another email (CC'ing debian-...@lists.debian.org)
with some areas where you can start to think or contribute to the
content, so you get familiarized with the structure of the pages.

(I don't send it now because I have to go, but I didn't want to
postpone answer to you more...).

Thank you for choosig Debian for your contributions to free software.

Best regards
- -- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQGcBAEBCAAGBQJXifv8AAoJEEw4Yb3McGt0ItsL/RBBLilwDgiXLI4RvGxyQb1H
P8T8rraBobpiVxBINLtmzq74ZJmDYew/ZnTd5aTKdm6JmJLGGP6bTw59NunPm4Y1
AMlfzFc7lpPJf1ij1m69VFqPCrQfeSJIEXOet5q1ATvBJ02ms307cQHL9P2L5RHB
KnT/JFnCNYRW4t9/beyBpse6hyoG6NaQ8laYrYuEZu9avGKbgxqHIbWO0ssvwrQT
wbI4hcU6aDBrXlZoU6gaeWEkmqNCVZehoOB+ci2R2qbI3Cb+rUX8FTB3pOsX+se3
WOm/VXk/ibwNKX5OXN72O3Sw8knowrjf372tJHFBY4GdWs5dw0yCi/cJIZA+EWUe
bIYXGWQacRjxeIYE+OmD/4lt5pHIMrYU8DQ77zkeWC2eBNFfI0HrOmbgflfeznV6
YiFBdm8bMNbqymV/bIHSA3CG9hgIhqPNn4SJDA0jjf0SjJZYU19FJYfIKPeueCTW
v9NWWo14zBeQTPmQZKE5bRziUCerscgFK27hXY5lMA==
=kFUQ
-END PGP SIGNATURE-

Bug#831456: ITP: policyd-rate-limit -- postfix policy daemon limiting the number of mails a user can send

[Valentin Samir]

Package: wnpp
Severity: wishlist
Owner: Valentin Samir 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: policyd-rate-limit
  Version : 0.5.0
  Upstream Author : Valentin Samir 
* URL : https://pypi.python.org/pypi/policyd-rate-limit
* License : GPLv3
  Programming Lang: Python
  Description : postfix policy daemon limiting the number of mails a user 
can send

policyd-rate-limit is a simple postfix policy daemon written in python3
allowing to limit the number of mails a user can send over time.
Users are identified either via their sasl usernames or their ip addresses.
Limitation rules are a list of couples (number of mails, number of seconds).
If a user has sent more than number of mails in number of seconds,
a configurable error is returned to the user.


By limiting the number of mails sent by users, this package allow to mitigate
the effects of a compromised email user account: instead for starting to send 
thousand
of spams, the compromised account will be limited, by default, to 150 mails a 
day.
An option allows policyd-rate-limit to send daily mail reports about who reach
limits to allow abuse detection.


I use it on my personal server.
Once package, it is planned to use it on
https://www.crans.org (a french small ISP) smtp server.

The packages postfix-cluebringer and postfwd provides similar functionalities.
postfix-cluebringer is written in php and use an interface web for 
configuration.
It is also lacking of ipv6 support,
postfwd is written in perl and offer a lot of other advanced functionality and
is more like a firewall for postfix.
Both lack of the mail report support.


The package is uploaded to mentors.debian.net.


I do need sponsor for upload to the debian archive.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXig7RAAoJEJwmwSdHaXDdtAoQAJQka30oXCLxJC98a9eRSTjk
txS2vOwuX7jfXxfp1E2FRLnHrDhKKNZa9PvA0hlhrTKffgDu+W+PQIXF5b768JRB
r0S8xGw86S6EI6phCTwfhQ/R28Mv0z+ztLQPqqj/nDiUaS7IcxRv+bU49TC7PwWb
bvIa2/h/PEyCGnhBS8JVpcim0YEpKB+qbCvxmhek0FntanKKMCC4zJxMzz6aUmKX
+Tp4z5GMQQMmRs8to8X0v0TFl1HY5bCGOG9TjIdDzHF4q3QkBt8p1ho+SDvgEzwX
86sgoXVK2sp4i34JjT4PtqNpnMNzCanLGPRJdRXb+zyU4ctKiUsnHL5Yi5h4HaeB
sDLkG/hgKRY+QJN8GfIel5Asxm6uVLpEPhVs6v/Fpnur264rgYVFSheOmxudw2JH
SdtVI3TIh0v74QlA3C2pOoStvuhoSFoaze2bWD95LOdVcJ4a6fR73HSbf2+Uxskc
oRkUMuoraz3OVNO95xWAqV9ju0y/DHLjFTMXyBSu96uFlnX8WsxBnvjH89vyl9UE
1qqjT/ZxC18YB66xT1UefCrEutQeLKoDqhBKd4+umzs1pHhMuNK61HYKsS2yByAB
m+B7Bc6ermo1qMXP9ivk0Bq/Zg7AjmaY1V3Zx0ZkmSV5Q88a6MUAvthFUmFcPspt
qWxrWcuFrNX7Xoe1Abz8
=5Q9r
-END PGP SIGNATURE-

Re: Reg: Website for Debian with Keen Interest

[Laura Arjona Reina]

Hi again

El 16/07/16 a las 11:19, Laura Arjona Reina escribió:

> 
> * The bugs or open tasks for the website:
> https://wiki.debian.org/Design
> 

Correction:

https://bugs.debian.org/www.debian.org

Best regards
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Re: Reg: Website for Debian with Keen Interest

[Pradeep Kumar S]

  
Thanks for your reply. Im really looking forward to work with your teams its a 
great pleasure. Please post the updated area information.
  
  
 Thank You Best Regards, Pradeep Kumar S, UI/UX Designer  +91 9941328132 
(tel:+91%209941328132)   
  
  
  
  
  
  

  
  
>   
> On Jul 16, 2016 at 2:49 PM,  mailto:larj...@debian.org)> 
>  wrote:
>   
>   
>   
>  -BEGIN PGP SIGNED MESSAGE-  
> Hash: SHA256  
>
> Hi Pradeep  
>
> El 13/07/16 a las 09:17, Pradeep Kumar S escribió:  
> >  Hi Team,  
> >   
> >  I have been a great user of debian OS and I like to make a big  
> >  change on Debian Branding. If you don't mind I can work on the  
> >  Debian site by being a fan. Please consider my interest and  
> >  allow me to develop a brand new website for Debian. Waiting for  
> >  the positive reply. Have a great day!  
>
> Thank you for your interest.  
> The Debian website is big and complicated.  
>
> It includes many content that it's automatically generated using wml  
> and Perl scripts.  
>
> It includes a system that tracks translations very well.  
>
> We try to make it without running Javascript.  
>
> Our wide and extremely diverse audience makes us be maybe more  
> verbose in content that what is usual nowadays.  
>
> For all this, any overhaul or migration becomes quite a difficult task  
> .  
>
> But that doesn't mean we should keep things as is, "just becasuse it  
> works", if there is a group of people determined to help making the  
> website better! Indeed the most important thing we need is people  
> interested in working on the website, so your mail and proposal is  
> really appreciated.  
>
> In my case, I'm member of the website team but not a coder nor a  
> designer, so my main contributions are translations and some patch  
> here and there to renew contect or small fixes.  
>
> I can point you, however, to some areas where you can start to work  
> in the website, and then, get used to its current state, and then,  
> make specific proposals for updates or changes.  
>
> Please have a look at:  
>
> * How it works, currently, the Debian website:  
> https://www.debian.org/devel/website/   
>
> * The Debian Design team:  
> https://wiki.debian.org/Design   
>
> * The bugs or open tasks for the website:  
> https://wiki.debian.org/Design   
> (maybe you can pick something there to start with)  
>
> I'll send you another email (CC'ing  debian-...@lists.debian.org 
> (mailto:debian-...@lists.debian.org))  
> with some areas where you can start to think or contribute to the  
> content, so you get familiarized with the structure of the pages.  
>
> (I don't send it now because I have to go, but I didn't want to  
> postpone answer to you more...).  
>
> Thank you for choosig Debian for your contributions to free software.  
>
> Best regards  
> - --  
> Laura Arjona Reina  
> https://wiki.debian.org/LauraArjona   
> -BEGIN PGP SIGNATURE-  
> Version: GnuPG v2  
>
> iQGcBAEBCAAGBQJXifv8AAoJEEw4Yb3McGt0ItsL/RBBLilwDgiXLI4RvGxyQb1H  
> P8T8rraBobpiVxBINLtmzq74ZJmDYew/ZnTd5aTKdm6JmJLGGP6bTw59NunPm4Y1  
> AMlfzFc7lpPJf1ij1m69VFqPCrQfeSJIEXOet5q1ATvBJ02ms307cQHL9P2L5RHB  
> KnT/JFnCNYRW4t9/beyBpse6hyoG6NaQ8laYrYuEZu9avGKbgxqHIbWO0ssvwrQT  
> wbI4hcU6aDBrXlZoU6gaeWEkmqNCVZehoOB+ci2R2qbI3Cb+rUX8FTB3pOsX+se3  
> WOm/VXk/ibwNKX5OXN72O3Sw8knowrjf372tJHFBY4GdWs5dw0yCi/cJIZA+EWUe  
> bIYXGWQacRjxeIYE+OmD/4lt5pHIMrYU8DQ77zkeWC2eBNFfI0HrOmbgflfeznV6  
> YiFBdm8bMNbqymV/bIHSA3CG9hgIhqPNn4SJDA0jjf0SjJZYU19FJYfIKPeueCTW  
> v9NWWo14zBeQTPmQZKE5bRziUCerscgFK27hXY5lMA==  
> =kFUQ  
> -END PGP SIGNATURE-  
>  

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

[Theodore Ts'o]

On Thu, Jul 14, 2016 at 01:57:13PM +1000, Peter Hutterer wrote:
> libinput is a lot smarter than synaptics when it comes to palm
> detection.

Question about libinput?  The main reason why I'm using synclient
because I have a Thinkpad T540p which doesn't have hard buttons for
the "mouse buttons".  It does have TrackPoint which I infinitely
prefer to the !@#?! horrendo Trackpad on the T540p.  So I do the
following to only use the Trackpad for buttons.

synclient RightButtonAreaTop=0
synclient RightButtonAreaRight=4858
synclient RightButtonAreaBottom=5000
synclient RightButtonAreaLeft=3500

synclient MiddleButtonAreaTop=0
synclient MiddleButtonAreaRight=3499
synclient MiddleButtonAreaBottom=5000
synclient MiddleButtonAreaLeft=2800

synclient coastingFriction=50
synclient coastingSpeed=15

synclient areaTopEdge=6000
synclient areaLeftEdge=0
synclient VertEdgeScroll=0
synclient HorizEdgeScroll=0

Basically, I don't want to use the Trackpad for mouse events, not
*ever*.  And even if the keyboard and trackpoint are quiscent, I don't
want a random palm swipe to be registered a mouse or button event ---
only when the pad is physically depressed.

What's the equivalent way of doing the same thing with the libinput
driver?  (Note: I'm still using the X server, not Wayland, and I'm
using XFCE).

Thanks,

- Ted

Policy 12.3: should I rename?

[Shachar Shemesh]

I am working on bringing the libargtable2 package up to date with both
upstream changes and the Debian policy. One of the changes state:

recommend to ship additional documentation for package |pkg| in a
separate package |pkg-doc| and install it into |/usr/share/doc/pkg|.

The package currently ships the docs in a package calles
"libargtable2-docs" (plural). I am wondering whether I should rename it,
and how to do it.

As far as I can tell, I have three options:

 1. Don't rename. It's only a "recommends".
 2. Rename with full transitional package
 3. Rename without transitional package

The incentive for doing 3 is that the dev package already depends on the
docs package, so a transitional package might not be all that important.

Another question I have is regarding packaging. The Policy suggests that
libargtable2-doc should install the docs to /usr/share/doc/libargtable2.
It seems that debhelper is not a friend in that regard, pushing me to
install to /usr/share/doc/libargtable2-doc. Am I missing some option
that would make that easy?

Shachar

Bug#831515: ITP: sdnotify -- A pure Python implementation of systemd's service notification protocol

[Orestis Ioannou]

Package: wnpp
Severity: wishlist
Owner: Orestis Ioannou 

* Package name: sdnotify
  Version : 0.3.1
  Upstream Author : Brett Bethke 
* URL : https://github.com/bb4242/sdnotify
* License : MIT
  Programming Lang: Python
  Description : A pure Python implementation of systemd's service
notification protocol

his is a pure Python implementation of the systemd sd_notify protocol.

This protocol can be used to inform systemd about service start-up completion,
watchdog events, and other service status changes.
Thus, this package can be used to write system services in Python that play
nicely with systemd.

sdnotify is compatible with both Python 2 and Python 3.

I need this package as it is a dependency for crossbar

EOMA68-A20 Crowd-funded Laptop and Micro-Desktop

[Luke Kenneth Casson Leighton]

https://www.crowdsupply.com/eoma68/micro-desktop

i've been working on a strategy to make it possible for people to have
more control over the hardware that they own, and for it to cost less
money for them to do so, long-term.  i've had to become an open
hardware developer in order to do that.

i believed for a long long time that leaving hardware design to the
mass-volume manufacturers would result in us having affordable
hardware that we could own.  they would make stuff; we could port
OSes to it, everybody wins.  starting in 2003 and working for almost
2 years continuously on reverse-engineering i got a bit of a rude but
early wake-up call where i learned just how naive that expectation
really is [1].  example: it took over THREE YEARS for cr2 to
reverse-engineer the drivers for the HTC Universal clamshell 3G
micro-laptop.

for everyone else, that message came through loud and clear with
mjg59's android tablet GPL violations list - which he stopped maintaining
because it was pointless to continue [2][3].  it was a bit of a slap in
the face - a wake-up call which not only debian but every other ARM
free software distribution is painfully reminded of on a regular basis
when someone new contacts them and asks:

  "I have hardware {X} bought off of Amazon / Aliexpress, can i run
   Linux on it"

and pretty much every time someone has to spend their time patiently
explaining that no, it's not possible, due to the extraordinary
amount of reverse-engineering that's required due to rampant and:
endemic GPL violations, and even if they could, it's *already too late*
due to "Single-Board Computer Supernova Lifecycle" syndrome.

shockingly even intel do not really "Get It".  not only do they have
the arbitrary remote code execution backdoor co-processor [4]
in every x86_64 processor since 2009, but in speaking to a member
of the intel open source education team at fosdem2016 i learned that
intel considers something as trivial as DDR3 RAM initialisation
sequences to be "commercial advantage" and this they use as
justification for not releasing the 200 lines of code needed... not
that it would help very much because of the RSA secret key needed
to sign early boot code.

we also have the issue of proliferation of linux kernel device drivers:
put simply if there are M processors and N "types of products",
we can reasonably and rationally expect the number of submissions
of device drivers and device tree files for upstream inclusion to be of the
order of "M *TIMES* N".  with "M" just in the ARM world alone being
enormous (over 650 licensees as of 10 years ago) and "N" likewise
being huge, this places a huge burden on the linux kernel developers,
and an additional burden downstream on you, the OS maintainers, as
well.

... would it not be better to have hardware that was designed around
"M plus N"?  this would stop the endemic proliferation of device drivers,
would it not?

so this is the primary driving factor behind EOMA68 - to reduce the
burden of work required to be carried out by software libre developers,
as well as reduce the long-term cost of ownership of hardware for
everyone.

so after five years i can finally say that the EOMA68 standard is
ready, and with the last (and final) revision adding in USB 3.1 it
can be declared to have at least a decade of useful life ahead of
it.  there are NO "options".  there will be NO further changes made
(which would result in chaos). a modern Computer Card bought
10 years from now will still work with a Housing that's bought today,
and vice-versa.

if this approach is something that you feel is worthwhile supporting,
the crowd funding campaign runs for another 40 days.  crowd funding
campaigns are about supporting "ideas" and being rewarded with
a gift for doing so.  they're not about "buying a boxed product under
contract of sale".

with your support it will be possible to bring other designs and other
processors to you later.  picking a processor has its own interesting
challenges [5] if you have ethical business considerations to take
into account, such as "don't use anything that's GPL violating or
otherwise illegal". [why *is* it that people think it's okay to sell GPL
violating products, even amongst the open hardware community?
ethical ends can never be justified by unethical means].

lastly, i'm... reluctant to bring this up, but i have to.  *deep breath*.
i'm aware that a lot of people in the debian world don't like me. many
of you *genuinely* believe that i am out to control you, to tell you
what to do, to "order you about".  which is nonsense, but, more
importantly, rationally-speaking, completely impossible given the
nature of free software.  we can therefore conclude, rationally, that
the conclusion reached by many of you [that i am "ordering you
about"] simply cannot be true.

after thinking about this for a long, long time, my feeling is that this
startlingly and completely overwhelmingly WRONG impression
stems from my reverse-engineering background, which, wh

Bug#831517: ITP: u-msgpack-python -- A portable, lightweight MessagePack serializer and deserializer written in pure Python

[Orestis Ioannou]

Package: wnpp
Severity: wishlist
Owner: Orestis Ioannou 

* Package name: u-msgpack-python
  Version : 2.1
  Upstream Author : Vanya Sergeev 
* URL : ttps://github.com/vsergeev/u-msgpack-python
* License : MIT
  Programming Lang: Python
  Description : A portable, lightweight MessagePack serializer and
deserializer written in pure Python

u-msgpack-python is a lightweight MessagePack serializer and deserializer
module written in pure Python,
compatible with both Python 2 and Python 3, as well as CPython and PyPy
implementations of Python.
u-msgpack-python is fully compliant with the latest MessagePack specification.
In particular, it supports the new binary, UTF-8 string, and application-
defined ext types.

This is a dependency for crossbar

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

[Peter Hutterer]

On 17/07/2016 05:49 , Theodore Ts'o wrote:

On Thu, Jul 14, 2016 at 01:57:13PM +1000, Peter Hutterer wrote:

libinput is a lot smarter than synaptics when it comes to palm
detection.


Question about libinput?  The main reason why I'm using synclient
because I have a Thinkpad T540p which doesn't have hard buttons for
the "mouse buttons".  It does have TrackPoint which I infinitely
prefer to the !@#?! horrendo Trackpad on the T540p.  So I do the
following to only use the Trackpad for buttons.

synclient RightButtonAreaTop=0
synclient RightButtonAreaRight=4858
synclient RightButtonAreaBottom=5000
synclient RightButtonAreaLeft=3500

synclient MiddleButtonAreaTop=0
synclient MiddleButtonAreaRight=3499
synclient MiddleButtonAreaBottom=5000
synclient MiddleButtonAreaLeft=2800

synclient coastingFriction=50
synclient coastingSpeed=15

synclient areaTopEdge=6000
synclient areaLeftEdge=0
synclient VertEdgeScroll=0
synclient HorizEdgeScroll=0

Basically, I don't want to use the Trackpad for mouse events, not
*ever*.  And even if the keyboard and trackpoint are quiscent, I don't
want a random palm swipe to be registered a mouse or button event ---
only when the pad is physically depressed.

What's the equivalent way of doing the same thing with the libinput
driver?  (Note: I'm still using the X server, not Wayland, and I'm
using XFCE).


At runtime:
xinput set-prop "libinput Send Events Modes Enabled" 1 0

Static config:
cat > /etc/X11/xorg.conf.d/99-libinput-disable-touchpad.conf
Section "InputClass"
   Identifier "disable touchpad"
   MatchDriver "libinput"
   MatchIsTouchpad "on"
   Option "SendEventsMode" "disabled"
EndSection

Any typos in the above are of course fully intended ;)

Long explanation: libinput doesn't have a concept of disabling a device 
because in some cases (like the T540 series) a disabled device still 
needs to send events. So we named the "send events mode", i.e. it 
decides whether the device will send events or not.


On the Lenovo *40 series, libinput reroutes top button events already 
anyway, those buttons always come out of the trackpoint device.
when you disable the touchpad the top software buttons will still work 
since they are logically part of some other device. We'll also 
automatically increase the button area in that case to make the buttons 
easier to hit.


Cheers,
  Peter

Re: [RFC] Switching dpkg-deb --uniform-compression by default

[Steve McIntyre]

On Fri, Jul 15, 2016 at 04:50:27AM +0200, Cyril Brulebois wrote:
>Hi,
>
>Guillem Jover  (2016-07-06):
>> I'd like consider switching dpkg-deb --uniform-compression by default,
>> so that both control.tar and data.tar members use the same
>> compression, which currently would be xz (or gzip with -Zgzip).
>
>(AFAICT 'none' is still supported, contrary to 'bzip2' and 'lzma').
>
>That wouldn't seem crazy to me.
>
>> This would give us more uniform and smaller packages. I think the d-i
>> people wanted something like this (?).
>
>[ Adding debian-boot@, where “the d-i people” are, and debian-cd@ for
>  completeness. ]
>
>A few years ago we pushed for xz compression in some key packages to try
>and squeeze more packages into installation images, notably CD#1; ISTR
>that would only change the data part and not the control one, which
>would limit the size gain for some specific packages. debian-cd only
>generates netinst CDs nowadays so that's no longer a hot topic for us
>AFAIK.

Almost - after some pleas we've added back a CD-only build for Xfce
too. But that's not massively relevant here I think. :-)

>> Not all .deb parsers support control.tar.xz yet, but most do:
>> 
>
>udpkg's status there seems correct (supports gz/xz/no compression), and
>just to be sure: I've just checked that compression_type is indeed
>handled independently for control (in udpkg.c's dpkg_unpackcontrol) and
>for data (dpkg_dounpack).
>
>> Would there be any objections to this?
>
>Bottom-line from a d-i point of view: having both compression in sync by
>default shouldn't change anything on our side (shouldn't gain us much
>but shouldn't do much harm either).

Agreed.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane


signature.asc
Description: Digital signature