hould really be doing from Perl and the rest of it remains
somewhat useful, but given that upstream has archived the project, I would
go ahead and remove it.
Maybe someday I'll dust off and finish a proper Kerberos Perl module that
uses the modern C API. In my copius free time. :)
--
Rus
gregor herrmann writes:
> On Wed, 06 Sep 2023 08:21:24 -0700, Russ Allbery wrote:
>> gregor herrmann writes:
>>> According to https://github.com/rra/docknot/issues/6 fixed upstream
>>> (in git, not released yet).
>> Yeah, I'm sorry about the delay here. I'm t
says that it's non-breaking (I believe that's
the case, although please tell me if I got that wrong) and is more
(perhaps excessively) explicit about distinguishing it from "-" because of
all the confusion about this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ography (the hyphen-minus is one of 25 dashes in Unicode), you may want
to say that explicitly in addition to saying that it's the character used
in UNIX command-line options (and, arguably as importantly, in UNIX
command names).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
en turned
into \-. People will have to rewrite them using proper Unicode hyphens to
get proper formatting.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ough that's somewhat
rare.
My opinion is that the world of documents that are handled by man do not
encode meaningful distinctions between - and \-, and man should therefore
unify those characters.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ous
to me. Sorry about the noise.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s is an architectural stab in the dark and I obviously don't
work on file system development, so maybe this isn't viable for some
reason that I'm not seeing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
t distribution before using it to
build the file system the actual installation is going into.
I suspect this won't be Ted's favorite option because this isn't a natural
way to think about the option space from a file system developer
perspective, but maybe we could find some compromise along those
up for occasional breakage. So the proximity-to-release argument to me
feels most relevant if this change is specifically a problem for the
release process and would hold up things Debian itself needs to do, due to
(for example) it being difficult to change tooling so that file systems
are gene
Package: tripwire
Version: 2.4.3.7-4+b3
Severity: grave
X-Debbugs-Cc: r...@debian.org
Looks like tripwire needs another rebuild against the latest libc6.
tripwire --check and tripwire --init both segfault once they start
analyzing the file system. Rebuilding the package with no changes
causes it
nd upgraded again
with USER and LOGNAME set to root, and now everything works fine. (Well,
my laptop gets extremely hot the first time I start the new Emacs, but I
assume that's expected for the new compilation system.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
d have assumed it must be something in my startup files that is
incompatible with the latest release of Emacs, except I thought -q
--no-site-file should completely disable loading anything from my local
configuration.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: emacs-lucid
Version: 1:28.1+1-1
Severity: grave
X-Debbugs-Cc: r...@debian.org
The 28.1 version of emacs-lucid fails on startup with a cryptic error
message:
% emacs
Cannot find suitable directory for output in ‘comp-native-load-path’.
Running emacs -q allows it to start, but it still
E for the dropped symbol,
or add an rk_closefrom wrapper around the glibc closefrom to keep the same
ABI. (Or break the ABI without changing the SONAME on the grounds that
only a few packages use it, but I'm pretty hesitant to recommend doing
that since who knows what outside of Debian might break and w
whole perl + shell + makefile has also lot of duct tape included.
> I’ll either fix this directly in dh-php or provide the affected packages
> with a patch.
> 1. I don’t think missing dependency on PHP is a serious bug, it doesn’t
> prevent usage of the extension, it just doesn’t pul
doing anything
as a package maintainer, or is this expected? Should it be a serious bug?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
nd apologies for the delay in fixing this! There
was a test suite change that requires an additional file from the source
tree be available and I need to fix the test configuration. Will fix this
shortly.
Thank you so much for generating these bug reports. They're incredibly
helpful!
--
Rus
Package: tripwire
Version: 2.4.3.7-3+b3
Followup-For: Bug #994910
Reproduced here following a libc6 upgrade. I suspect this is because
tripwire is statically linked and there has been a new release of libc6,
so I suspect the nsswitch interface has broken (which is a standard
problem with
Adrian Bunk writes:
> Source: docknot
> Version: 4.00-1
> Severity: serious
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/docknot/10221864/log.gz
Thank you for relaying those results! I forgot to go explicitly check.
Will fix shortly.
--
Russ Allbery (r..
admit I have no idea on how
> to report a bug outside reportbug.
To add additional information to a bug, you can just send mail directly to
976...@bugs.debian.org with a regular mail client if you want. (reportbug
is very useful for getting all the right bits in place to open a new bug,
tho
Russ Allbery writes:
> Adrian Bunk writes:
>> ...
>> lib/network/server..MISSED 34-42 (killed by signal 14)
>> ...
>> Failed Set Fail/Total (%) Skip Stat Failing Tests
>> -- -- -
sts=3631, 12.90 seconds (2.43 usr + 1.92 sys = 4.35 CPU)
> make[2]: *** [Makefile:38: test] Error 1
I'm working on a fix. It's unfortunately rather complicated because the
assumption that binding on any address will provide two sockets ran fairly
deep.
I think the problem only affects the
the buildds with only IPv6
addresses. Working on a fix, will try to get it uploaded soon since I
know a Python transition is coming.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
/facts.d
> /etc/puppetlabs/facter/facts.d
> /opt/puppetlabs/facter/facts.d
Yup, confirmed that works. Thank you!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: facter
Version: 3.11.0-4.1
Severity: grave
facter no longer works at all on amd64. When invoked, it dies with
an invalid pointer error:
% facter
free(): invalid pointer
Aborted (core dumped)
gdb backtrace:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1
o DELAYED/15, closing this
> bug. Please let me know if I should delay or cancel that upload.
Oh, whoops, sorry. Thank you for letting me know! I'll do the source
upload myself, since that way it's easy for me to keep the Git history
consistent. I can do that this evening.
--
Russ Allbery (
Marco d'Itri writes:
> On Jan 20, Russ Allbery wrote:
>> This also implies that there is arguably an SONAME issue with this library
>> given that two versions of the library with the same SONAME don't provide
>> the same symbols, but I suspect there were really
me (but now I wonder if I have other
> leftover files like this…).
This also implies that there is arguably an SONAME issue with this library
given that two versions of the library with the same SONAME don't provide
the same symbols, but I suspect there were really, really good reasons to
not ch
Andreas Beckmann writes:
> Followup-For: Bug #932351
> Control: tag -1 pending
> buster-pu request: https://bugs.debian.org/948796
Oh, thank you! I was going to get to that and then didn't. Much
appreciated and let me know if I can help in any way.
--
Russ Allbery (r...@d
Now fixed, although I got the changelog message wrong because I still
didn't understand properly. Ugh. I could have sworn that Debian buildds
didn't allow network access. I'll fix the changelog message in a future
upload.
Thank you!
--
Russ Allbery (r...@debian.org) <ht
Now fixed, although I got the changelog message wrong because I still
didn't understand properly. Ugh. I could have sworn that Debian buildds
didn't allow network access. I'll fix the changelog message in a future
upload.
Thank you!
--
Russ Allbery (r...@debian.org) <ht
s (I thought it would know that an unversioned dependency on typing was
already satisfied by Python 3 stdlib). Will fix tonight.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
thought setuptools was much smarter than apparently it
actually is. I'll look at this tonight; I may fix this upstream instead
of only in the Debian package if it doesn't take too long to do.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
this for unstable and will see about getting a targeted fix into
stable as well, although it won't go out, at best, until the next point
release.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
erminated
> I got the same result on two different machines, over Wayland and X11.
I can't reproduce this.
Can you enable core dumps (ulimit -c unlimited) and then run gdb on the
corresponding core dump (gdb /usr/games/gnubg core) and then run backtrace
and show the backtrace for this?
--
Russ All
nel
errors like:
[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo
underrun on pipe B
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO
underrun
and then lots and lots of:
[drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle
patterns
--
t.
> https://lwn.net/Articles/664800/
The work is actively underway in both the kernel and in glibc, but I don't
think it's fully working in buster. I would expect it to be there by the
next Debian release, though.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: rssh
Version: 2.3.4-8
Severity: grave
Tags: security upstream
https://sourceforge.net/p/rssh/mailman/message/36519118/ is the upstream
report. The reporter indicated they asked for a CVE but didn't include it
in the message.
scp allows remote code execution inside the server
te loop during byte-compilation does make it feel like there may
be some underlying but in Emacs as well, since that doesn't feel like
something that should be possible, but it may not be detectable or
avoidable depending on what the cause was.)
--
Russ Allbery (r...@debian.org) &l
gnome_shell.json
Splitting that single config file into a separate contrib package feels
like overkill here. It shouldn't hurt anything on a system without Chrome
and it doesn't create any sort of dependency on Chrome, which is the
normal case for contrib.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Vincent Lefevre writes:
> On 2018-09-11 15:29:02 -0700, Russ Allbery wrote:
>> Vincent Lefevre writes:
>>> This would mean that a breakage is possible after any patch (in
>>> particular with those "Update to SVN..." in the changelog). Thus this
>>
the one used to build the kernel. For
> sid, GCC is often not in sync with the one used to build the
> kernel. This is a really big problem.
I don't think it's an NVIDIA-specific problem, though, right? Doesn't
this happen with any kernel module build? Or am I confused and this is an
NVID
tisfiable dependency since the compiler packages aren't
broken apart that way.)
> If the minor version really matters, why Debian doesn't ship different
> packages, such as gcc-6.3 and gcc-6.4?
I suspect that usually only the kernel is affected.
--
Russ Allbery (r...@debian.org)
is the obligation of
> the one doing the change to ensure proper availability of modules and
> support files.
There were literally zero packages in Debian that did this that Lintian
could find. Did we miss something?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
> make[2]: *** [policy.pdf] Error 127
> Since Sphinx 1.6, latexmk is required to build the LaTeX documentation [1].
> Adding a build-dependency on latexmk should help.
Thanks, fixed in Git. We'll need to make a new upload shortly.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
'm no longer working for the
employer who had that problem). If someone runs into a need for it, they
can always circle back and look at the package again. It seemed pretty
seriously unmaintained.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
I'm currently holding off on releasing debian-policy 3.9.9 until the
corresponding base-files change has been uploaded.
(It will probably actually be 3.10.0.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ot an unreasonable course of action).
Yeah, this is a good argument. Works for me! It's also good to use a
more robust mechanism for doing this so that we don't get accidental
problems in the future when the locking stuff changes again.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
cussion about
disabling the init script and this ended up being better, but I forget the
history.
I think restoring the disable logic may be all that's required.
Thank you for looking at this!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
and try to use the server
named "puppet" as a Puppet master on package installation is pretty bad.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
that. :) The error message you give
doesn't even have anything to do with this module?
Lots of people are using this package in jessie, so the chances are
extremely low that it's actually broken for everyone.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ache can go to 1.1 and all the pieces are happy. (The OpenSSL work is
done in a separate daemon, shibd, that the Apache module talks to.)
(Not that this solves all the problems, but just FYI.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
an-devel?
This seems like something we're going to have to figure out project-wide,
since the way the transition is currently set up doesn't seem likely to
work.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
frame. So I'm not sure there's any other alternative.
Whatever dependencies that were pushing open-vm-tools to 1.1 may have to
be reverted back to 1.0.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
an
letting it use its normal upgrade semantics. (Also, a general upgrade is
safer in that you'll always get security updates.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
he test more robust against this by also checking for a
string containing $(hostname), but if you happen to know what the reverse
DNS is for 127.0.0.1 in the test environment, I'll make sure this is
caught.
Downgrading since this shouldn't be a problem for Debian proper; this
seems to work fine on al
loves
hiding things like this.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ckage
> will FTBFS for anyone building it.
Thanks for the report! I won't get a chance to get to this until this
weekend, but I'll definitely take a look and try to get it fixed then.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
forgot about that until just
after I uploaded it.
I'll open a bug against release.debian.org for the mini-transition.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
og4shib propagates everywhere just in case.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ferenc Wagner <wf...@niif.hu> writes:
> Russ Allbery <r...@debian.org> writes:
>> I think I was just confused and everything is fine, since the
>> transition already happened after the previous NMU. There's still a
>> transition for opensaml2 and shibbol
Ferenc Wagner <wf...@niif.hu> writes:
> Please wait a little, I'm packaging the new upstream anyway and will
> introduce this change soon (I'll need a sponsor, though).
I should be able to help with sponsorship.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
7).>, __len=6,
> __len@entry= detected (257).>) at /usr/include/x86_64-linux-gnu/bits/string3.h:53
> 53
Hrm. Okay, so the compiler is doing something weird, and this isn't a
problem with libtasn1. Thanks for the additional information! I'm going
to reassign this to gcc-5, and
work, but I could have sworn the
version I uploaded wasn't built with PIE.
I can reproduce this, trying to figure out what's going on right now.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
nstable and running gnubg. To get the above backtrace, I just
grabbed the source package, did apt-get build-dep gnubg, debian/rules
build, and installed the debugging packages for libgnutls and libtasn1.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
RCE_DATE_EPOCH support from podlators-4.00
> doesn't itself survive being build with SOURCE_DATE_EPOCH (or
> POD_MAN_DATE, for that matter) set. Patch attached.
podlators 4.03 released with this fix.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
rsion, probably this weekend.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: golang-golang-x-tools
Version: 1:0.0~git20150716.0.87156cb+dfsg1-4
Severity: serious
Unpacking golang-golang-x-tools (1:0.0~git20150716.0.87156cb+dfsg1-4) ...
dpkg: error processing archive
/var/cache/apt/archives/golang-golang-x-tools_1%3a0.0~git20150716.0.87156cb+dfsg1-4_amd64.deb
f, just don't be too concerned about the fate of
> the current versions in unstable, expect new upstream versions after a
> couple of weeks.
If you're changing the SONAME anyway, you don't have to do the renaming
described here. That's actually an even cleaner solution.
--
Russ Allbery (
Just one more data point:
I just upgraded another system using assword, with a separate private key
that was generated on 2014-08-20, and everything worked fine with it. And
I don't get the legacy keys errors on that system either.
--
Russ Allbery (r...@debian.org) http
successfully imported. Just not that one.
do you know if there were more legacy key messages for the second
--import command?
Oh, yeah, there are tons every time I run that command. Basically one for
every key.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
D15D313882004173
gpg: using classic trust model
pub rsa4096/D15D313882004173 2009-05-29 [expires: 2017-09-17]
uid [ultimate] Russ Allbery ea...@eyrie.org
uid [ultimate] Russ Allbery r...@stanford.edu
uid [ultimate] Russ Allbery r...@debian.org
uid
)= 0
write(2, Assword database error: Decrypti..., 59Assword database error:
Decryption error: Decryption failed) = 59
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
[ultimate] Russ Allbery ea...@eyrie.org
uid [ultimate] Russ Allbery r...@stanford.edu
uid [ultimate] Russ Allbery r...@debian.org
uid [ revoked] Russ Allbery ea...@windlord.stanford.edu
uid [ultimate] Russ Allbery r...@cs.stanford.edu
sub 4096R
Package: assword
Version: 0.8-2
Severity: grave
assword can no longer decrypt any of my password stores. It fails with
the error:
mithrandir:~$ assword dump foo
Assword database error: Decryption error: Decryption failed
The data store is not corrupt; running GnuPG on it manually works fine.
. (Meaning that I don't think we should remove this
package from the release if no one gets to this.)
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
behavior on
upgrades.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Vincent Lefevre vinc...@vinc17.net writes:
On 2015-03-21 13:14:08 -0700, Russ Allbery wrote:
Correct. The Policy statement is about preserving user changes, not
about never touching any file that a user has modified in any way. The
package is free to modify unchanged portions
that as a particularly `strict'.
There are certainly other packages in the archive with Perl maintainer
scripts, although the ones I'm aware of I don't think use modules that
have moved.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian
.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
welcoming.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
cleaner should a later backport be done, but I
think your change will work fine.
Sorry about that oversight!
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
a look, but I no longer use Shibboleth and handed the
package maintenance off. Copying the general mailing list.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
a process crash. But to create
this situation, the attacker has to nearly exhaust all process memory, and
could just go a step farther and exhaust all memory, which would almost
certainly result in a process crash anyway, or an OOM kill.
Am I overlooking something?
--
Russ Allbery (ea...@eyrie.org
one
that upstream should accept fairly readily.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
fault for not separating CFLAGS and CPPFLAGS.)
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
back, so this explains that as well. Sorry about the incorrect diagnosis!
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
changes, but for the
record, there's no need to have the discussion again after a library
SONAME change. Pre-Depends on libraries should be assumed to track SONAME
changes in that library.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian
inferior to what's available with
very little additional work using the native configuration format, and the
regular inittab jobs are provided by regularly-configured services. Yes,
that is a disruptive change for people who were using inittab to run other
things.
--
Russ Allbery (r...@debian.org
that.
There's no reason to switch away from inittab for sysvinit. For systemd,
a unit file can easily do everything that you would get from inittab.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
.
Let me know if I can assist with an NMU.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: puppet-module-puppetlabs-firewall
Version: 1.0.2-1
Severity: grave
With version 1.0.1 of iptables-persistent, this module fails with
the error:
Error: /Stage[main]/Firewall::Linux::Debian/Service[iptables-persistent]: Could
not evaluate: Could not find init script for
Source: krb5
Version: 1.12.1+dfsg-1
Severity: serious
When the documentation is built, 1.12.1+dfsg-1 fails to build with the
following error:
cd build/doc make substhtml substpdf
make[1]: Entering directory '/«BUILDDIR»/krb5-1.12.1+dfsg/build/doc'
sed -e 's|@SRC@|../../src|g' \
-e
meant that dpkg-buildpackage fell back on
debian/rules build but didn't install B-D-I.
That said, adding python to B-D-I is still correct since the build uses
Python directly, not only via something provided by python-lxml.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle
out, but I'll go ahead and do the packaging changes now and
worry about that later.
Thanks for the report!
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
Christian Hofstaedtler z...@debian.org writes:
* Russ Allbery r...@debian.org [140409 02:46]:
Hm. Those are timing-sensitive tests that can fail on extremely slow
systems, but I did have them tweaked so that they pass on all of Debian's
buildds.
Actually this should be quite a fast system
. But
then everything worked great.
I also added the XB-Ruby-Versions header, since that seems to be best
practice these days (although I didn't manage to find it in the Ruby
packaging policy).
Now uploaded, with ruby-remctl built against 2.0 and 2.1. Thank you for
your work on this!
--
Russ
).
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: xml2rfc
Version: 2.4.3-1
Severity: serious
Since python-lxml was upgraded to 3.3.1-1, xml2rfc no longer works.
It fails with the following backtrace:
Traceback (most recent call last):
File /usr/bin/xml2rfc, line 225, in module
main()
File /usr/bin/xml2rfc, line 139, in main
1 - 100 of 493 matches
Mail list logo
