Reg: Website for Debian with Keen Interest
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, Warm Regards *Pradeep Kumar S* UI/UX Designer Codexsys *Contact:* +91 99413 28132
Re: ITP: django-setuptest -- simple test suite enabling Django app testing via setup.py
Hi, > ITP: django-setuptest -- simple test suite enabling Django app testing via > setup.py Do note that upstream is a little--err--slow, and doesn't even support the version of Django that's currently in sid: https://github.com/praekelt/django-setuptest/pull/26 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#830981: ITP: python-zenoss -- module to work with the Zenoss JSON API
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: python-zenoss Version : 0.6.2 Upstream Author : Seth Miller * URL : https://github.com/iamseth/python-zenoss * License : WTFPL Programming Lang: Python Description : module to work with the Zenoss JSON API
Bug#830983: ITP: field -- extracts a list of fields from a file
Package: wnpp
Severity: wishlist
Owner: Trevor Bramwell
* Package name: field
Version : 0.2.0
Upstream Author : Trevor Bramwell
* URL : https://github.com/bramwelt/field
* License : GPLv3+
Programming Lang: Python
Description : extract a list of fields from a file
field it is a simpler version of:
awk '{ print $5,$3,$1; }'
and similar scripts. Field defaults to spliting lines, read from stdin
and written to stdout, on whitespace (space and tab).
The benefits it provides over the above awk pattern and cut are:
- Out of order printing
field 3 2 3 1 < file
- Ranges
field 5-1 < file
- Repetition
field 2 2 2 2 < file
I am the sole creator of field and expect to maintain the package when
new bugs are found. The first build of the package can be found on my
website[1] and as this is my first Debian package I would appreciate a
sponsor.
[1] https://trevor.bramwell.net/downloads/field_0.2.0-1_amd64.deb
Re: Browserified files and DFSG
On Monday 11 July 2016 05:43 PM, Paul Wise wrote: > On Mon, Jul 11, 2016 at 8:36 AM, Pirate Praveen wrote: > >> There is a bug with severity serious filed against libjs-handlebars [1] > > I note that this bug was filed by an FTP-team member. I have referred this to CTTE http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978 signature.asc Description: OpenPGP digital signature
Re: Bug#830983: ITP: field -- extracts a list of fields from a file
On Jul 13, Trevor Bramwell wrote:
> field it is a simpler version of:
>
> awk '{ print $5,$3,$1; }'
Do we really need this trivial program which barely saves typing a few
characters, especially in a standalone package?
Also, what is wrong with cut(1)?
--
ciao,
Marco
signature.asc
Description: PGP signature
Re: Bug#830983: ITP: field -- extracts a list of fields from a file
On Wed, Jul 13, 2016 at 06:47:22PM +0200, Marco d'Itri wrote: > Do we really need this trivial program which barely saves typing a few > characters, especially in a standalone package? > Also, what is wrong with cut(1)? Seems to me two retoric questions. Quoting the original posting: > > I am the sole creator of field and expect to maintain the package when > > new bugs are found. The first build of the package can be found on my > > website[1] and as this is my first Debian package I would appreciate a > > sponsor. That seems to me a "Debian is a good FLOSS project, I want to contribute, here is my code which I have allready packaged!" Where I can understand the Point Of View of both Trevor and Marco, think I that the answer is some where in the middle. Such has having the 'field' codo in an existing Debian package. Groeten Geert Stappers [1] https://trevor.bramwell.net/downloads/field_0.2.0-1_amd64.deb -- Leven en laten leven
Re: Bug#830983: ITP: field -- extracts a list of fields from a file
On Wed, Jul 13, 2016 at 07:39:32PM +0200, Geert Stappers wrote: > That seems to me a "Debian is a good FLOSS project, I want to contribute, > here is my code which I have allready packaged!" Bingo. In fact the code is already packaged for Python[1]. I have high hopes of getting more involved in Debian and this is my 'foot-in-the-water'. > Where I can understand the Point Of View of both Trevor and Marco, > think I that the answer is some where in the middle. I wrote this specifically because it was clear coreutils is not interested[2] in including these changes into 'cut'; understandably because of backwards-compatability. > Such has having the 'field' codo in an existing Debian package. If you would be so kind as to point me to the right package this should be included in, I'd be happy to discuss it with the maintainer and close this bug. Regards, Trevor Bramwell [1] https://pypi.python.org/pypi/field [2] https://www.gnu.org/software/coreutils/rejected_requests.html See 'cut -f2,1' and 'cut -d '[:blank:]'. signature.asc Description: Digital signature
Re: Bug#830983: ITP: field -- extracts a list of fields from a file
On Wed, Jul 13, 2016 at 01:08:25PM -0500, Matt Zagrabelny wrote: > Perhaps moreutils? > > The utilities provided therein are (partially) written in perl. So it > is out of place in that regards - but certainly not a show stopping > road block. > > Joey Hess is the maintainer according to: > > apt-cache show moreutils | grep '^Maintainer:' > Maintainer: Joey Hess That's obsolete information. https://tracker.debian.org/pkg/moreutils has current information. -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: Bug#830983: ITP: field -- extracts a list of fields from a file
On Wed, Jul 13, 2016 at 12:50 PM, Trevor Bramwell wrote: > On Wed, Jul 13, 2016 at 07:39:32PM +0200, Geert Stappers wrote: >> Such has having the 'field' codo in an existing Debian package. > > If you would be so kind as to point me to the right package this should > be included in, I'd be happy to discuss it with the maintainer and close > this bug. Perhaps moreutils? The utilities provided therein are (partially) written in perl. So it is out of place in that regards - but certainly not a show stopping road block. Joey Hess is the maintainer according to: apt-cache show moreutils | grep '^Maintainer:' Maintainer: Joey Hess -m
Re: Bug#830983: ITP: field -- extracts a list of fields from a file
On Wed, Jul 13, 2016 at 1:14 PM, Lars Wirzenius wrote: > On Wed, Jul 13, 2016 at 01:08:25PM -0500, Matt Zagrabelny wrote: >> Perhaps moreutils? >> >> The utilities provided therein are (partially) written in perl. So it >> is out of place in that regards - but certainly not a show stopping >> road block. >> >> Joey Hess is the maintainer according to: >> >> apt-cache show moreutils | grep '^Maintainer:' >> Maintainer: Joey Hess > > That's obsolete information. Indeed! :) I thought I was performing the command on a sid machine, but it was jessie. Oops! -m
Bug#831038: ITP: python-pydotplus -- interface to Graphviz's Dot language
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-pydotplus Version : 2.0.2 Upstream Author : Carlos Jenkins * URL : http://pydotplus.readthedocs.org/ * License : Expat Programming Lang: Python Description : interface to Graphviz's Dot language PyDotPlus is an improved version of the old pydot project that provides a Python Interface to Graphviz's Dot language. . Differences with pydot: * Compatible with PyParsing 2.0+. * Python 2.7 - Python 3 compatible. * Well documented. * CI Tested.
Re: Bug#830292: ITP: django-setuptest -- simple test suite enabling Django app testing via setup.py
Thanks, but according to the Changelog, Django 1.9 is supported in the latest release (0.2.1). https://github.com/praekelt/django-setuptest/blob/develop/CHANGELOG.rst (I'm assuming that Django's APIs are stable between 1.9 and 1.9.7.) My package is here if you'd like to try it: https://mentors.debian.net/package/django-setuptest Christopher On 13 July 2016 at 10:32, Chris Lamb wrote: > Hi, > > > ITP: django-setuptest -- simple test suite enabling Django app testing > via setup.py > > Do note that upstream is a little--err--slow, and doesn't even support > the version of Django that's currently in sid: > > https://github.com/praekelt/django-setuptest/pull/26 > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- >
Bug#831042: ITP: django-memoize -- implementation of memoization technique for Django
Package: wnpp Severity: wishlist Owner: Christopher Hoskin * Package name: django-memoize Version : 1.3.1 Upstream Author : Thadeus Burgess, Thomas Vavrys et al * URL : https://pythonhosted.org/django-memoize/ * License : BSD Programming Lang: Python Description : implementation of memoization technique for Django django-memoize is an implementation of the memoization technique for Django. You can think of it as a cache for function or method results. . In memoization, the functions arguments are also included into the cache_key. Memoize is also designed for methods, since it will take into account the repr of the ‘self’ or ‘cls’ argument as part of the cache key. The theory behind memoization is that if you have a function you need to call several times in one request, it would only be calculated the first time that function is called with those arguments. I would hope that the Python Modules Team would be willing to maintain the package. I am not a DD, so require a sponsor.
Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics
On Thu, 2016-07-14 at 13:41 +1000, Peter Hutterer wrote: Thanks for the thorough analysis. > The second component is that apparently tapping doesn't work when > enabled. That's most probably a bug, file one against libinput at > bugs.freedesktop.org and it'll get fixed. Done. Having to filing it against a Wayland component was novel, and encouraging. signature.asc Description: This is a digitally signed message part
Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics
[Disclaimer: I'm jumping in because of the LWN quote of the week and I'm just reconstructing the emails from the archives, I'm not subscribed. Apologies if the thread breaks or any other side effects. Please keep me in CC] On Tue, Jul 12, 2016 at 09:36:16AM +1000, Russell Stuart wrote: > On Mon, 2016-07-11 at 23:51 +0200, Raphael Hertzog wrote: > > Well, if some KDE/XFCE/etc. packages work only with synaptics and not > > with libinput, then we should get those packages updated to depend on > > xserver-xorg-input-synaptics, no? > > I don't know about KDE/XFCE, but in the etc category is LXDE, and it > works with both. I'd be surprised if KDE and XFCE didn't work with > both too as libinput and synaptics are drivers, and as such are hidden > by the X API these window managers use. The surprising thing for me is > GNOME evidently isn't using the X API, but instead talking to the > driver directly. You're misinterpreting things here. GNOME is using the X device property API to talk to the driver - the same way as it does for synaptics or anything else. The property API is a generic key/value API (see XIChangeProperty) and when you set properties you have to know which format to set. It's the same API the xinput tool uses (and synclient, syndaemon, xsetwacom, etc.) The reason why supporting both drivers is because the properties are highly driver specific. If you want to enable tap-to-click on synaptics, you need to set the fifth, sixth and seventh byte of the "Synaptics Tap Action" property to 1, 3 and 2, respectively. This is exactly what g-s-d and any other config tool did before. libinput has different configuration options. We discussed making it 1:1 compatible but it was deemed impossible, especially given how little benefit we would get from it. So xf86-input-libinput's properties are different - e.g. tapping is enabled by setting the boolean "libinput Tapping Enabled" property to 1. also note: xf86-input-libinput is the X driver that wraps "libinput the library", we tend to use the two interchangably though, especially in the X context. the X driver has very little functionality beyond mapping between X and libinput APIs. > In my case, the thing that broke when xserver-xorg briefly switched to > using libinput instead of synaptics wasn't LXDE, it was me. The > reasons are spelled out in the bug that was filed when the change was > made: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822835 > > Briefly: synaptics is much better touchpad driver than libinput. > Libinput treats a touchpad as a mouse. Modern MAC like touchpads are > great input devices, but when you strip them of multitouch and gesture > recognition they become so unwieldly people give up and plug in a real > mouse. That statement is false. We have plenty of documentation online that explains what we do with touchpads. https://wayland.freedesktop.org/libinput/doc/latest/touchpads.html The only features I can think of that definitely don't work anymore are circular scrolling and corner tapping. I think everything else is supported, albeit not always in exactly the same manner as synaptics did. Tapping, two-finger scrolling, edge scrolling, etc. they're all supported. Speaking of gesture recognition: we have actual gesture recognition in libinput, something synaptics never had (beyond two-finger scrolling). See https://wayland.freedesktop.org/libinput/doc/latest/gestures.html back to the bug: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822835 there are two components to this bug: one is that you're using synclient which is a tool specifically written to interact with the synaptics driver. Historical fact: it used to use shm to communicate with the driver before I added the device properties to the server (~8 years ago). As an analogy: fsck.ext3 won't work on btrfs either. syndaemon is the same, it monitors the events in the server and uses synaptics-specific properties to disable the touchpad. This isn't needed anymore in libinput and the equivalent disable-while-typing feature is enabled by default. The second component is that apparently tapping doesn't work when enabled. That's most probably a bug, file one against libinput at bugs.freedesktop.org and it'll get fixed. Cheers, Peter
Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics
[Disclaimer: I'm jumping in because of the LWN quote of the week and I'm just reconstructing the emails from the archives, I'm not subscribed. Apologies if the thread breaks or any other side effects. Please keep me in CC] On Tue, 2016-07-12 at 07:48 +0300, Lars Wirzenius wrote: > For me, the opposite is true. After Raphael's mail yesterday, I > switched from the synaptics driver to the xinput one (by removing point of order :) - synaptics == xf86-input-synaptics == old X touchpad driver - libinput == the library to handle libinput, used by wayland compositors and - xf86-input-libinput == the X driver wrapping libinput, though for simplicity in most X context worring about the difference between the driver and libinput doesn't matter - xinput == a commandline tool to change X device properties and a couple of other X Input Extension calls. There's no "xinput" driver, and xinput is similar to tools like gsettings, it has no knowledge of the other end, the properties API is a generic one. synclient is a synaptics-specific tool that uses the same API that xinput uses but because it's synaptics specific it can have a more 'intuitive' interface. (haha. as if TapButton1 was intuitive. anyway, you get the gist :) > xserver-xort-input-synaptics) and since then, I've not had a single > case of moving the mouse or clicking by tapping by accident. When the > opposite change happened a few weeks ago, the accidents started > happening with such frequency that I could barely finish a sentence in > the same window I started it. As a result, I started pulling out my > hair and when I had no hair left on my head, I switched to an external > mouse. The doctors say I should make a complete hair-recovery and my > barber is very happy about that. > > So for me, the "palm detection" that the xinput driver does, is very > much better than what the synaptics driver does. This might be because > the xinput driver is less smart than the synaptics one, but the end > result for me is a massively better user experience. Tapping and > two-finger scrolling work perfectly fine with the xinput driver, too. libinput is a lot smarter than synaptics when it comes to palm detection. there's only so much we can do with the data we get from touchpads (it's pretty terrible) but the couple of things we do are: we look for touches in areas on the touchpads that are likely palms and monitor those touches. If they exhibit palm behaviour we ignore them. And the touchpad monitors the keyboard and the trackstick (if any) for activity and disables itself, depending on the input (without the need for an external process like syndaemon). There are a couple of details synaptics never had, for example if you rest your palm on the touchpad while typing that palm won't generate touch events. But if you start a touch immediately after the last key press that finger *will* generate touch events. Both are common scenarios that need special treatment. https://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html Cheers, Peter
Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics
On Thu, 2016-07-14 at 14:13 +1000, Russell Stuart wrote: > The second component is that apparently tapping doesn't work when > > enabled. That's most probably a bug, file one against libinput at > > bugs.freedesktop.org and it'll get fixed. > > Done. For anyone still following along it is possible to get libinput to work as least as well synaptics on my laptop (and I presume all others): https://bugs.freedesktop.org/show_bug.cgi?id=96925#c6 Short form: there are bugs somewhere, but you can work around them. signature.asc Description: This is a digitally signed message part
