Bug#980839: rnnoise model training data

On Mon, 01 Feb 2021 16:19:03 +0800 Paul Wise wrote: > It has been made clear in this Hacker News subthread that the > RNNoisem odel has been trained in part using proprietary data: This is correct. There's been some discussion about this on IRC with respect to that thread and the Debian Machine

Bug#954189: Upload approval for acmetool 0.2 in buster-backports

As an update on this, I've gotten acmetool 0.2 to build on buster. The following packages need backporting: - golang-github-gofrs-uuid - golang-golang-x-xerrors - golang-github-google-go-cmp - golang-gopkg-square-go-jose.v2 - golang-gopkg-hlandau-acmeapi.v2 - acmetool The 5 golang-* packages are

Bug#954189: Upload approval for acmetool 0.2 in buster-backports

On Sun, 2020-08-09 at 20:22 -0400, Peter Colberg wrote: > Please feel free to go ahead with backporting acmetool and needed > golang dependencies to buster. Thanks for the approval, Peter! We'll backport and follow-up with the go-team if there are issues. Cheers, Ralph signature.asc

Bug#954189: Upload approval for acmetool 0.2 in buster-backports

Hi, I wanted to request approval from the maintainer team to upload the acmetool 0.2.1-2 package currently in testing/unstable to buster- backports. The version currently in buster (0.0.63) only supports the deprecated ACME v1 protocol, which no longer works for new registrations, and will stop

Bug#954189: Backport to buster?

Please backport the 0.2.1 package from bullseye to buster. The 0.0.62 package currently in buster no longer works for new installs, and will stop working for renewals of current domain certificates in July 2020. The 0.2.1 tag of acmetool is two years old and should build with the golang 1.11

Bug#881788: patch is upstream

Just wanted to note that this patch has been merged upstream and should be part of the 0.12 release. https://gitlab.xiph.org/xiph/opusfile/-/commit/49578c103ac59e00538a73311a479c5456922016 -r

Bug#923940: [libtheoraenc] What resolution were you looking for?

On Wed, 2020-04-15 at 13:34 +0800, Paul Wise wrote: > Generally one should only link a program with libraries that provide > symbols that are directly used by the program. Ok, good to hear transitive linking can be assumed to work these days! > If libtheoraenc uses some functions from

Bug#923940: [libtheoraenc] What resolution were you looking for?

Paul, Looking at this bug, I don't understand what exactly you're reporting. libtheoraenc does depend on libtheoradec, so applications need to link to both. This is declared in the pkg-config file: $ pkg-config --libs theoraenc -ltheoraenc -ltheoradec -logg Is the issue that this

Bug#955208: rustc: rustup is not available on Debian

I would also like to start off with a Debian-packaged rustup rather than having to install it from upstream. It's been discussed before, but I think no one was pursuaded to start maintaining a package. IIRC one issue was that rustup likes to update itself. You'd need to check how difficult it

Bug#948708: Further information

On Wed, 15 Jan 2020 19:02:47 + Nick Thomas wrote: > Attached is the output of bt from gdb with debug symbols loaded, and > disassemble too. Looks like it's just going into NULL memory? Illegal instruction in a smart pointer dereference sounds like basic mis-compilation. > Should this go

Bug#880689: [Pkg-rust-maintainers] Bug#880689: dh-cargo: installs too much for libpkg

On 2017-11-04 11:13 AM, Jonas Smedegaard wrote: You snipped the parted clarifying that the .pc came not from upstream but was created during my Debian package build: The ".pc" directory, created during build by a packaging helper tool, should certainly not be installed. Oops, I see that

Bug#880689: [Pkg-rust-maintainers] Bug#880689: dh-cargo: installs too much for libpkg

On 2017-11-04 3:51 AM, Jonas Smedegaard wrote: I believe that from your own rule, stuff generated during build by upstream build tools - typically but not necessarily listed in upstream .gitignore - should hot be installed either. Unfortunately, `cargo package` includes everything in the

Bug#842634: [Pkg-rust-maintainers] Bug#842634: rustc: FTBFS (sys_common::net::tests::no_lookup_host_duplicates fails)

On 2016-11-29 1:17 AM, Santiago Vila wrote: > I wonder, however, why two lines like this in /etc/hosts > > 127.0.0.1 localhost > 127.0.0.1 localhost ip6-localhost ip6-loopback > > should make rustc build to fail at all. The test was added in

Bug#821321: libvorbisfile: ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes

On 2016-04-18 7:31 AM, Martin Steghöfer wrote: > Judging from the code that reproduces the bug (two subsequent seeks to > 0) and from the related vorbis code you are mentioning, this sounds a > lot like #782831, which was fixed in 1.3.4-3. Could you confirm or > refute that theory by testing your

Bug#812692: Add pulseaudio dependency to iceweasel

Package: iceweasel Version: 43.0.4-1 We (upstream) are considering dropping support for audio back ends outside pulseaudio. We've had an increasing number of bugs to do with the plain alsa and oss backends, e.g. with output device choice and complex configurations. It is better to require a

Bug#786836: [Pkg-rust-maintainers] Bug#786836: packaging not yet ready for mass/stable usage

On 2015-12-10 12:19 PM, Luca Bruno wrote: > We had an informal discussion on IRC a bunch of days ago, and we > now feel confident enough to let rustc+cargo into testing. rustc > 1.5.0 has been tagged today, and together with cargo 0.6.0 we plan > to let them migrate to testing. Thanks Luca

Bug#786836: packaging not yet ready for mass/stable usage

On Tue, 26 May 2015 00:15:50 +0200 Luca Bruno wrote: > Even though Rust recently reached the 1.0 milestone, compiler and > ecosystem packaging still has to reach a "ready for the masses" > status. What needs to happen to resolve this bug? We're starting to use rust code in

Bug#786836: [Pkg-rust-maintainers] Bug#786836: packaging not yet ready for mass/stable usage

On 2015-12-10 10:58 AM, Sylvestre Ledru wrote: > I will be at the meeting [1] in 30 minutes :p , we can discuss about > that if you want :) I'll be there too, but there may not be time after gecko requirements for rust and rust requirements for the gecko build system and... But we should talk

Bug#798960: libvorbis: Please upgrade to 1.3.5

On 2015-09-23 3:30 AM, Martin Steghöfer wrote: > I can take care of forwarding them now. Thanks, Martin! -r

Bug#798960: libvorbis: Please upgrade to 1.3.5

On 2015-09-22 2:37 AM, Petter Reinholdtsen wrote: > But the CHANGES file in the tarball claim the version is unreleased. > Is it the wrong tarball, or did someone forget to update the CHANGES > file before release? There's a mistake in the release tarball. I forgot to change the date before

Bug#790442: FTBFS with new LaTeX: Unknown float option `H'.

On Mon, 29 Jun 2015 11:32:43 -0400 Martin Michlmayr t...@hp.com wrote: You're using the H float option. According to https://en.wikibooks.org/wiki/LaTeX/Floats,_Figures_and_Captions you need \usepackage{float} for that, but it seems simpler solution is to replace it with !h. Thanks for the

Bug#431023: Segfaults in aspell when no word is selected

Package: bluefish Version: 1.0.7-1 Steps to reproduce: 1. launch application 2. close tip window 3. Select Document:Check Spelling... from the menu 4. click the Add button in the Check Spelling window 5. segfault Also filed upstream as http://bugzilla.gnome.org/show_bug.cgi?id=444992 which

Bug#431023: [PATCH] suggested fix for the segfaults

Here's the actual patch for reference. Applying this would close the bug. -r diff -ur bluefish-1.0.7/src/bfspell.c bluefish-1.0.7-g1/src/bfspell.c --- bluefish-1.0.7/src/bfspell.c 2005-11-24 10:18:01.0 -0800 +++ bluefish-1.0.7-g1/src/bfspell.c 2007-06-06 22:07:36.0 -0700 @@

Bug#383793: [theora-dev] Bug#383793: libtheora0: not 64-bit clean

This has been committed now. -r On Sat, Aug 19, 2006 at 05:06:23PM +0200, Peter De Wachter wrote: Package: libtheora0 Version: 0.0.0.alpha7-1 Severity: important Tags: patch The theora_unpack_comment casts a pointer-to-int to a pointer-to-long, which breaks badly if ints and longs are

Bug#323252: acknowledged by developer (Re: Bug#323252: automake 1.9 warning fix)

On Tue, Aug 16, 2005 at 06:18:10PM -0700, Debian Bug Tracking System wrote: Ralph Giles wrote: Package: aalib Version: 1.4p5 Please include full version numbers in bug reports, including the debian revision. Oops. I was actually working backward from Ubuntu 5.04 and hadn't checked

Bug#287339: Whacky

I'm not sure this is a good idea. Even if one is using autoconf, the value of libdir comes from the user, or a default like /usr/local/lib In short, I think a better policy is to follow the one from libdir itself; it's a user config option, /usr/local/lib is a good default, and it's up to the

Bug#323252: automake 1.9 warning fix

Package: aalib Version: 1.4p5 Automake 1.9 warns about insufficient quoting on aalib.m4. The attached trivial patch silences the warning, cleaning up everyone's ./autogen.sh. -r --- aalib.m4- 2005-08-15 11:12:09.713552488 -0700 +++ aalib.m42005-08-15 11:12:29.079608400 -0700 @@ -9,7

Bug#321169: default ssl certificate expires once a year

Package: ipopd Version: 7:2002edebian1-11 The post-install script by default generates a self-signed ssl certificate, which is great, but it expires after a year, causing some mail clients to begin warning. This sudden change makes for a poor user experience for both clients and the

Bug#302295: python should use the alternatives mechanism

On Sun, Apr 03, 2005 at 08:54:58PM +0200, Matthias Klose wrote: no, because you cannot assure, that all modules installed in one version are installed on the other version as well. So because debian packages don't track python module dependencies correctly, incorrect. if there's

Bug#302295: python should use the alternatives mechanism

On Sun, Apr 03, 2005 at 09:21:55PM +0200, Matthias Klose wrote: consider Package: baz Depends: python2.2 | python2.3, python2.2-foo | python2.3-foo, python2.2-bar | python2.3-bar the dependencies are fullfilled installing python2.2-foo and python2.3-bar... So how does package baz

Bug#302295: python should use the alternatives mechanism

Package: python Version: 2.3.5-1 Debian provides parallel installable versions of python as, e.g. python (which depends on python2.3) and python2.4. However, the default /usr/bin/python executable is a symlink to python2.3 owned (I think?) by the python package itself. Thus, the only way to

Bug#271427: Debian bug #271427

On Tue, Jan 25, 2005 at 12:59:59AM +, Dafydd Harries wrote: Ok, I'd be happier if I knew of some ways I could perform QA on the modifications which I make. How would I go about checking the metrics? Use Fontforge to generate .afm files for the new fonts, then compare them with the

Bug#288876: [Flac-dev] liboggflac1 soname

On Mon, Jan 24, 2005 at 05:43:04PM -0800, Josh Coalson wrote: because of the mess and since there have been API changes and additions in both libFLAC and libOggFLAC since 1.1.1 I plan on bumping all the libtool numbers as follows: current++, revision=0 age=0. if this will cause problems

Bug#271427: Debian bug #271427

Your summary is more or less accurate. We've never had much success coordinating with fillippov. I don't know if it's a language barrier, lack of interest, or what. Fontforge is the preferred editing tool for these fonts and the solution is as you suggest. In addition, after the new fontset is

Bug#288393: buggy splash

Hmm. The may or may not be unrelated, but I've also noticed since the 2.8 upgrade that the splash screen stays up for A LONG TIME (minutes) after the desktop has apparently finished loading. I always have to click it away. This could be causing some of the complaints as well, as it's still

Bug#288876: [Flac-dev] liboggflac1 soname

On Mon, Jan 10, 2005 at 09:37:18PM -0800, Josh Coalson wrote: as far as I can piece together, the last releases went like: FLAC release libOggFLAC went to - -- 1.1.0 1:2:0 from 1:1:0 (code changes only I think) 1.1.1-beta1