Bug#915591: ITP: qmath3d -- Useful 3dmaths functions from Qt3d v1.0

2018-12-04 Thread Wookey
Package: wnpp Severity: wishlist Owner: Wookey * Package name: qmath3d Version : 1.0 Upstream Author : Digia/Philip Schuchardt * URL : https://github.com/vpicaver/QMath3d * License : GPL or LGPL Programming Lang: C++ Description : Useful 3dmaths functio

Bug#915579: ITP: xdg-dbus-proxy -- filtering D-Bus proxy

2018-12-04 Thread Simon McVittie
Package: wnpp Severity: wishlist Owner: Simon McVittie * Package name: xdg-dbus-proxy Version : 0.1.0 Upstream Author : Alexander Larsson * URL : https://github.com/flatpak/xdg-dbus-proxy * License : LGPL-2.1+ Programming Lang: C with GLib Description :

Re: call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)

2018-12-04 Thread Simon McVittie
On Tue, 04 Dec 2018 at 23:22:19 +0100, Adam Borowski wrote: > On Tue, Dec 04, 2018 at 10:49:44PM +0100, IOhannes m zmölnig (Debian/GNU) > wrote: > > i asked upstream, and their answer is: > > > The version was always 1.00 even when it was inside Csound. Minor > > > changes made it go to 1.01 when

Re: call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)

2018-12-04 Thread Adam Borowski
On Tue, Dec 04, 2018 at 10:49:44PM +0100, IOhannes m zmölnig (Debian/GNU) wrote: > On 12/4/18 9:34 PM, Simon McVittie wrote: > > If they agree that this is confusing, they might be willing to re-version > > to 7.01.0 or something, so that version numbers keep going up. > > > > If they are unwillin

Bug#915567: ITP: fcitx5 -- Next generation of Fcitx Input Method Framework

2018-12-04 Thread Boyuan Yang
Package: wnpp Severity: wishlist Owner: Boyuan Yang X-Debbugs-CC: debian-devel@lists.debian.org * Package name: fcitx5 Version : 0~20181128 Upstream Author : Weng Xuetian * URL : https://gitlab.com/fcitx/fcitx5 * License : LGPL-2.1+ Programming Lang: C++ D

Re: call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)

2018-12-04 Thread Debian/GNU
On 12/4/18 9:34 PM, Simon McVittie wrote: > > I would suggest talking to the upstream developer of pd-csound. It seems > reasonably likely that their users will be confused by the fact that > that version 1.01.0 of the "Csound external" (I assume that's some sort > of loadable module, analogous to

Re: call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)

2018-12-04 Thread Simon McVittie
On Tue, 04 Dec 2018 at 20:03:27 +0100, IOhannes m zmölnig (Debian/GNU) wrote: > On 04.12.18 19:28, IOhannes m zmoelnig wrote: > > Package: wnpp > > * Package name: pd-csound > > Version : 1.01.0 > > > > pd-csound used to be built from the csound (source) package, but upstream > > has

call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)

2018-12-04 Thread Debian/GNU
On 04.12.18 19:28, IOhannes m zmoelnig wrote: > Package: wnpp > * Package name: pd-csound > Version : 1.01.0 > > pd-csound used to be built from the csound (source) package, but upstream has > factored it out into a separate project (starting with fresh version numbers). > This is an

Bug#915553: ITP: pd-csound -- Csound external for Pure Data

2018-12-04 Thread IOhannes m zmoelnig
Package: wnpp Severity: wishlist Owner: IOhannes m zmoelnig * Package name: pd-csound Version : 1.01.0 Upstream Author : Victor Lazzarini et al. * URL : https://csound.com * License : LGPL Programming Lang: C Description : Csound external for Pure Data

Re: Sending using my @debian.org in gmail

2018-12-04 Thread Marc Haber
On Mon, 3 Dec 2018 16:00:36 +0100, Bernhard Schmidt wrote: >Am 30.11.18 um 20:05 schrieb Marc Haber: >> If I could vote for which idea Debian mail admin time is dedicated >> (which I cannot since Debian admins are volunteers and can choose what >> to work on), I'd vote for better spam filtering on

Re: Tainted builds (was Re: usrmerge -- plan B?)

2018-12-04 Thread Holger Levsen
On Tue, Dec 04, 2018 at 01:07:42AM +0100, Guillem Jover wrote: > These will detect problematic files under /usr/local which can taint > the current build. [...] > +.B usr\-local\-has\-programs I regularily have stuff in /usr/local/(s)bin/ which does not taint the system nor my builds, so I think y

Re: usrmerge -- plan B?

2018-12-04 Thread Marco d'Itri
On Dec 04, Russ Allbery wrote: > Does this imply that you're considering adding support for merging /usr > *properly* directly inside dpkg, with all the correct updates to dpkg's > metadata? > > Because that would be an awesome way to fully support this. It would make using dpkg -S a bit easier