Package: apt
Version: 2.7.13
Severity: minor
Tags: patch
Attached are minor improvements to 'apt edit-sources' bash completion:
- Generate accurate '*.list' list of files, and omit '.list'
suffixes. (I _would_ also list '*.sources', but current 'apt
edit-sources' does not support this newer f
Package: libcap2-bin
Version: 1:2.66-4
Severity: wishlist
In my opinion, getcap(8) is useful to run as a non-root user, so it
should be in /bin rather than /sbin. This seems analogous to ip(8)
from iproute2, which was moved to /bin many years ago.
Thanks,
Peter
nd to finish"
The - vs. \- distinction especially matters, because if you search for
"<<-" by typing "/<<-" into "less", but nroff has used a non-ASCII
hyphen there, it will not find it.
(Also, some older X11 fonts don't have the non-ASCII dash c
Package: feh
Version: 3.10-1
Severity: minor
Tags: patch upstream
feh.1, like many manpages, fails to escape the `-` character in option
descriptions. In modern groff, this causes each one to be rendered as
U+2010 "HYPHEN" instead of the ASCII character (U+002D "HYPHEN-MINUS").
The net effect:
-
[M. Zhou]
> I'd personally not prefer to upload zfs-X.Y.99 anytime in the future.
> Since debian is volunteer-based, we don't seem to have more bandwidth
> than Ubuntu for dealing with regressions and serious bugs in a
> snapshot version.
That's fair - but now that Linux 6.4 is in unstable, zfs-
Package: usb.ids
Version: 2023.01.16-1
Severity: minor
The UI at http://www.linux-usb.org/usb-ids.html, and the email
submission interface, do not permit submissions of anything but
vendors, devices, and classes. Here are some other typos I found just
by paging through the usb.ids file. If you h
Source: openssh
Version: 1:9.1p1-2
Severity: minor
I have no idea what possessed you to fix the dates on those
20-year-old changelog entries, but since you care ... 1:3.0.2p1-2 is
still wrong.
The correct fix was not s/Sat/Sun/ but s/2003/2002/.
Package: libavcodec60
Version: 7:6.0-1
Severity: minor
libavcodec{59,60} cannot be co-installed because both depend on exact
versions of libswresample4. (Also, libavfilter{8,9} have the same
issue.)
This will require an all-or-nothing library transition, and it means I
can't install ffmpeg 6.0 f
Package: ykls
Version: 1.3.4-2+b7
Severity: normal
$ lsusb | grep -e Yubi -e Smart
Bus 001 Device 098: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID
Bus 001 Device 099: ID 04e6:5116 SCM Microsystems, Inc. SCR331-LC1 / SCR3310
SmartCard Reader
$ ykls
Reader: SCM Microsystems Inc. SCR 3310 [CC
Can confirm that Lukas's patch builds zfs 2.1.1 when I update abigail
build-dep to (>= 1.8) and unfuzz patches.
Seems to work, too, at least with the kernel I'm booted into,
5.13.0-trunk-amd64 from experimental. (Which zfs 2.0.x does not
support.)
Peter
Package: openssh-client
Version: 1:7.6p1-2
Severity: minor
ssh-keygen refuses to edit my known_hosts file because:
$ ssh-keygen -f kh -R foo
kh:17: invalid line
kh:146: invalid line
kh is not a valid known_hosts file.
Not replacing existing known_hosts file because of errors
Package: gzip
Version: 1.6-5
Severity: normal
Given multiple files, zgrep's return value is inconsistent with grep:
$ echo foo > a
$ true > b
$ grep -q foo a b; echo $?
0
$ zgrep -q foo a b; echo $?
1
That is: grep succeeds, because at least one file contains a match.
But: zgrep fails, because a
[Colin Watson]
> Sorry, but I am not going to include any more large and invasive patch
> sets in Debian's OpenSSH package, especially not ones that add new
> configuration options (upstream has a history of giving such things
> different names when they accept them, and then I'm stuck maintaining
reassign 749014 src:linux
thanks
[Ben Hutchings]
> Your mail server seems to be broken.
Right you are, thanks for the extra step to contact me via the BTS.
> This should be assigned to src:linux not a binary package.
Also correct, I just didn't know offhand whether there was a way to
assign t
reassign 749014 linux-image-3.17.0-trunk-amd64
thanks
CONFIG_USB_UAS was enabled but then later disabled due to problems with
a particular Seagate USB enclosure (#755995). Upstream found a
workaround, a quirks table / blacklist approach, and this fix was
included in 3.17.1 (see below).
Therefor
Package: linux-image-3.15-rc5-amd64
Version: 3.15~rc5-1~exp1
Severity: wishlist
CONFIG_USB_UAS (USB Attached SCSI) is apparently now solidly supported:
a patchset arrived in the 3.15 window to rewrite it and remove it from
CONFIG_BROKEN. Please add this to kernels that support USB 3.0 (it may
wor
> Source: gpm
>
> This package seems Linux-specific, so it should use Architecture:
> linux-any in the control file, so its build is not even tried on
> non-Linux archs.
Well, really libgpm2 should be ported to non-Linux platforms. gpm
itself may be specific to the Linux console, but libgpm2 sh
[Matthias Klose]
> Please build the subversion bindings for Python3, but keep building
> the bindings for Python2. I don't think that a hard switch can be
> made, and we have to provide both at least for some time.
Python3 is not supported upstream. A port was done, or at least
attempted, a cou
[Fabian Greffrath]
> So, the question boils down to "What should be shown as old revision,
> if not all files in the repo had the same old revision?".
If you really want this feature and are trying to figure out the
design, look at 'svnversion'. In the mixed-rev case, it shows a range.
(It also
> Am Dienstag, den 04.02.2014, 23:37 -0600 schrieb Peter Samuelson:
> > What would you expect the software to say in a mixed-rev wc?
[Fabian Greffrath]
> I don't know, I have never worked with such a repository (and my patch
> only addresses the simple single-rev wc c
[Vincent Lefevre]
> Well, the main problem with such unreferenced pristines is big files,
> and very often big files are binary files, or one doesn't use "blame"
> on them.
Well, 'svn blame' is just an example. 'svn switch', switching between
branches, is another case where caching pristines tha
[Vincent Lefevre]
> A "svn cleanup" reduces the pristine size to normal, but
> 1. this isn't documented (I'm wondering how many users know that);
> 2. this isn't automatic.
Right... I seem to recall that there is a vague plan to keep unused
pristines around for awhile in order to reuse them inste
reassign 729426 libsvn1
forcemerge 721878 729426
thanks
[Wouter Bolsterlee]
> svn: E200029: Couldn't perform atomic initialization
> svn: E200030: SQLite compiled for 3.8.0.2, but running with
> 3.7.13
Thanks. The problem is that there's 3 different opinions on this
depe
[James McCoy]
> Peter, what do you think of a) dropping the arch blacklists for Java and
> b) changing from gcj-jdk to default-jdk?
I'm a bit leery of using only OpenJDK everywhere, in principle, if it
causes gcj to fade away. Java was always supposed to be an open
platform, but these days it se
Package: bind9
Version: 1:9.9.3.dfsg.P2-4
Severity: normal
My RFC 1918 reverse zone definitions no longer work, unless I specify:
disable-empty-zone "168.192.in-addr.arpa";
(one for each reverse zone.) According to the ARM, I should not have
to do that - it should detect that I've defined
[Luca Conte]
> This morning I've dist-upgraded my debian testing and the problem has
> gone because, as someone said, (lib)sqlite3 unstable version was
> shifted into testing!
You can thank Julien Cristau for making that happen. It's not a fix
for this bug but it was an expedient workaround.
-
[Julien Cristau]
> + * Non-maintainer upload.
> + * Drop SQLite version check (closes: #722233). This is dpkg-shlibdeps'
> job.
Well, you're half right: it's something that should be expressed as
package dependencies, at which point the runtime version check would be
redundant and perhaps too
> ---8<---
> svn: E200029: Couldn't perform atomic initialization
> svn: E200030: SQLite compiled for 3.8.0.1, but running with 3.7.17
> --->8---
Sigh. This kind of problem is usually solved by the shlibs system, but
that doesn't fully work here. The problem is that the SQLite "ABI"
(usable SQL
[Norbert Preining]
> On Di, 03 Sep 2013, Peter Samuelson wrote:
> > texlive-lang-european? It doesn't look like it to me (no Breaks or
> > Conflicts), but I haven't actually tried it.
>
> conflicts there are, texlive-base conflicts with all the old packages.
I
> > Sounds like you are saying 'texlive-lang-danish' is only useful as a
> > package dependency - in other words, users would never install it
> > explicitly because they want its functionality. Is that correct? This
[Norbert Preining]
> I never said that. The functionality is now in
> te
[Norbert Preining]
> I understood your proposal, of course. Still, since there are no rdepends
> besides very few (1?) build-depends on these two packages, I consider
> it a a waste of resources.
Sounds like you are saying 'texlive-lang-danish' is only useful as a
package dependency - in other w
[Salvatore Bonaccorso]
> Only wanted to ask back: Did you had already a chance to look at the
> update for 1.7.10 (and the updates needed for the apache2.4
> transition?
I'm aware of the situation, yes. :/ I keep trying to find time to
finish the Apache 2.4 thing, yes. If I can find a bit of ext
[Arno Töll]
> could you please let me know if you're able to work on a patch in a
> foreseeable future?
Ah yes - I was looking at this last weekend but then ran out of time.
The conflict with the event mpm is probably not critical - it is only a
specific unusual configuration that breaks - so I t
[Joao Eriberto Mota Filho]
> Re-name [...] is a small and quick tool written in C so it's quicker
> than most rename tools written in shell scripts.
[citation needed]
I'm suspicious of this claim for two reasons.
- The obvious tool to compare with is 'prename' (mentioned up-thread),
which w
[Mathieu Malaterre]
> I do not believe in debian life-span, a package manager ever switch
> an implementation of a package. So libjpeg9 and libjpeg-turbo will
> have to co-live.
It happens. Look at the source for 'libc6'. It used to be glibc,
these days it is a fork called eglibc. Likewise the
> > http://subversion.apache.org/security/CVE-2013-1845-advisory.txt
> > http://subversion.apache.org/security/CVE-2013-1846-advisory.txt
> > http://subversion.apache.org/security/CVE-2013-1847-advisory.txt
> > http://subversion.apache.org/security/CVE-2013-1849-advisory.txt
> > http://subversion.
iceweasel 20 in experimental requires a newer tabmixplus. 0.4.0.5
seems to work. (But this is still only a 'wishlist' bug, as I'm only
talking about experimental.)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas..
[Kacper Perschke]
> Additionally I'd like to ask about
> http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-graph.pl
>
> Whom may I offer my help on beautifying this script with perltidy and
> documenting it by pod?
Anything in http://svn.apache.org/repos/asf/subversion is ma
[Daniel Schepler]
> debian/ino_t_test
> ***
> *** 'apr_ino_t' size is 8, expected 4
> *** Please report this to the Debian Apache maintainers
> ***
This test exists in order to detect an ABI change from older 1.2
(before lenny!) to present. Obviously the x32 port didn't exist then,
so, is there
Package: gimp
Version: 2.8.0-2+b1
Severity: normal
I have a 3-head X server without Xinerama. (Xinerama doesn't support
mixed video drivers - in my case, nouveau + intel + nouveau.) Thus,
DISPLAY is :0.0, :0.1, :0.2.
gimp Create -> Screenshot only captures data from its own screen.
Specifically
[Chris J Arges]
> This patch fixes issues related python multi-arch include problems.
> This casues this package to FTBFS when building in Ubuntu raring.
Looks good, except that part of your patch (the 'allpydbg' bits) is
specific to the Ubuntu packaging. It's a nice clean approach, though,
so t
[Jonathan Nieder]
> Are you sure? Could you send output from trying to install it?
I used interactive aptitude and it can't install chromium:i386 because
it can't find a candidate for the chromium-inspector dependency.
> (I had always thought that in the multi-arch world "Arch: all" meant
> "wi
Package: chromium-inspector
Severity: minor
In order to install chromium:i386 on my amd64 system, its dependency,
chromium-inspector, would need to be "Multi-Arch: foreign". This is
because it is "Architecture: all", which in a multi-arch context is
calculated as "Architecture: {primary installed
[Dominic Hargreaves]
> HybServ is a daemon that connects to your IRCD-Hybrid server and
> automagically provides nickname, channel, memo, and oper services to your
> entire network if it is configured correctly to talk with your IRC server.
"Automagically"? When you install a server package, con
> > Of course dpkg should be careful when replacing symlinks with
> > directories, because it's possible for a local admin to replace a
> > directory with a symlink for filesystem layout reasons. But this
> > is the opposite case, and dpkg certainly has enough information to
> > know it is safe.
[Andreas Beckmann]
> A test with piuparts revealed that your package misses the copyright
> file after an upgrade from squeeze to wheezy, which is a violation of
> Policy 12.5 :
Thanks - yeah, looks like a dpkg bug: during the upgrade, the old
/usr/share/doc/$pkg directory disappears, but dpkg fo
[Francesco Poli]
> However, asking for clarifications to the license author is not
> necessarily helpful: the reply you obtained from L. Rosen clarifies
> *his own* interpretation of one unclear clause of the AFL v3.0.
I know the distinction. But he is a lawyer with significant experience
in IP
Larry,
As author of the AFL v3.0, can you comment on some concerns raised
about it by Francesco Poli at
https://lists.debian.org/debian-legal/2012/09/msg00082.html
?
Francesco's message is somewhat long, so here is the most important
concern. (I read the relevant section of your book,
http://ro
> Setting up libapache2-svn (1.6.17dfsg-4) ...
> ERROR: Module dav_svn does not exist!
> dpkg: error processing libapache2-svn (--configure):
> subprocess installed post-installation script returned error exit status 1
> Errors were encountered while processing:
> libapache2-svn
> E: Sub-process
> 31.07.2012, Peter Samuelson wrote (on debian-release):
> > There is no need to remove gromacs in order for lesstif2 to migrate.
> > There's no SONAME bump or anything. The issue only came up at all,
> > because we needed to make sure the new lesstif2 does not add
[Stephen Fox]
> I rebuilt subversion without SASL after realizing SASL is an optional
> dependency, and svn is working fine. I suppose a way to isolate it to
> the ABI issue would be rebuilding the SASL libs, and building svn
> against that? I don't entirely understand the implications of Bug
> #6
[Norbert Preining]
> $ svn up
> Updating '.':
> svn: E170001: Unable to connect to a repository at URL
> 'svn://u...@server.org/some/path'
> svn: E170001: Could not create SASL context: generic failure: No such file or
> directory
>
> The same happens with svn+ssh://... on svn.debian.org
This
Package: cmucl
Version: 20c-2
Severity: important
The cmucl build is split into build-arch and build-indep, but
build-indep builds doc files that appear in arch-dependent packages.
This issue would cause a buildd to fail. Because it is a single-arch
package, it is not normally autobuilt, but a b
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mtink
Two FTBFS issues fixed: one for new lesstif2 (which is not in wheezy
yet), the other for dpkg-dev 'binary' vs 'binary-arch'.
Unfortunately I wasn't thinking of
[Ian Zimmerman]
> [50+1]transitional-foo$ grep '^Files:' control
> Files: foo /usr/bin
> [51+1]transitional-foo$ file foo
> foo: broken symbolic link to `bar'
[...]
> Cannot copy foo to
> /usr/local/var/git/transitional-sp/equivs.nI3JY_/install/0/foo:\
> No such file or directory
Yeah, equivs
[Michael Gilbert]
> Make sure to file an unblock request bug for the release team to
> review.
I doubt they will want it at this point. I should have thought of this
earlier: the new lesstif2 causes FTBFSs in dependent packages. I don't
know how many yet, as my workstation is still test-buildin
[Michael Gilbert]
> If you wouldn't mind. Please go ahead with this. I'm already
> causing too much trouble for the release team with my efforts on the
> multiarch release goal.
I saw your thread on debian-release. It looks like they aren't very
interested in fixing this (and the new ia32-libs
[Michael Gilbert]
> This package has not been updated in 3 years, so it is a prime
> candidate for nmu'ing. In fact, it's perfectly appropriate to nmu
> without advance permission of the maintainer in general.
I noticed later that the new empty/dummy ia32-libs is not in wheezy, so
that makes thi
This patch works for me, and allows me to upgrade ia32-libs:amd64 to
the sid version.
IMO, this bug is important enough to fix in wheezy, as it affects the
ability to upgrade ia32-libs. I'd be happy to NMU, if the maintainers
don't mind.
Peter
diff -u lesstif2-0.95.2/debian/rules lesstif2-0.95.
Source: ia32-libs-i386
Version: 20120616
Severity: normal
ia32-libs-i386 Depends: libjack0
But libjack0 conflicts with libjack-jackd2-0, so if you have
libjack-jackd2-0 installed already, it is not easy to upgrade
ia32-libs. We believe the dependency should really be
libjack0 | libjack-jack
[Christian Bac]
> Id - résumé compacte des 4 libellés précédents.
> and in french it should be:
> Id - résumé compact des 4 libellés précédents.
>
> Compact should not have a e because resumé is male and not female.
Fixed upstream: h
tags 678845 patch
thanks
[Neil Williams]
> $ svn-inject -o pycparser_2.07+dfsg-1.dsc \
> file:///home/neil/code/debian/svn-buildpackage/test/svn/upstream/
>
> ... which fails.
>
> So this is only related to the -o option.
>From your log:
cd /tmp/tmp.e9DyJwzOqX/unpdir/pycparser-2.07+dfsg ; ta
tags 678760 patch
thanks
Trivial patch to fix the FTBFS with libsvn-dev 1.7. This is one of
those cases, as we see with major new g++ / libstdc++ releases, where
an include has been missing all along, just not previously noticed.
From: Peter Samuelson
Subject: Include needed headers
Origin
[Stefano Rivera]
> Since upgrading to subversion 1.7, svn-inject no longer works:
>
> > ...
> > svn co svn+ssh://purcell/tmp/test/pycparser/trunk /tmp/tmp.jKa9wdfMh5/trunk
> > svn: E125001: Couldn't determine absolute path of '.'
> > svn: E02: No such file or directory
> > mkdir -p /tmp/tmp.j
[Neil Williams]
> Frankly, the new subversion working copy structure is insane and will
> break hundreds of tools of all different kinds by removing the .svn
> directory.
"Hundreds of tools" try to look inside the .svn directory? They
shouldn't, and they never should've. The working copy format
[Daniel Leidert]
> --- /usr/bin/svn-do.orig 2010-05-23 17:48:50.0 +0200
> +++ /usr/bin/svn-do 2012-06-20 20:12:50.0 +0200
> @@ -50,7 +50,7 @@ case "$1" in
> esac
> done
>
> -if ! [ -d .svn ]; then
> +if ! `svn info > /dev/null 2>&1`; then
> echo "E: Not in a SVN che
> I had a checked out copy created by svn 1.6; after updating the subversion
> package to 1.7.5, it insisted on running "svn upgrade", which I did.
>
> $ svn st
> ! gif/mobile
>
> Trying to run "svn log" on this directory causes svn to segfault:
Huh. Can you reproduce this? I mean, do y
[Arthur de Jong]
> I'm the upstream author of svn2cl and also a Debian developer. I've
> filed an ITP for it (http://bugs.debian.org/678664) and I'll provide
> a package soon.
Ah, thanks. (You mean bug #678676.) I know I pinged you about this
several months ago, but I should have pinged you aga
Package: lua-svn
Version: 0.4.0-6
Severity: serious
Justification: FTBFS
Please drop the 'Build-Depends: libserf-0-0-dev' from lua-svn. It
appears you do not need this build-dep at all. But if you do need it,
note the package has been renamed to 'libserf-dev'.
Thanks.
--
To UNSUBSCRIBE, em
Package: rapidsvn
Version: 0.12.0dfsg-5
Severity: serious
Justification: FTBFS
Please drop the 'Build-Depends: libserf-0-0-dev' from rapidsvn. It
appears not to be needed. If it _is_ needed, note that I have renamed
the package to 'libserf-dev'.
--
To UNSUBSCRIBE, email to debian-bugs-dist-
[Sven-Haegar Koch]
> $ svn ls https://svn.sdinet.de/src/kernel
> WARNING: gnome-keyring:: no socket to connect to
> ...
(Of course this specific warning from the gnome-keyring library has
since been fixed.)
I have reason to believe this use of gnome-keyring may actually be
caused by libneon27-gn
retitle 678346 subversion: 'svn log' output tricked by symlinks in some cases
found 678346 1.1.0-1
notfound 678346 1.7.5-1
fixed 678346 1.7.5-1
thanks
tl;dr I'm closing this because I believe it is a bugfix, not a bug.
I'm marking it found in 1.1.0, not because I've tested it, but because
that i
tags 539637 wontfix
thanks
> Please split the package into corresponding *-client and
> *-server packages.
libapache2-svn is already a *-server package split out from subversion.
It isn't named *-server but it is server code. Other than that, a
split makes little sense:
(a) Subversion is mostl
> BUILD/subversion/svn/svn --version > /dev/null
> svn: E200019: Version mismatch in 'svn_gnome_keyring': found 1.6.17, expected
> 1.7.5
> make: *** [debian/stamp-build-arch] Error 1
This means libsvn1 1.6.17 is installed in the build chroot. Uninstall
libsvn1 and try again.
This may or may no
> As one can easily test, gpm uses one clip-board space for all users
> (including root). So if any of them marks anything sensitive, a
> following user can gather this information.
Likewise, if you log out, your Linux console screen is still readable
for the next user. And even if you clear th
> Since serf is now in SID, is it possible to push svn 1.7 ?
That's my plan. I uploaded serf last weekend (as you noticed), and
have been working on svn 1.7 this week, hope to upload 1.7.5 today or
tomorrow.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
[Jakub Adam]
> I see you are preparing a package for Subversion 1.6.18 in
> experimental. Would you please consider including the patch from
> #644438 [1] into the final upload? I'd like to finally package
> eclipse-subclipse before Wheezy is frozen.
Actually 1.7.5 if I can manage it. I hope to
> > I just checked the build logs. Every buildd, plus my local amd64
> > build, used gzip 1.4-5.
[Hilko Bengen]
> Strange. Does a rebuild produce different results?
I just downloaded all the libgpm2 debs and compared them and you are
right: the amd64 build (the one I uploaded) has a different m
Package: ftp.debian.org
Severity: normal
libsvn-dev is not for use with a 'vcs' but is for _building_ software
that uses a vcs. Thus I think 'libdevel' is more appropriate.
libsvn-ruby and libsvn-ruby1.8 are now transition packages, not ruby
packages, so I think they should go in 'oldlibs'. The
[Hilko Bengen]
> I am preparing an NMU to DELAYED/7 right now. You can find the changelog
> entry below. A binNMU would not work because it would break
> co-installability with a new changelog entry.
In other words, any 'M-A: same' package that is _ever_ binNMU'd is
broken. Argh.
I just checked
Package: dosemu
Version: 1.4.0+svn.2010-1
Severity: minor
Please update your Build-Depends sometime from libgpmg1-dev to libgpm-dev.
After multiple releases as a dummy package, I've finally gotten around
to dropping libgpmg1-dev entirely. I'm keeping a 'Provides' and of
course I can keep it as l
[Raphael Hertzog]
> It the next upstream version of your javascript library provides new
> files, they will not be in the symlink tree that you built in your
> package. So at runtime, it will fail because of the missing file.
Forgive me if I'm missing something basic here, but this sounds like a
severity 675987 important
thanks
[Daniel Leidert]
> Package misses a proper Replaces, because it overwrites
> /usr/lib/x86_64-linux-gnu/jni/libsvnjavahl-1.so.0.0.0 also in
> libsvn-jni <<1.6.17dfsg-4~.
Argh, you're right. For a package that was in sid for only 2 days,
that 1.6.17dfsg-3.1 NMU h
[OndÅej Surý]
> I did reply you:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621460#34
>
> and you didn't respond from that time at all.
Yes, your reply was:
| I thing it is reasonable that in your case it's probably better to
| either depend directly on libdb5.1-dev + db5.1-util (and
[Stefan Lippers-Hollmann]
> I'd like to ask you to consider uploading the attached NMU diff or
> something equivalent
Ah yes - sorry about that! I completely forgot that this hadn't been
done yet. I will try to find time to do an upload in the next couple
of days.
Thanks for your patch! It lo
[Petr Vorel]
> subversion site has been migrated to http://subversion.apache.org some time
> ago. Please
> update watch file (actually last version from old site is 1.6.18 - not sure
> if you're
> going to package it or if you take 1.7.4).
Right, the 1.6 series is still hosted at subversion.tig
[Arno Töll]
> as promised lately I investigated the issue with your package manually
> now. The Debian version of subversion is not compatible with the new
> upstream release of Apache 2.4, subversion 1.7.4 however is [1].
Thanks for investigating and all that helpful information!
> Note, subve
[Lucas Nussbaum]
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
This looks a lot like a failure due to apr 1.4.6, which now randomizes
hash enumeration for security reasons. This then randomizes the
ordering of a lot of things in the Subversion API, which doe
[Friedrich Delgado]
> The problem is that the order of matches is non-deterministic since
> this monday for me (I can't see a relevant updated package, but it
> used to work before).
I'm guessing this is the fault of apr 1.4.6, which randomizes hash
table ordering for security reasons. (Some has
reassign 668825 subcommander
tags 668825 patch
thanks
[Robert Luberda]
> I guess subcommander uses some libsvn symbols that it shouldn't use,
> however I have no idea how to find which ones. That's why I'm
> reporting this bug against libsvn-dev.
Good guess, but ... oooh. Interesting - I haven'
[Jari Aalto]
> I'm planning to NMU with changes listed in previous mail's patch to help
> migrate away from deprecated dpatch.
I don't understand the urgency to get away from dpatch
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646420#17 -
I think Marga is right) but I suppose that's a questi
[Jari Aalto]
> I'm planning to NMU with changes listed in previous mail's patch to help
> migrate away from deprecated dpatch.
I don't understand the urgency to get away from dpatch
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646420#17 -
I think Marga is right) but I suppose that's a questi
severity 663424 wishlist
tags 663424 wontfix
thanks
> please use a VCS to package equivs and document it in debian/control
> with the VCS-* lines.
Severity normal? Really? Anyway, I'm not really interested.
Peter
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
close 632573 1.0.1-1
close 525035 1.0.1-1
thanks
[Michael Diers]
> Sorry for the noise, I just noticed that serf (1.0.1-1) is in fact
> available in experimental.
Yes, sorry for not metioning this earlier: the reason I didn't follow
up with your sponsor request is that 1.0.0 -> 1.0.1 was such a
[Brad Spengler]
> Frankly it makes more sense for me to offer .debs myself than to deal
> with a bureaucracy and non-standard kernel in Debian. It contains
> who-knows-what extra code, and I doubt anyone looked at any of it to
> see if it allows for some way to leak information I prevent against
[Diego Fernández Durán]
> What's the state of Subversion 1.7 packaging for Debian?
> Is there any way in which I can help?
I've just been really really short on time. I hope I can find time to
get a 1.7 package uploaded this weekend. I will probably disable serf
support on kFreeBSD until I
[Jakub Adam]
> upstream accepted my OSGi metadata patch for JavaHL and commited to
> trunk. Until this version is released and packaged, could you please
> add the attached file to debian/patches?
Ah, yeah, I see, r1234864 upstream. Sure, I'll do the equivalent in my
next upload, which I reall
[Nicolas Bonifas]
> svn-bisect doesn't behave as expected if good_rev > bad_rev (a
> subsequent "svn-bisect bad" command will select the wrong half of the
> suspucious revisions).
Indeed. When I (re-)wrote it I assumed the only interesting case was
to detect a regression (good < bad). But 'good
> Another detail I missed before: nowadays apr_generate_random_bytes()
> reads from urandom, not /dev/random, so this would not cause
> bug#285708 to come back.
Right. Now that apr reads /dev/urandom, there doesn't seem to still be
a need for this patch. I suppose I'll remove it in the next upl
Package: swaks
Version: 20100211.0-4
Tags: patch
The timezone field of RFC 822 date format is [+-]HHMM, whereas swaks
calculates it as hundredths-of-an-hour. So it is wrong any time the MM
field is nonzero. For example:
Timezone RFC822 swaks
---
Ca
1 - 100 of 800 matches
Mail list logo
