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!
Best,
Sebastian
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
kimproxy_out.conf changed [not included]
-- no debconf information
>From 97a5d9695bdf7488c9d6a2a058c852457657a86f Mon Sep 17 00:00:00 2001
From: Sebastian Boehm
Date: Thu, 16 Feb 2017 13:56:41 +
Subject: [PATCH] Update Vcs-Browser and Vcs-Git
---
debian/control | 4 ++--
1 file changed,
ackages dkimproxy recommends:
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:
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 dependencies and hence build ti
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 whic
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 the same conclusion when
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
st
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
386 (i686)
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
Date: Mon,
Hi,
thanks for the detailed response.
On 26 May 2015 at 00:31, David Kalnischkies 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 that I don't believe
i
Hi,
On 25 May 2015 at 16:58, Julian Andres Klode 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 seconds
on whe
Hi,
On 25 May 2015 at 15:32, Julian Andres Klode 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 never taken lon
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. (Wh
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
W
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
Package: wnpp
Severity: wishlist
Owner: Sebastian Boehm
* Package name: ruby-minitest-stub-const
Version : 0.4
Upstream Author : Adam Mckaig
* URL : https://github.com/adammck/minitest-stub-const
* License : Expat
Programming Lang: Ruby
Description
On 19 October 2014 17:45, Christian Hofstaedtler 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, DEB_HOST_GNU
Hi,
On 19 October 2014 15:17, Christian Hofstaedtler 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 apply your p
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
packaging
On 8 May 2014 12:39, Christian Hofstaedtler 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 loaded by syst
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,
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,
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 issues
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
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.
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 debian-bugs-di
Package: wnpp
Severity: wishlist
Owner: Sebastian Boehm
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
Version : 20111030
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
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
30 matches
Mail list logo