Bug#676875: ruby-build: Recipy rbx-2.0.0-dev fails

The exact same thing happens with a non-Debian version of rbenv and ruby-build on a pristine Wheezy box. This does not seem to be a packaging error but a problem with ruby-build (or maybe rubinius). Could you please file an upstream bugreport? Thanks. -- To UNSUBSCRIBE, email to

Bug#646399: chef: Chef packages in Debian are out of date

Package: chef Version: 0.8.16-4.2 Severity: wishlist Debian's chef packages should be updated to chef 0.10 or 0.9 for Debian Sid. 0.8 is too old to be useful anymore. The current chef version on http://apt.opscode.com/ is 0.10.4 for 0.10 and 0.9.18 for 0.9. If there's anything I can do to help

Bug#622374: current status of bundler package

Whtat is the current status of this ITP? Is there any way I can help? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#652075: ITP: ruby-build -- tool to compile and install different versions of Ruby

Package: wnpp Severity: wishlist Owner: Sebastian Boehm sebast...@sometimesfood.org I just joined the pkg-ruby-extras team and would like to add a package for ruby-build, a small tool to compile and install different versions of Ruby that works great with rbenv. * Package name: ruby-build

Bug#556732: libnss-pgsql2: hangs after authentication in _nss_pgsql_getpwuid_r

I just ran into this bug which was described in more detail by Daniel Popowich on pgsql-general last November: http://www.postgresql.org/message-id/20626.48966.389612.978...@jupiter.astro.umass.edu The workaround (running nscd) seems to work fine so far, even if a real fix would be preferrable.

Bug#695475: Bug in rbenv

Closing this. This was a bug in rbenv and has been fixed for some time now. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747232: Ruby should support SystemTap

Package: ruby2.0 Version: 2.0.0.484+really457-3 Ruby 2.0 introduced support for DTrace, a dynamic tracing framework by Sun, which can be used to trace running processes with minimal performance impact. While DTrace support on Linux still seems to be rather basic and burdened by licensing

Bug#747232: Ruby should support SystemTap

Hi Antonio, great to hear that 2.1 actually will be the default Ruby in jessie. On Tuesday 6 May 2014 at 23:32, Antonio Terceiro wrote: Can you try this on ruby2.1 and let me know? The patch works great for ruby2.1 as well and applies cleanly to Git commit fb119e39 via git am”. Best,

Bug#747232: Ruby should support SystemTap

On Wednesday 7 May 2014 at 20:42, Antonio Terceiro wrote: Just to be sure: did you actually tested it with ruby2.1 and does it work for you? Of course, otherwise I would not have said the patch “worked great”. :) Right now I am not familiar with dtrace/systemtap beyond knowing they exist, so

Bug#747232: Ruby should support SystemTap

On 8 May 2014 12:39, Christian Hofstaedtler z...@debian.org wrote: Please expand on this - would this mean additional changes to the Ruby package? If so, please show us :-) Yes, but only minor changes. Basically we would have to install a tap file to /usr/share/systemtap/tapset which is then

Bug#765862: Ruby should include a SystemTap tapfile

Package: libruby2.1 Version: 2.1.3-1 While Ruby supports SystemTap, a dynamic tracing framework for Linux (see #747232), at the moment the Debian package does not ship with a tapfile to facilitate tracing Ruby programs. The attached patch adds the tapfile used in Fedora and modifies the

Bug#765862: Ruby should include a SystemTap tapfile

Hi, On 19 October 2014 15:17, Christian Hofstaedtler z...@debian.org wrote: I think this would break Multi-Arch co-installability of libruby2.1 (a file that differs between architectures gets installed in the same location on different architectures). If you could sort this out I'd likely

Bug#765862: Ruby should include a SystemTap tapfile

On 19 October 2014 17:45, Christian Hofstaedtler z...@debian.org wrote: No, I don't know where systemtap would look for the file. If that locations works, that's fine with me. Apparently systemtap expects tapfiles to be located in x86_64 on amd64 systems and in i386 on i386 systems. However,

Bug#783874: ITP: ruby-minitest-stub-const -- library that lets minitest users stub constants for the duration of a block

Package: wnpp Severity: wishlist Owner: Sebastian Boehm sebast...@sometimesfood.org * Package name: ruby-minitest-stub-const Version : 0.4 Upstream Author : Adam Mckaig adam.mck...@gmail.com * URL : https://github.com/adammck/minitest-stub-const * License

Bug#783874: Acknowledgement (ITP: ruby-minitest-stub-const -- library that lets minitest users stub constants for the duration of a block)

Sorry, duplicate ITP. Trying to merge this with #782312. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764204: apt-cache calls fcntl() on 65536 FDs

Julian, do you have any pointers on where the fcntl calls could originate? I encountered the same problem after upgrading to jessie and it seems I am not the only one: - https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1332440 - http://askubuntu.com/questions/477757/why-is-apt-cache-so-slow

Bug#764204: apt-cache calls fcntl() on 65536 FDs

Hi, just looked into this, apparently the calls originate in the ExecFork function in apt-pkg/contrib/fileutl.cc, lines 760-792 (as of commit 15901516). Michael Vogt seems to have increased the number of file descriptors that are closed from 40 to sysconf(_SC_OPEN_MAX) in Git commit 61f954bf.

Bug#764204: apt-cache calls fcntl() on 65536 FDs

Hi, On 25 May 2015 at 15:32, Julian Andres Klode j...@debian.org wrote: I don't really see the performance issue here, though. I don't know why the submitter thinks that there is a performance issue here. The closing takes a few milliseconds. An apt-cache show runs in 0.040s here, and has

Bug#764204: apt-cache calls fcntl() on 65536 FDs

Hi, On 25 May 2015 at 16:58, Julian Andres Klode j...@debian.org wrote: Those seem to be uncached or on compressed indices, and thus not relevant for this bug. fair enough. Still, even with cached and uncompressed indices a single apt-cache show takes about 1.6 seconds on jessie and about 1.2

Bug#764204: apt-cache calls fcntl() on 65536 FDs

Hi, thanks for the detailed response. On 26 May 2015 at 00:31, David Kalnischkies da...@kalnischkies.de wrote: Also, Wheezy has more packages and therefore more data than Jessie. True. But when disabling index compression and regenerating all caches, the difference in performance is so large

Bug#668571: Fixed in stretch

Hi, while this typo is still present in jessie, it seems to be fixed in stretch. The arp manpage in net-tools 1.60+git20150829.73cef8a-1 does not contain the typo anymore. Best, Sebastian

Bug#796497: ruby-ronn: depends on obsolete ruby-hpricot

Just for the record: ronn's upstream seems to be dead. The latest release is more than five years old and there haven't been any upstream commits for over two years. While ronn is a useful tool, asciidoc and asciidoctor are viable alternatives and are actively maintained as well as available in

Bug#799664: ruby-mustache: has a superfluous dependency on ruby-sinatra

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Shell: /bin/sh linked to /bin/dash >From 6d342689e837370d012439423c4016fcd19d991f Mon Sep 17 00:00:00 2001 From: Sebastian Boehm <sebast...@sometime

Bug#692274:

Any news on this? As explained in Debian bug #796497, ruby-ronn, a pure Ruby manpage authoring tool, depends on the obsolete ruby-hpricot parser which will not be shipped with stretch. Since a lot of packages use ruby-ronn for their manpages, it would be great to have an asciidoc-man package

Bug#796497: ruby-ronn: depends on obsolete ruby-hpricot

On 18 November 2015 at 00:32, Antonio Terceiro wrote: > I had a quick look at ronn and it looks like a lost case. it seems to convert > the markdown input to HTML first, and only then from HTML to roff, and the > dependency on hpricot seems very entrenched. Yes, I came to

Bug#796497: ruby-ronn: depends on obsolete ruby-hpricot

On 19 November 2015 at 14:41, Antonio Terceiro wrote: > can you try asciidoctor instead? I just uploaded 1.5.3, which got > support for creating manpages, 2 days ago. Great timing, thanks! asciidoctor works just fine and significantly cuts down the number of build

Bug#855291: dkimproxy: package recommendation "amavisd-new" should be a suggestion

nds: pn amavisd-new dkimproxy suggests no packages. -- Configuration Files: /etc/default/dkimproxy changed [not included] /etc/dkimproxy/dkimproxy_out.conf changed [not included] -- no debconf information >From a30c8f7aa247f7bb8becbd2a8dc9359569576e21 Mon Sep 17 00:00:00 2001 From:

Bug#855295: dkimproxy: Vcs-Browser and Vcs-Git are out of date

[not included] -- no debconf information >From 97a5d9695bdf7488c9d6a2a058c852457657a86f Mon Sep 17 00:00:00 2001 From: Sebastian Boehm <sebast...@sometimesfood.org> Date: Thu, 16 Feb 2017 13:56:41 + Subject: [PATCH] Update Vcs-Browser and Vcs-Git --- debian/control | 4 ++-- 1 file c

Bug#656041: dkimproxy: add IPv6 support

Hi Thomas, should we apply the IPv6 patch to the Debian version of dkimproxy? Upstream has been inactive for quite some time now, so it might be a good idea to add small fixes like this one to the Debian patch queue. Best, Sebastian

Bug#656041: dkimproxy: add IPv6 support

Hi Thomas, On 6 April 2017 at 17:28, Thomas Goirand wrote: > Yes, I agree, but not during the Stretch freeze. Let's do that when > Stretch is out. no worries, I did not expect you to break the freeze for such a minor change. Sounds like a great plan, thanks for your work!