Bug#1060397: libsys-syscall-perl: FTBFS on riscv64: t/01-epoll.t failure

Eric Wong wrote: > Attached patch adds support for riscv64 and loongarch64 tested loongarch64 on cfarm400 tested aarch64 on cfarm103 (so no regression) > I can't access loongarch64 machines on cfarm atm I forgot 400/401 are on a nonstandard port :x

Bug#1060397: libsys-syscall-perl: FTBFS on riscv64: t/01-epoll.t failure

00:00:00 2001 From: Eric Wong Date: Wed, 10 Jan 2024 19:28:48 + Subject: [PATCH] add loongarch64 and riscv64 support riscv64 tested on cfarm92.cfarm.net I can't access cfarm40[01] right now, but I tested the epoll_* syscall numbers a while ago for another project (not readahead nor sendf

Bug#1057749: spamc --headers corrupts body with NUL char in body

Package: spamc Version: 3.4.6-1 Severity: normal Tags: upstream Dear Maintainer, I'm able to reproduce this bug on 4.0.0-8 on a sid machine, too. My use of `spamc -E --headers' causes body corruption if a NUL ('\0') character appears in the body when talking to spamd. The bug appears to be in

Bug#1054120: perl: open EMFILE failure misreported

Package: perl Version: 5.36.0-9 Severity: normal Tags: upstream The `open' perlop fails to report EMFILE (Too many open files) when it fails due to having too many open files. strace confirms the underlying open(2) syscall does fail with EMFILE, but Perl misreports `$!' as EINVAL (Invalid

Bug#1040947: perl: readline fails to detect updated file

Niko Tyni wrote: > On Tue, Jul 18, 2023 at 01:23:51AM +0000, Eric Wong wrote: > > > At this point (given Perl's maturity); it's less surprising if > > it kept it's lack of error detection in all cases. > > Thanks for caring, but please take your arguments upstream.

Bug#1040947: perl: readline fails to detect updated file

rehensively, so I will comment on some of the details in your > message. With each iteration of the loop in my example, the file size increases as shown by `-s', yet readline isn't returning any data after it sees a transient EOF. > Eric Wong writes ("Re: Bug#1040947: perl: readline fails to detect

Bug#1040947: perl: readline fails to detect updated file

Niko Tyni wrote: > On Sun, Jul 16, 2023 at 11:35:49AM +0300, Niko Tyni wrote: > > Control: forwarded -1 https://github.com/Perl/perl5/issues/21240 > > > > On Wed, Jul 12, 2023 at 09:17:54PM +, Eric Wong wrote: > > > Package: perl > > > Version: 5.3

Bug#1040947: perl: readline fails to detect updated file

Package: perl Version: 5.36.0-7 Severity: normal Tags: upstream Dear Maintainer, The `readline' op (`') no longer detects updates to file which is being written to in Perl 5.36.0 after updating to bookworm. The attached script worked fine with Perl 5.32.1 in oldstable, both scripts show the

Bug#1030689: ruby-upr: blocking ruby-moneta migration

Abhijith PA wrote: > Package: ruby-upr > Version: 0.3.0-3 > Severity: serious > User: debian-r...@lists.debian.org > Usertags: ruby-sprint-2023 > > > Hi, > > ruby-upr is dead upstream (last commit in 2013[1]). It have no > reverse-dependencies and blocking the migration ruby-moneta (1.0.0-9 >

Bug#1018696: w3m: can't be used as target

Package: w3m Version: 0.5.3+git20210102-6 Severity: normal Tags: upstream This fails in commit c515ea8a47b62408 (Update ChangeLog, 2022-04-29), too. Using to link to a dfn says "foo not found" foo bar Replacing dfn with div works, however. `id'is a global attribute should

Bug#1002219: [PATCH] t/eml.t: ignore newer Email::MIME behavior

Uwe Kleine-König wrote: > Hello, > > adding the Debian Perl Group to Cc, maybe they can help here. > (for context look at https://bugs.debian.org/1002219) > > On 12/30/21 10:12, Uwe Kleine-König wrote: > > I got a bug report against the public-inbox 1.6.1 package about a > > failing test, see

Bug#996362: ruby-raindrops: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed.

Antonio Terceiro wrote: > Source: ruby-raindrops > Version: 0.19.0-2 > > === > > Error: test_unix(TestLinux): TypeError: no implicit conversion of Hash into > > Integer > >

Bug#995804: closed by Debian FTP Masters (reply to Yadd ) (Bug#995804: fixed in libencode-perl 3.15-1)

Thanks for the upload. What is the plan to get this leak fixed for bullseye and buster users? Thanks again.

Bug#995804: Acknowledgement (libencode-perl: Encode <3.12 leaks)

Note: Encode 3.15 has more comprehensive leak fix (it leaks on encoding, too, not just decoding). Avoid 3.14, it segfaults and made 3.15 necessary. cf. http://nntp.perl.org/group/perl.perl5.porters/261689 <9fb18b82-1fa8-4e33-b7f2-507e9b35c...@dan.co.jp> Thanks.

Bug#995738: Acknowledgement (perl: leak fixes for buster (perl 5.28.1))

Note: Encode 3.15 contains a better fix which encompasses encoding, too. Encode 3.14 was broken (segfaults). Please consider providing Encode 3.15, thanks.

Bug#995804: libencode-perl: Encode <3.12 leaks

Package: libencode-perl Version: Encode <=3.12 leaks on decode, 3.13 released Severity: normal Tags: upstream patch Dear Maintainer, Encode 3.13 was just released with a memory leak fix for: https://rt.cpan.org/Ticket/Display.html?id=139622 Since Encode is also bunded with various libperl5.xx

Bug#995738: perl: leak fixes for buster (perl 5.28.1)

Package: perl Version: 5.28.1-6+deb10u1 Severity: normal Tags: upstream patch There are at least two regexp leaks affecting buster/oldstable that affect codebases I'm maintaining. They're fixed upstream and in current stable/testing/unstable; but I expect there to be many users still using

Bug#993860: public-inbox-imapd: missing dependency libparse-recdescent-perl

Nicolas Schier wrote: > Installing libparse-recdescent-perl was enough on my system to solve the > issue. Perhaps you might want to add it as dependency? Uwe: Fwiw, perhaps making more things optional via Suggests:/Recommends: and possibly splitting into several packages (e.g.

Bug#983419: liburi-perl: URI nntps support

Package: liburi-perl Version: 1.76-1 Severity: wishlist Tags: upstream While URI::snews exists for NNTP over TLS, "nntps" is the IANA-registered name: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=nntps Also, "nntps" (not "snews") is present

Bug#975607: libgit2-28: relative paths in alternates mishandled when nested

Package: libgit2-28 Version: 0.28.3+dfsg.1-1~bpo10+1 Severity: normal Tags: upstream Dear Maintainer, I've noticed libgit2 fails to handle relative paths for alternates properly when a relative path is nested from within another alternate. Regular git(1) works fine (as shown in the attached

Bug#964736: ITP: public-inbox -- Mailing list archiver

Uwe Kleine-König wrote: > Package: wnpp > Severity: wishlist > Owner: Uwe Kleine-König > > * Package name: public-inbox > Version : 1.5.0 > Upstream Author : Eric Wong and others > * URL : https://www.public-inbox.org/ > * License

Bug#961713: python-imaplib2: times out when compression is enabled

Package: python-imaplib2 Version: 2.57-5 Severity: normal Tags: upstream I noticed this from trying "usecompression = yes" in offlineimap. When fetching large messages over IMAP, it's possible to completely drain the system socket, but still have leftover data in userspace that the high-level

Bug#944887: libemail-mime-perl: fails to handle boundary="0"

ot;_" / "," / "-" / "." / "/" / ":" / "=" / "?" >From 72e288ff88a191976be339929bed1d2c9c6d1b7a Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Sun, 17 Nov 2019 08:57:49 + Subject: [PATCH] Email::MIME: allow "0" as bo

Bug#929857: libkqueue0: fails to emulate close-on-fork or close-on-exec behavior of native kqueue

Package: libkqueue0 Version: 2.0.3-1.1 Severity: normal Tags: upstream Native kqueue (tested on FreeBSD 11.2) has close-on-fork and close-on-exec behavior. libkqueue should follow it. Close-on-exec is easy to do on epoll via epoll_create1 (or fcntl on Linux <2.6.27) Close-on-fork will require

Bug#928679: rinse: please update for Fedora 30

Package: rinse Version: 3.4 Severity: wishlist I tried updating things myself by symlinking the existing post-install.sh and copying the package list from fedora-28, but it failed during the post-install. Anyways, this is the error I hit when I tried to update to Fedora 30 myself: Running

Bug#927409: [PATCH] render entity

is supported in XHTML and HTML5, so at least render it properly when seen in HTML we encounter. We don't start escaping "'", yet; but if we do, I suggest using to ensure compatibility with older w3m versions. >From b557289dd4309b37a2d9710fa92c3d269ef67228 Mon Sep 17 00:00:00 20

Bug#927822: libhighlight-perl: provide API to map shebangs and extensions to language

David Bremner wrote: > Eric Wong writes: > > > It would be nice if the highlight API provided a way to reliably > > map filename extensions and shebangs to the language I'm > > highlighting. I'm currently parsing the filetypes.conf directly > > and it's a bit

Bug#927822: libhighlight-perl: provide API to map shebangs and extensions to language

Package: libhighlight-perl Version: 3.41-2+b1 Severity: wishlist Tags: upstream It would be nice if the highlight API provided a way to reliably map filename extensions and shebangs to the language I'm highlighting. I'm currently parsing the filetypes.conf directly and it's a bit fragile:

Bug#927409: w3m: entity support needs to be added

Package: w3m Version: 0.5.3-37 Severity: normal Tags: upstream is supported in XHTML and HTML 5.0 and does not render properly with w3m https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references

Bug#927410: highlight: character entity not compatible with older HTML

Package: highlight Version: 3.41-2+b1 Severity: normal Tags: upstream highlight 3.41 uses "" for HTML output which only appears in HTML 5.0 and XHTML. This causes problems with older browsers such as w3m which haven't been updated, yet (separate bug report just filed). I suggest using the ""

Bug#927271: grokmirror: new upstream version available

Package: grokmirror Version: 1.0.0-1.1 Severity: wishlist Upstream is up to 1.2.1 at the moment, Python 3 compatibility appeared in 1.1.0

Bug#918916: Unicorn not reporting proper version for gemfile?

(unicorn upstream here, adding unicorn-public to Cc, for context: ) Dominik George wrote: > +--- a/unicorn.gemspec > b/unicorn.gemspec > +@@ -11,7 +11,7 @@ end.compact > + > + Gem::Specification.new do |s| > + s.name = %q{unicorn} > +- s.version =

Bug#917775: RFP: xrandr-invert-colors -- xrandr-invert-colors

Package: wnpp Severity: wishlist * Package name: xrandr-invert-colors Version : git Upstream Author : Zoltan Padrah * URL : https://github.com/zoltanp/xrandr-invert-colors * License : GPL-3.0+ Programming Lang: C Description : invert colors on all

Bug#917774: RFP: rubygems-roda -- routing tree web toolkit for Ruby

Package: wnpp Severity: wishlist * Package name: rubygems-roda Version : 3.15.0 Upstream Author : Jeremy Evans * URL : http://roda.jeremyevans.net/ * License : MIT Programming Lang: Ruby Description : routing tree web toolkit for Ruby Roda is a routing

Bug#916189: xapian-bindings: please package Lua bindings

Source: xapian-bindings Version: please package Lua bindings Severity: wishlist Dear Maintainer, I noticed Lua bindings are provided with Xapian upstream; but there's no Debian package for it. I'm not a Lua programmer, yet, but the availability of Xapian bindings would influence my choice to

Bug#840388: fusedav non-functional

Carsten Leonhardt wrote: > Control: severity -1 grave > > This software appears to be non-functional. A tcpdump confirms that no > network traffic between the client and the server is being generated. Fwiw, I have filed many bugfixes against this package years ago but the maintainer is not

Bug#840388: fusedav non-functional

Eric Wong wrote: > AFAIK, there was one unresolved corner-case with readdirplus > support I never got around to fixing[1], but it works for common > cases with "ls" [1] Sorry, correct URL is: https://marc.info/?i=CAJfpeguWVhpPkUoTxGrW=kc43rrksjtwoq0ysczl0_oc9jl...@mail.gma

Bug#902193: mutt: [PATCH] imap/message: fix segfault from uninitialized progress bar

ecode\n|(umask 0022 && git am -3)\n:set pipe_decode\n" This problem only affects 1.7.2-1 in Debian stretch, mutt 1.10.0 handles the problem differently. >From 203648db06effe40d826cbf07f637c02a766ad8d Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Thu, 21 Jun 2018 21:51:11 +

Bug#894997: [PATCH] git-svn: avoid warning on undef readline()

Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Fri, Apr 06 2018, Eric Wong wrote: > > Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > > > >> --- a/perl/Git.pm > >> +++ b/perl/Git.pm > >> @@ -554,7 +554,7 @@ sub get_record { > >

Bug#894997: [PATCH] git-svn: avoid warning on undef readline()

Ævar Arnfjörð Bjarmason wrote: > See https://public-inbox.org/git/86h8oobl36@phe.ftfl.ca/ for the > original report. Thanks for taking a look at this. Also https://bugs.debian.org/894997 > --- a/perl/Git.pm > +++ b/perl/Git.pm > @@ -554,7 +554,7 @@ sub get_record { >

Bug#888791: libsvn-perl: likely some reference counting bug around SVN::Client/SVN::Ra

Package: libsvn-perl Version: 1.9.5-1+deb9u1 Severity: normal Tags: upstream git developers have encountered a weird crash with git-svn which uses libsvn-perl. My patch (in the thread below) to undef the SVN::Client instance before creating SVN::Ra instances seems to solve the problem; so I

Bug#881121: sox: null pointer dereference while running sox

Joonun Jang wrote: > Package: sox > Version: 14.4.1-5+b2 > Severity: normal > Tags: security > > null pointer dereference while running sox with "poc.aiff output.aiff speed > 1.027" option > > Running 'sox poc.aiff output.aiff speed 1.027' with the attached file raises

Bug#881145: [PATCH] wavpack: check errors when initializing

project; either... Will also try to look at https://bugs.debian.org/881121 soon (maybe Måns can help). ---8<- From: Eric Wong <e...@80x24.org> Subject: [PATCH] wavpack: check errors when initializing Avoid NULL dereference when opening an WavPack input file fails as

Bug#865595: spamassassin install problem in Debian 9

Marcelo Gondim wrote: > Em 23/06/2017 02:07, Noah Meyerhans escreveu: > >On Thu, Jun 22, 2017 at 11:50:35PM -0300, Marcelo Gondim wrote: > >>Configurando spamassassin (3.4.1-6) ... > >>-su: 53: Syntax error: "(" unexpected (expecting "}") > >>dpkg: erro ao

Bug#849843: libyaml-libyaml-perl: [PATCH] lazy load B::Deparse for big speedup

g to host an open-to-all bug tracker :) >From 8c51950fa3796346542ca01ee04659edaaf81cc3 Mon Sep 17 00:00:00 2001 From: Eric Wong <e...@80x24.org> Date: Sun, 1 Jan 2017 08:05:59 + Subject: [PATCH] load B::Deparse lazily This speeds up startup time dramatically and is noticeable with smal

Bug#839807: unicorn: Missing depends on lsb-base

(upstream here) Fwiw, I prefer to make the init script itself optional; especially since unicorn 5.x supports systemd and does not need an init script. I prefer fewer required dependencies (suggests/recommends) can be fine. Santiago Vila wrote: > Forgot the (trivial) patch.

Bug#734005: error: git-svn died of signal 11 (at least doing git svn fetch/rebase)

Jason Briggs wrote: > [ 1463.669888] git-svn[3270]: segfault at 7fab78a3a178 ip 7fab7f80da31 sp > 7ffc8c6d7280 error 6 in _Delta.so[7fab7f7fa000+2a000] > [ 2701.760387] git-svn[29940]: segfault at 7fa6f896d370 ip 7fa6ff5a1a31 > sp 7fff96961620 error

Bug#833479: libmail-thread-perl: [PATCH] avoid recursion warnings in recurse_down

avoid crashes). ref: https://rt.cpan.org/Ticket/Display.html?id=116727 From: Eric Wong <e...@80x24.org> Subject: [PATCH] avoid recursion warnings in recurse_down There is no need to actually perform recursion when traversing messages to perform callbacks on them. This quiets down rec

Bug#780246: [libsvn-perl] Is there any progress on this?

I only recently subscribed to this tracker, but this looks like the same problem documented a few weeks ago on the git list: https://public-inbox.org/git/0bca1e695085c645b9cd4a27dd59f6fa39aad...@gbwgceuhubd0101.rbsres07.net/T/

Bug#830353: ruby-kgio: FTBFS: ERROR: Test "ruby2.3" failed.

Antonio Terceiro <terce...@debian.org> wrote: > On Fri, Jul 08, 2016 at 06:53:29PM +0000, Eric Wong wrote: > > Thanks for the report. Can you try the patch below? > > Didn't help. > > I can't, however, reproduce this locally on my workstation. Thanks for following

Bug#830353: ruby-kgio: FTBFS: ERROR: Test "ruby2.3" failed.

Lucas Nussbaum wrote: > The full build log is available from: > > http://people.debian.org/~lucas/logs/2016/07/07/ruby-kgio_2.10.0-1_unstable_reb.normal.log > > A list of current common problems and possible solutions is available at >

Bug#827220: ruby-kgio FTBFS on hppa architecture

Helge Deller wrote: > I'm somehow lost here now... > Ideas? Thanks, I'm lost here, too. Anyways I've forwarded this to ruby-core upstream: https://bugs.ruby-lang.org/issues/12489 Unfortunately, I think posting to that bug tracker or replying to Message-ID:

Bug#827220: ruby-kgio FTBFS on hppa architecture

Helge Deller <del...@gmx.de> wrote: > On 13.06.2016 22:59, Eric Wong wrote: > > Seems to be a ruby2.3 problem. > > Does the ruby2.3 test suite work at all on hppa? > > No idea (I'm no ruby expert). > The last build log is here: > https://buildd.debian.org/status/f

Bug#827220: ruby-kgio FTBFS on hppa architecture

Mattia Rizzolo wrote: > On Mon, Jun 13, 2016 at 10:40:51PM +0200, Helge Deller wrote: > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0xfa5dd480 (LWP 29258)] > > mix_id_table_lookup (tbl=0x0, id=id@entry=3265, valp=valp@entry=0xfa55f248) > >

Bug#825790: w3m: -cols should work without -dump

Tatsuya Kinoshita wrote: > On May 29, 2016 at 10:47PM +, e (at 80x24.org) wrote: > > In other words, there should be a way to forcibly wrap long > > lines of text when using w3m interactively. > > > > I looked around the source and docs but could not find a > > way to do it,

Bug#825790: w3m: -cols should work without -dump

Package: w3m Version: 0.5.3-19 Severity: normal Tags: upstream In other words, there should be a way to forcibly wrap long lines of text when using w3m interactively. I looked around the source and docs but could not find a way to do it, but please tell me if I missed something. This is an

Bug#824843: libsys-syscall-perl: autopkgtest failures on arm64

Niko Tyni wrote: > The problem is that arm64 does not have the legacy epoll_create() and > epoll_wait() syscalls, those are implemented in glibc with epoll_create1() > and epoll_pwait() if I understand correctly. > > So epoll_create(arg) can be replaced with epoll_create1(0). >

Bug#824843: libsys-syscall-perl: autopkgtest failures on arm64

Niko Tyni wrote: > It seems probable that this makes it fail to build from source > on arm64 as well, but I haven't verified that. armhf is OK on > tests.reproducible-builds.org fwiw. Does removing the ARM-specific part and falling back to the .ph files help at all? (see diff

Bug#824377: slrnpull: expiry cronjob fails after jessie upgrade

Package: slrnpull Version: 1.0.2-2 Severity: normal Finally upgraded from wheezy to jessie today, and now my daily cronjob fails with the following: /etc/cron.daily/slrnpull: This account is currently not available. Which is coming from the following line in

Bug#824244: libfilesys-notify-simple-perl: fails to notify on moves with inotify

gregor herrmann <gre...@debian.org> wrote: > On Sat, 14 May 2016 04:22:46 +0000, Eric Wong wrote: > > I also tried 0.12-1 from jessie with the same effect. > So this needs further investigation ... Sorry for the noise, I screwed up the include path when using the jessie mod

Bug#824244: libfilesys-notify-simple-perl: fails to notify on moves with inotify

Package: libfilesys-notify-simple-perl Version: 0.08-1 Severity: normal I tried to have this watch some Maildirs but it fails to detect rename() calls. So this probably should watch for IN_MOVED_TO and IN_MOVED_FROM events from inotify. I also tried 0.12-1 from jessie with the same effect.

Bug#795913: libmail-thread-perl: [PATCH] avoid failing grouping by subject with missing references

Fwiw, I suggest fixing this bug in Debian since upstream has been nonresponsive for years. This route was taken for https://bugs.debian.org/763403 , too. Thanks.

Bug#808610: Accepted xapian-core 1.2.22-3~bpo8+1 (source amd64 all) into jessie-backports, jessie-backports

Olly Betts wrote: > Closes: 765820 791312 808610 814744 > Changes: > xapian-core (1.2.22-3~bpo8+1) jessie-backports; urgency=medium > . >* Rebuild for jessie backports. Thanks Olly. Are you still planning on getting #808610 fixed in normal jessie (and not just

Bug#808610: libxapian22: xapian database corruption causes recollindex loop

Olly Betts <o...@survex.com> wrote: > On Thu, Mar 03, 2016 at 01:52:45AM +0000, Eric Wong wrote: > > > > I would greatly appreciate a backport to fix this in Jessie. > > A backport would only fix it for people who take special action and > install from backports

Bug#808610: libxapian22: xapian database corruption causes recollindex loop

> > > On Mon, Dec 28, 2015 at 02:45:43AM +, Olly Betts wrote: > > > > http://trac.xapian.org/changeset/826d1a19cc356e7bf66c1681626e70af32967447/git It's been longer than 24 hours, but yes, everything is still good with the above change. I would greatly appreciate a backport to fix this in

Bug#808610: libxapian22: xapian database corruption causes recollindex loop

Eric Wong <e...@80x24.org> wrote: > > On Mon, Dec 28, 2015 at 02:45:43AM +, Olly Betts wrote: > > > There haven't been many backend changes since 1.2.19 - my guess is it's > > > this one: > > > > > > http://trac.xapian.org/changeset/826

Bug#808610: libxapian22: xapian database corruption causes recollindex loop

Olly Betts wrote: > On Mon, Dec 28, 2015 at 02:45:43AM +, Olly Betts wrote: > > There haven't been many backend changes since 1.2.19 - my guess is it's > > this one: > > > > http://trac.xapian.org/changeset/826d1a19cc356e7bf66c1681626e70af32967447/git > > > > Can you test

Bug#797705: [PATCH] git-svn: fix auth parameter handling on SVN 1.9.0+

os/asf/subversion/branches/1.8.x svn log -v $BRANCH/subversion/bindings/swig/core.i ref: https://bugs.debian.org/797705 Cc: 797...@bugs.debian.org Signed-off-by: Eric Wong <normalper...@yhbt.net> --- Thanks to the reporter (Bcc:-ed to protect their privacy) who notified Dair and I of this

Bug#795913: libmail-thread-perl: [PATCH] avoid failing grouping by subject with missing references

, 'oldstable') -- no debconf information From 9d1837f2118efa614d1acddd09ea7f53aba15ba4 Mon Sep 17 00:00:00 2001 From: Eric Wong e...@80x24.org Date: Mon, 17 Aug 2015 21:16:25 + Subject: [PATCH] avoid failing grouping by subject with missing references It is possible to for the topmost subroutine

Bug#795913: [rt.cpan.org #106498] Example workaround for existing apps

For reference to other users who may encounter this bug but cannot patch Mail::Thread itself, this is how I workaround the bug in the public-inbox project using monkey patching: http://public-inbox.org/meta/m/20150818-CPANRTBug106498-workaround%40v1.txt

Bug#795913: Acknowledgement (libmail-thread-perl: [PATCH] avoid failing grouping by subject with missing references)

Upstream bug link: https://rt.cpan.org/Ticket/Display.html?id=106498

Bug#776244: lv2file: [PATCH] allow piping raw FP audio from stdin to stdout

/ecasound, such as dtas-player in dtas http://dtas.80x24.org/ From 61a2f330c030544055c4f546966254722363e063 Mon Sep 17 00:00:00 2001 From: Eric Wong e...@80x24.org Date: Sun, 6 Oct 2013 04:00:48 + Subject: [PATCH] allow piping raw FP audio from stdin to stdout This allows lv2file to be used

Bug#767530: SVN::Ra: get_dir fails

Package: libsvn-perl Version: 1.8.10-3 Severity: important Tags: upstream The attached script using get_dir fails with SVN 1.8.10-3 in unstable. The SVN package in Debian stable (1.6.17dfsg-4+deb7u6) is fine. I get the following failure: Incorrect parameters given: Could not convert '%ld'

Bug#763403: libmail-thread-perl: [PATCH] memory leak/cycle fix from CPAN

Package: libmail-thread-perl Version: 2.55-1 Severity: important Tags: patch There is a nasty memory cycle for long running processes, and upstream seems non-responsive: https://rt.cpan.org/Public/Bug/Display.html?id=22817 Direct link to patch (not written by me, but I've tested it):

Bug#760336: libsys-syscall-perl: [PATCH] fix 0.25 release regressions

in 0.21 is a no-op nowadays). See https://github.com/bradfitz/sys-syscall/issues/5 for full discussion. Upstream may not be able to respond in time, but I hope we can get this patch in for Jessie. Thanks. From 5fc4d9fd90f3e894bef0f1bdad0a17beaa81f39f Mon Sep 17 00:00:00 2001 From: Eric Wong e

Bug#735861: [ruby-core:61553] [Backport200 - Backport #9649] [Open] Segfault running thread_safe torture tests under Ruby 2.0

This is fixed in Ruby 2.0.0 p451, seems related to https://bugs.ruby-lang.org/issues/9178 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732608: slrnpull logrotate needs missingok

Package: slrnpull Version: 1.0.0~pre18-1.3 Severity: normal Tags: patch When I configure the slrnpull to only run manually, /var/log/news/slrnpull.log does not exist at all (it is not empty), so logrotate needs missingok in addition to notifempty. Otherwise logrotate will fail during its daily

Bug#717276: perl: enable systemtap support via -Dusedtrace

Niko Tyni nt...@debian.org wrote: On Thu, Jul 18, 2013 at 06:37:25PM +, Eric Wong wrote: Source: perl Severity: wishlist I would like to use systemtap to trace Perl under Linux. The existing dtrace support in Perl may be used for this. Passing -Dusedtrace to Configure

Bug#717276: perl: enable systemtap support via -Dusedtrace

Source: perl Severity: wishlist I would like to use systemtap to trace Perl under Linux. The existing dtrace support in Perl may be used for this. Passing -Dusedtrace to Configure as documented in INSTALL should enable tracing support. A Build-Depends on systemtap-sdt-dev would be required

Bug#699321: [PATCH] avoid stat/fstat in statvfs/fstatvfs

I've also forwarded this patch to glibc upstream http://mid.gmane.org/20130201023510.ga22...@dcvr.yhbt.net From 2374682f5dc38d7cc752cdbdecd55bd870b38a90 Mon Sep 17 00:00:00 2001 From: Eric Wong normalper...@yhbt.net Date: Fri, 1 Feb 2013 01:55:27 + Subject: [PATCH] avoid stat/fstat in statvfs

Bug#699321: libc6: statvfs() calling stat() unnecessarily (2.6.36)

Package: libc6 Version: 2.13-37 Severity: normal Running statvfs() my machine still results in stat() being called, and from what I can tell, it's being called _before_ __statvfs_getflags() is called. I have not yet determined where stat() is called, but strace on my C program (see below)

Bug#699321: Acknowledgement (libc6: statvfs() calling stat() unnecessarily (2.6.36))

Here's the strace output I get with my patched libc6 on my test program: statfs(/mnt, {f_type=EXT2_SUPER_MAGIC, f_bsize=4096, f_blocks=37927273, f_bfree=3472739, f_bavail=1546144, f_files=9633792, f_ffree=7644549, f_fsid={-660744975, 649746596}, f_namelen=255, f_frsize=4096}) = 0 stat(/mnt,

Bug#696783: fusedav: [PATCH] setxattr: fix return values for errors

for the XATTR_REPLACE flag. Returning ENOTSUP for invalid attributes now allows GNU cp(1) to successfully archive files with a cp -a invocation. From ea2acf727beeed0030525d84271d0f7b6b0997b9 Mon Sep 17 00:00:00 2001 From: Eric Wong normalper...@yhbt.net Date: Wed, 26 Dec 2012 19:24:46 + Subject

Bug#692175: Acknowledgement (fusedav: concurrent dav_open can result in duplicate cache entries)

Here's a small cleanup on top the existing patch. I don't believe it fixes any real bugs, but it's Obviously Correct (TM). I worked on it while resolving issues with the original patch for #692179 commit d9ae7c815e8a98eeb214ea7e8495d95a458761a7 Author: Eric Wong normalper...@yhbt.net Date

Bug#692179: Acknowledgement (fusedav: fix flush and release of open files)

Attached are two more patches to fix problems this patch introduced. All fixes are in the bugfix-only branch of git://bogomips.org/fusedav I also have a cgit viewer running on http://bogomips.org/fusedav.git commit b330ce5df52d09879ed98e6889863b8f405b9938 Author: Eric Wong normalper...@yhbt.net

Bug#692175: Info received (Bug#692175: Acknowledgement (fusedav: concurrent dav_open can result in duplicate cache entries))

Attached is a big bugfix for the original patch. Sorry for the breakage. commit 54984c1bc3635efbe0661c0bdd98eb5083555e38 Author: Eric Wong normalper...@yhbt.net Date: Thu Nov 8 00:56:10 2012 + filecache: unlink cache entry on HEAD failure during open Since we insert

Bug#692174: fusedav: write-only files are truncated on update

. From 80275948b43eca7b30c3f715886ffd907da42b84 Mon Sep 17 00:00:00 2001 From: Eric Wong normalper...@yhbt.net Date: Wed, 24 Oct 2012 22:39:10 + Subject: [PATCH 08/13] filecache: file_cache_sync_unlocked properly syncs entire file When file_cache_sync_unlocked() calls load_up_to_unlocked(fi, -1

Bug#690926: [PATCH] dav_mknod respects executable bit

2001 From: Eric Wong normalper...@yhbt.net Date: Fri, 2 Nov 2012 21:37:46 + Subject: [PATCH 05/13] preserve executable attr on PUT when replacing Servers may not preserve the executable property if a PUT request overwrites an existing file. Since dav_mknod creates an empty file, the resulting

Bug#692175: fusedav: concurrent dav_open can result in duplicate cache entries

are hit by many opens at once. From 8ddaa7a0a9d19d913b9acf92f6056aea72267d83 Mon Sep 17 00:00:00 2001 From: Eric Wong normalper...@yhbt.net Date: Thu, 25 Oct 2012 01:56:27 + Subject: [PATCH 09/13] file_cache: prevent duplicate entries on concurrent open Calling file_cache_open() concurrently

Bug#692177: fusedav: [PATCH] fix truncate (it was completely broken)

Usage: TEST_DIR=/path/to/fusedav/mount ruby /path/to/this_script.rb From d4b6e7b53634ac2577e64325ffadba2530bb98b8 Mon Sep 17 00:00:00 2001 From: Eric Wong normalper...@yhbt.net Date: Thu, 25 Oct 2012 19:10:42 + Subject: [PATCH 10/13] fix truncate (it was completely broken) dav_truncate(): add

Bug#692178: fusedav: [PATCH] filecache: clear modified flag after PUT sync

Package: fusedav Version: 0.2-3 Severity: wishlist Tags: patch upstream This prevents a redundant PUT for apps which call fsync() before calling close(). From fa8c3aca4178f7f6b8453dbfbcef34202b6ce96b Mon Sep 17 00:00:00 2001 From: Eric Wong normalper...@yhbt.net Date: Thu, 25 Oct 2012 20:31:12

Bug#692179: fusedav: fix flush and release of open files

ad701acac54f8dcc60b697332c1a3ca1971cbc63 Mon Sep 17 00:00:00 2001 From: Eric Wong normalper...@yhbt.net Date: Thu, 1 Nov 2012 23:24:36 + Subject: [PATCH 12/13] implement dav_flush to avoid race from dav_release dav_release unlinks a file from the cache before syncing, allowing a concurrent thread to open

Bug#691369: fusedav: [PATCH] listxattr: fix space calculation leading to assertion failure

no packages. fusedav suggests no packages. -- no debconf information From e38a671e7347d5ef10965bd12720b40a1e94ab98 Mon Sep 17 00:00:00 2001 From: Eric Wong normalper...@yhbt.net Date: Wed, 24 Oct 2012 20:11:43 + Subject: [PATCH] listxattr: fix space calculation leading to assertion failure

Bug#514330: possibly related to fix in #691369

Hi, this may be related to a patch I just made for bug #691369 Some questions: * are you using 'cp -a' (perhaps aliased) instead of plain 'cp'? * does fusedav crash when this copy fails? * can you try my patch for #691369 and see if that fixes the issue? ref: http://bugs.debian.org/691369

Bug#691085: fusedav: [PATCH] filecache: parse large Content-Length properly

An HTTP and WebDAV client library fusedav recommends no packages. fusedav suggests no packages. -- no debconf information From 9753a633011caf66ce1f7f8a633c7e42df8fb152 Mon Sep 17 00:00:00 2001 From: Eric Wong normalper...@yhbt.net Date: Sun, 21 Oct 2012 01:25:27 -0700 Subject: [PATCH] filecache

Bug#690926: fusedav: [PATCH] dav_mknod respects executable bit

: Eric Wong normalper...@yhbt.net To: Lennart Poettering mzshfr...@0pointer.de Cc: Sebastian Harl s...@tokkee.org Subject: [PATCH (fusedav)] dav_mknod respects executable bit Message-ID: 20121019034640.ga17...@dcvr.yhbt.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition

Bug#691010: fusedav appears to deadlock

Package: fusedav Version: 0.2-3 Severity: normal Tags: upstream patch I've noticed fusedav is getting stuck on futexes sometimes. While eyeballing the code, I've found one possible source of deadlock on stat_cache_mutex: stat_cache_get() - locks stat_cache_mutex

Bug#691010: [PATCH] avoid mutex deadlock in stat_cache_get()

Attached is a better patch that avoids the non-portable (and ugly) recursive mutex in favor of properly releasing the lock before reacquiring it. From 460c14e1db1d1cab5f405f21e4a28a39c5721a36 Mon Sep 17 00:00:00 2001 From: Eric Wong normalper...@yhbt.net Date: Sat, 20 Oct 2012 04:17:43 +

Bug#669881: python-tweepy is out of date

Package: python-tweepy Severity: wishlist Hi, The version of tweepy in sid is out of date. It is version 1.7 in sid, but up to version 1.9 on github https://github.com/tweepy/tweepy/tags It's true that there is no egg file for this or the previous 1.8 release, so it needs to be built from

Bug#669572: libkqueue: want bugfix in new upstream version (1.0.5)

Package: libkqueue Version: 1.0.4-2 Severity: normal Hello, r524 fixes a truncation bug for me in knote_lookup(). The uintptr_t ident got truncated to a short, causing my app to fail when used with libkqueue. For non-file descriptor events, applications authors (e.g. myself) may choose a

  1   2   >