Bug#837401: ITP: osmalchemy -- OpenStreetMap to SQLAlchemy bridge
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: osmalchemy Version : 0.1a0 Upstream Author : Dominik George, Eike Tim Jesinghaus * URL : https://github.com/Natureshadow/OSMAlchemy * License : MIT Programming Lang: Python Description : OpenStreetMap to SQLAlchemy bridge OSMAlchemy is a bridge between SQLAlchemy and the OpenStreetMap API. . OSMAlchemy's goal is to provide completely transparent integration of the real-world OpenStreetMap data within projects using SQLAlchemy. It provides two things: . 1. Model declaratives resembling the structure of the main OpenStreetMap database, with some limitations, usable wherever SQLAlchemy is used, and 2. Transparent proxying and data-fetching from OpenStreetMap data. . The idea is that the model can be queried using SQLAlchemy, and OSMAlchemy will either satisfy the query from the database directly or fetch data from OpenStreetMap. The package should be co-maintained by the Debian Python Modules Team. -BEGIN PGP SIGNATURE- iQJhBAEBCABLBQJX1TZYMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW xhIP/2wf4p7/NZR7M62t6XrnYOVX/ddiTZn3MjyWmXbckyb9CDB92ofxcFPji8MQ AUyDs79hLLJqyyPnRG4YvtMaIvFg4GALKaGP0lpZj7rahK5ir15r5Ez+mLyMzo4k Eum4l3kxnffDP1rzVbZ0eycjQnr4+Utrc8MLXD7Ix/fA1tYDIwmtnmwjEyXnKAW0 qTzDWpByqOPeIw3urtPIfSg2CLGFe35JIJxkHL2LioGjJs4JXWo8YcZsx7HwcRuP C4kYFJBibTvWiDI6CwqmKa5w7VOUn3gSVx+/m5t8E9/d9NymTIr0xk9Wjpr+ti/z +M3wtrV99F+m8A2N+NJnsA4SK24hgMHTUfm1FyQOvvo+XP+diH0GufJmSZ6LO2Uh L3ew8UgxSyOPzm6FZqf7tOy7AzYGJ4HcwOZWJsbqoKT0NXIigGP3oj3WmlDPtOiJ KPNs0h97B7u3qNmy/KRukMhaSC4Wd2015rlM0yuERfw2tmdwRiATP2sBGw55rE9u 97sBEooWNEQYBkKVXIgn3tQkfh/WFY1Tc9k8Kqag51dl74PqV01NXVayTt3vQYle k/B2xj35eI5/0IDEVmAsMni7mXftsDRKUf1PO5+1aQEcwwil+irXnnMBXtqx/N6i YBKmMyQ8qdv2QsqU1XP74JAoWz6hgIB6uYxgjw14FG/C3l0g =86vr -END PGP SIGNATURE-
lirc and new upstream release, can we update?
Hi, I would like to have the new lirc in time for Stretch. Alec (upstream) really wants us to update it, for various reasons (including bug reports about outdated releases), new features, RC bug fixed, porting to new libraries, less Debian-diverging package, package in sync between Fedora, Debian and Ubuntu (not three-differently-behaving-packages) and so on. Since the pkg-lirc is almost dead (the last uploader retired some days ago), and Stefan is too busy to review it again, I'm asking for advices: 1) would it be nice to upload the package on experimental and ask for testing? 2) would it be possible to create a lirc-ng package and conflict with the current one, so people can choose the best one for them? 3) NMU in unstable seems unfair and possibly a source of troubles for such a complex package (with complex changes). there is a new systemd integration, and some breaking changes on the configuration file (with some migration helpers), but I really think following upstream will be a benefit for our end users. Did I miss anything? anybody wants to test the package on mentors? Any other idea? thanks, (Alec, please update it, or complete this mail with your opinion if I missed some bits) Gianfranco
Re: Automating importing sso certificates into chromium/chrome
On 10.09.2016 18:05, Enrico Zini wrote: > I manually generated a new certificate with sso.debian.org, then > combined them into a PEM: > >cat enrico.crt enrico.key > enrico.pem > > I then tried to import them into chromium using certutil: > >certutil -d sql:/home/enrico/.pki/nssdb -A -i enrico.pem -n > sso.debian.org -t u -u C > > But the certificate shows up in chrome://settings/certificates under > "Other" instead of "Your Certificates". > > I could not find any combination of -t and -u that would make the > certificate show up in the right place. > > Is there a way to do it automatically with certutil? If so, The process > of enrolling with chrome could be easily scripted. Did you try pk12util with a PKCS#12 file (bundle of key and certificate) already? (-d, -i as above, and -W for the password of the PKCS#12 file, which can be the empty string.) Probably something like "openssl pkcs12 -export -inkey enrico.key -in enrico.crt -name enrico -out enrico.p12" and something for the password to generate the PKCS#12 blob. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#837435: ITP: colorspacious -- powerful, accurate, and easy-to-use Python library for doing colorspace conversions
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: colorspacious Version : 1.0.0 Upstream Author : Nathaniel J. Smith * URL : https://github.com/njsmith/colorspacious * License : MIT Programming Lang: (Python Description : powerful, accurate, and easy-to-use Python library for doing colorspace conversions needed by matplotlib 2.x
Various ITPs for Mbrola voices
Hello, With the newer versions of espeak, there is potential use for other Mbrola voices. I thus intend to upload these voices to increase the high-quality voice coverage. ITP: mbrola-br2 -- Brazilian Portuguese female voice for Mbrola ITP: mbrola-br4 -- Brazilian Portuguese female voice for Mbrola ITP: mbrola-de1 -- German female voice for Mbrola ITP: mbrola-de2 -- German male voice for Mbrola ITP: mbrola-de3 -- German female voice for Mbrola ITP: mbrola-ir1 -- Farsi male voice for Mbrola ITP: mbrola-lt1 -- Lithuanian male voice for Mbrola ITP: mbrola-lt2 -- Lithuanian male voice for Mbrola ITP: mbrola-mx1 -- Mexican Spanish male voice for Mbrola Samuel Subject: ITP: mbrola-br2 -- Brazilian Portuguese female voice for Mbrola Package: wnpp Version: N/A; reported 2016-09-11 Severity: wishlist Owner: Samuel Thibault * Package name: mbrola-br2 Version : 2.021 Upstream Author : Faculte Polytechnique de Mons - mbrola team * URL : http://tcts.fpms.ac.be/synthesis * License : see the file readme.txt in the source zip: non-free as in without source code, and for non-commercial, non-military purposes, with and only with the mbrola package made available by the author. Description : Brazilian Portuguese female voice for Mbrola This package contains a Brazilian Portuguese diphone database provided in the context of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/ . It provides a Brazilian Portuguese female voice to be used with the MBROLA program. Subject: ITP: mbrola-br4 -- Brazilian Portuguese female voice for Mbrola Package: wnpp Version: N/A; reported 2016-09-11 Severity: wishlist Owner: Samuel Thibault * Package name: mbrola-br4 Version : 1.0 Upstream Author : Faculte Polytechnique de Mons - mbrola team * URL : http://tcts.fpms.ac.be/synthesis * License : see the file readme.txt in the source zip: non-free as in without source code, and for non-commercial, non-military purposes, with and only with the mbrola package made available by the author. Description : Brazilian Portuguese female voice for Mbrola This package contains a Brazilian Portuguese diphone database provided in the context of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/ . It provides a Brazilian Portuguese female voice to be used with the MBROLA program. Subject: ITP: mbrola-de1 -- German female voice for Mbrola Package: wnpp Version: N/A; reported 2016-09-11 Severity: wishlist Owner: Samuel Thibault * Package name: mbrola-de1 Version : 2.050 Upstream Author : Faculte Polytechnique de Mons - mbrola team * URL : http://tcts.fpms.ac.be/synthesis * License : see the file readme.txt in the source zip: non-free as in without source code, and for non-commercial, non-military purposes, with and only with the mbrola package made available by the author. Description : German female voice for Mbrola This package contains a German diphone database provided in the context of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/ . It provides a German female voice to be used with the MBROLA program. Subject: ITP: mbrola-de2 -- German male voice for Mbrola Package: wnpp Version: N/A; reported 2016-09-11 Severity: wishlist Owner: Samuel Thibault * Package name: mbrola-de2 Version : 0.0.19990106 Upstream Author : Faculte Polytechnique de Mons - mbrola team * URL : http://tcts.fpms.ac.be/synthesis * License : see the file readme.txt in the source zip: non-free as in without source code, and for non-commercial, non-military purposes, with and only with the mbrola package made available by the author. Description : German male voice for Mbrola This package contains a German diphone database provided in the context of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/ . It provides a German male voice to be used with the MBROLA program. Subject: ITP: mbrola-de3 -- German female voice for Mbrola Package: wnpp Version: N/A; reported 2016-09-11 Severity: wishlist Owner: Samuel Thibault * Package name: mbrola-de3 Version : 1.0 Upstream Author : Faculte Polytechnique de Mons - mbrola team * URL : http://tcts.fpms.ac.be/synthesis * License : see the file readme.txt in the source zip: non-free as in without source code, and for non-commercial, non-military purposes, with and only with the mbrola package made available by the author. Description : German female voice for Mbrola This package contains a German diphone database provided in the context of the MBROLA pro
Bug#837464: ITP: globjects -- cross-platform C++ wrapper for OpenGL API objects
Package: wnpp Severity: wishlist Owner: Ghislain Antony Vaillant * Package name: globjects Version : 1.0.0 Upstream Author : CG Internals * URL : http://globjects.org/ * License : Expat Programming Lang: C++ Description : cross-platform C++ wrapper for OpenGL API objects Long-Description: globjects provides object-oriented interfaces to the OpenGL API (3.0 and higher). The main goals are much reduced code to use OpenGL in your rendering software and fewer errors due to the underlying glbinding and further abstraction levels on top. Typical processes are automated and missing features in the used OpenGL driver are partially simulated or even emulated. This package will be co-maintained by the Debian Science Team alongside glbinding which it depends on.
Bug#837471: ITP: willow -- Python image library combining Pillow, Wand and OpenCV
Package: wnpp Severity: wishlist Owner: Christopher Hoskin * Package name: willow Version : 0.3.1 Upstream Author : Torchbox * URL : https://github.com/torchbox/Willow * License : BSD-3-clause Programming Lang: Python Description : Python image library combining Pillow, Wand and OpenCV Willow is a simple image library that combines the APIs of Pillow, Wand and OpenCV. It converts the image between the libraries when necessary. Willow currently has basic resize and crop operations, face and feature detection and animated GIF support. New operations and library integrations can also be easily implemented. This package will be maintained within the Python Modules Team. I will need a sponsor. OpenCV support for Python 3 is not yet avaliable in Debian. Therefore this module will be packaged for Python 2 initially.
Re: PIE and static libraries
Hi All, 2016-05-22 11:26 GMT+02:00 Christian Seiler : > On 05/22/2016 10:50 AM, Andrey Rahmatullin wrote: >> On Sun, May 22, 2016 at 10:41:56AM +0200, Christian Seiler wrote: ... > >>> B. From a performance perspective, using non-PIC/PIE code is >>>faster, though not necessarily by much anymore. >> It was worth mentioning only for i386 anyway. > > Well, there's not only amd64 and i386 - and some other platforms > also show some differences here. But as I said: I would recommend > to use PIE/PIC anyway. I have opened a bug to encourage PIC for static libraries in Policy, too.: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837478 Cheers, Balint
Re: lirc and new upstream release, can we update?
On Sep 11, Gianfranco Costamagna wrote: > 2) would it be possible to create a lirc-ng package and > conflict with the current one, so people can choose the best one for > them? No. > 3) NMU in unstable seems unfair and possibly a source of troubles for > such a complex package (with complex changes). The current lirc package has obviously been neglected for a very long time and this is shameful. I recommend that you notify to the current maintainer your intent to take over the package, wait for two weeks and then do it. -- ciao, Marco signature.asc Description: PGP signature
Bug#837511: ITP: golang-github-googleapis-proto-client-go -- Generated proto and gRPC classes for Google cloud platform
Package: wnpp Severity: wishlist Owner: Tim Potter X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org * Package name: golang-github-googleapis-proto-client-go Version : 0.0~git20160726.0.e5790fe-1 Upstream Author : Google APIs * URL : https://github.com/googleapis/proto-client-go * License : BSD-3-clause Programming Lang: Go Description : Generated proto and gRPC classes for Google cloud platform This repository contains the Go classes generated from protos contained in Google APIs (https://github.com/googleapis/googleapis/). signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#837517: ITP: elpa-fill-column-indicator -- graphically indicate the fill column
Package: wnpp Severity: wishlist Owner: Lev Lamberov * Package name: elpa-fill-column-indicator Version : 1.87 Upstream Author : Alp Aker * URL : https://github.com/alpaker/Fill-Column-Indicator * License : GPL-2+ Programming Lang: Emacs Lisp Description : graphically indicate the fill column Many modern editors and IDEs can graphically indicate the location of the fill column by drawing a thin line (in design parlance, a `rule') down the length of the editing window. Fill-column-indicator implements this facility in Emacs.
Re: PIE and static libraries
On 09/12/2016 01:47 AM, Bálint Réczey wrote: > I have opened a bug to encourage PIC for static libraries in Policy, too.: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837478 Thanks, cool. Is there any specific reason for not mentioning -fPIE in that request? That seems like a good middle-ground for static libraries. Reading up on the subject so far, I got the impression that most static libraries should be built with PIE, but not necessarily PIC (to allow building PIE(xecutable)s, but discourage creating shared libraries from those static ones.) To be honest, I didn't really check any use-case other than libsimgear-dev, which I'm concerned about. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
