-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All the reports of this that I can remember seeing were with 1.0.x
versions. I don't remember it being debugged, but the problem seems to
have vanished.
Has the problem been observed with current versions of Subversion?
Max.
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The only possibility for debugging I can see would be to reproduce the
problem with a debug build of svn, running under gdb, accessing the
problem repository.
If this can be done, great!
If not, I think this is going to remain an unsolved mystery.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marc Haber wrote:
Package: subversion
Version: 1.2.3dfsg1-2
Severity: wishlist
for some automatic processes invoked via ssh authentication (with an
ssh key restricted to svnserve -t in authorized_keys, for example, it
would be desireable to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tags 341438 + upstream fixed-upstream
thanks
Marc Haber wrote:
On Sat, Dec 03, 2005 at 01:46:19PM +, Max Bowsher wrote:
Uh... an -R (--read-only) option *ALREADY* exists. In fact, it has been
deprecated in favour of a repository's
Can you give more detail about how to reproduce the error?
It certainly isn't a common error, so it must be being triggered by
something unique to your system.
It would be useful to know what access method you are using (file:///,
svn://, http://), as well as anything else you think might be
retitle 343142 -r {DATE} option could support more date formats
thanks
Early versions of Subversion used a yacc-based date parser which
supported a range of date formats similar to CVS. The yacc-based parser
was abandoned and replaced with a handwritten C parser supporting only a
few date formats
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Vaughan wrote:
The subversion book says subversion accepts
--revision {2002-02-17}
--revision {2002-02-17 15:30}
etc.
(see http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-3-sect-3.3 )
This is correct. The problem is simply not
The problems encountered here were due to an unusual once-off need to add
new APIs to an old branch in order to fix a security bug. This wasn't
handled perfectly by the Subversion project - with hindsight, we should have
ensured that the emergency-fixed 1.0 API was a subset of the 1.1 API, and
Package: adduser
Version: 3.80
Currently, --firstuid (and --lastuid) are silently ignored when used
with the --system option:
[EMAIL PROTECTED]:~$ sudo adduser --system --firstuid 200 test1
Adding system user `test1'...
Adding new user `test1' (102) with group `nogroup'.
^^ UID 102 was
Marc Haber wrote:
On Mon, Dec 26, 2005 at 04:53:04PM +, Max Bowsher wrote:
The help doesn't mention any use of --firstuid with --system, but this
would be useful to allow local non-human users, to be created in a
separate uid range to the system users created by Debian packages
It seems that the linked-to files are an unmaintained fork of the
official Subversion bash_completion files.
Perhaps this bug should be disposed of, in favour of packaging the
actively maintained bash_completion file shipped with Subversion.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
This bug is very over-anticipatory, given that a working svn-config has
not been written yet, and no-one has shown any particular inclination to
write one, a situation which has been in existence for years.
If this was a Bugzilla installation, I'd classify this bug as RESOLVED
INVALID. I'm not
Hi, I'm an upstream Subversion developer, adding a few comments to this
discussion.
I agree that converting to FSFS is a workaround, not a fix.
However, there is not enough information in this bug report as-is for anyone
to do anything useful with it.
High volume of activity alone is
retitle 269635 Doxygen API documentation not built and installed
severity 269635 normal
stop
There is not a complete lack of API documentation - the doxygen docs are
generated from the comments in the header files themselves - thus, the
documentation exists, albeit without the hyperlinking and
I have followed the procedure outlined by the submitter as closely as
possible, and coded a reproduction script.
No data loss occurs for me - at the point where the sumitter writes all of
dir c, including the local modifications got erased, what happens to me is:
any files within dir c which
Since 1.2.x versions have entered Debian, this bug ought to be closable now.
There is a reproduction script earlier in the bug to verify this.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Now that Subversion has reached 1.x, the compatibility rules we work too are
much stricter - all 1.x versions of Subversion must and will be able to work
with the database of any earlier 1.x version.
Therefore, I think this bug can be closed with no further action.
Max.
--
To UNSUBSCRIBE,
In 1.2.3a-1, the file avoids all controversy by simply saying svnadmin
create /path/to/repos.
I think this bug can now be closed.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Current python2.3-subversion packages seem to depend on a libsvn0 at least
as new as themselves, thus, I believe this bug is fixed now, and should be
closed.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 339298 + upstream fixed-upstream
stop
Fixed in Subversion 1.3.0.
Max.
signature.asc
Description: OpenPGP digital signature
To me, it is very unintuitive for a sysadmin to be expected to move away
a file which is normally under logrotate control.
At a minimum, I would suggest that the alert email contain a reference
to README.Debian.html section 2.5.1, so that sysadmins seeing this can
more quickly understand what's
Mark Purcell wrote:
On Friday 27 October 2006 13:03, Max Bowsher wrote:
Dropping support for wct4xxp represents a critical regression to people
using that hardware.
Max,
I would suggest you have a read of:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388756
wct4xxp was removed
severity 389780 normal
thanks
setuptools earlier than 0.6c3 do not support Subversion 1.4, which is
currently in unstable.
Specifically, attempting to install a setuptools-using python package
from a Subversion 1.4 working copy fails.
An update to 0.6c3 is needed to fix this loss of
Package: python-semanage
Version: 1.6.16-3
Severity: normal
python-semanage has a Conflicts against python2.4-semanage so that the
old package is removed upon upgrade. However, this does not work,
because the version range is (= 1.6), but 1.6-1 is a version of the
old package, which does not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Branden Robinson wrote:
reopen 246285
found 246285 1.0.2-2
close 246285 1.2.3dfsg1-3
thanks
On Thu, Jan 12, 2006 at 12:48:41PM -0800, Debian Bug Tracking System wrote:
I tested 1.1.4-2 (current sarge) and confirmed the presence of the bug.
I
Package: initscripts
Version: 2.86.ds1-4
Severity: minor
On a simple single partition system, /proc is the only non-root non-swap
non-noauto filesystem in fstab - i.e. it is the only filesystem that is
a candidate for 'mount -a'.
When mountall.sh runs, /proc is often already mounted. If this is
I too would like to register a complaint about broken working methods
with sudo 1.6.8p7-1.3.
The preservation of all environment variables is not necessarily a
security flaw when done by a user with ALL commands sudoers rights. When
such a user is using 'sudo -s', it can be highly desirable not
tags 343142 + upstream wontfix
thanks
The issues raised have easy alternate solutions:
(1) Whilst Subversion doesn't understand -r {`date`}, it does
understand -r {`date -Is`}.
(2) Whilst Subversion doesn't understand -r {3 days ago}, date can
help out there too: -r {`date -Is -d '3 days
libsvn0 1.2.3.dfsg1-3 has no indirect library dependencies, which would
make this bug fixed, I think?
Max.
signature.asc
Description: OpenPGP digital signature
tags 269365 + patch
thanks
From 1.3.0 onwards, adequate Makefile support is in place to make this
fairly easy.
Attached is a patch which adds a new libsvn0-doc subpackage containing
doxygen docs.
Max.
Index: debian/control
===
---
tags 269365 - patch
thanks
Oops, transposition error in bug number, sorry.
Max.
signature.asc
Description: OpenPGP digital signature
tags 269635 + patch
thanks
From 1.3.0 onwards, adequate Makefile support is in place to make this
fairly easy.
Attached is a patch which adds a new libsvn0-doc subpackage containing
doxygen docs.
Max.
Index: debian/control
===
---
According to http://bugs.mysql.com/bug.php?id=27694 this was fixed
upstream as of 5.0.50, so the current unstable package is probably no
longer affected.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Torsten Landschoff wrote:
From this information I created the following quick hack to fix or at
least work around the problem. It would surely be more elegant to get
the type once. OTOH the interaction with the svn server will most
probably be much slower than the swig type lookups.
Index:
warrants severity=important.
Max Bowsher.
signature.asc
Description: OpenPGP digital signature
Package: python-moinmoin
Version: 1.5.3-1.1
Severity: important
Password reminder emails send by moinmoin display incorrect passwords,
since the reminder passwords sent by moinmoin always end with an '=',
which gets eaten by incorrect quoted-printable encoding.
See
This sounds quite likely to be the same as
http://subversion.tigris.org/issues/show_bug.cgi?id=2580
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fixed upstream in 1.3.0.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Feature is present on development trunk, and will be in 1.3.0.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reassign 291390 subversion-tools
merge 291390 324511
quit
#324511 links to a later version of svn2cl.xsl than is attached to #291390.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
It is a bug in the pl.po message catalog.
Fixed in trunk r15880.
Fixed in 1.2.x branch ready for 1.2.4.
Not fixed in about-to-be-released 1.2.3, tarballs were already rolled and in
final QA.
Patch:
svn diff -r15879:15880
http://svn.collab.net/repos/svn/trunk/subversion/po/pl.po
Max.
--
This is not a bug.
The URL with the trailing colon is not valid, and as already mentioned svn
switch --relocate is the way to fix this.
This bug can be closed.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This is fixed in Subversion 1.2.0 and later.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This feature is implemented in Subversion 1.2.x.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
The language does say *If* the directory db contains a Berkeley DB
environment, but I agree that's a bit pathetic.
Taken upstream. Ought to be fixed for 1.3.0.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
As Wesley J. Landaker says above, this is NOT a bug.
It would conceivably be possibly to relax a few restrictions to allow this
to work in additional - but not all - cases.
Anyway, either this bug should be closed, or it needs to be taken upstream,
because fixing it would be more complex
4096 bit RSA keys seem particularly common in my experience, could that
variant be considered for the the package, soon?
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Details, including tarballs of pregenerated keysets and painfully
detailed information on how to be a script kiddie, are now published by
the metasploit project (which is linked from wiki.debian.org/SSLkeys,
even) so I think the benefits of secrecy have been eroded by now.
The only missing piece
I'm not sure whether Debian will ship blacklists generated by others,
since there's no way to verify a blacklist other than regenerating it
yourself, but I have generated RSA 1023, 1024 and 4096 bit blacklists
for my own use - available here: http://www.red-bean.com/~maxb/ .
These are i386+amd64
Package: apt
Version: 0.7.14
Severity: normal
apt-get --no-install-recommends disables the behaviour of
APT::Install-Recommends, but does not disable any configured
APT::Install-Recommends-Sections. This is rather perplexing to users
who don't understand the details of how APT manages its
Package: apt
Version: 0.7.14
Severity: wishlist
The -o command line option allows arbitrary overriding on scalar-valued
configuration items, and appending extra entries to list-valued
configuration items. However, the ability to completely override the
contents of a list-valued configuration item
Package: mercurial
Version: 1.0.1-1
Severity: minor
Quoting from postinst:
ucf --sum-file /usr/share/mercurial/$conffile.md5sums --three-way \
$TMPFILE /etc/mercurial/hgrc.d/$conffile
ucfr mercurial /etc/hgrc.d/$conffile
The 'ucfr' line incorrectly mentions
Package: python-clearsilver
Followup-For: Bug #479637
#479637 is essentially a duplicate of #452612, I think - the missing
Py_InitModule4 symbol is a manifestation of trying to reuse the
python2.4 module with python2.5 - so the bug is fixed in 0.10.4-1.2.
--
To UNSUBSCRIBE, email to [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tags 283992 upstream
thanks
I'd be happy to commit such a patch to the upstream Subversion project,
if you still feel like writing it.
Max.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tags 217133 fixed-upstream upstream
thanks
Done for upstream 1.4.0.
Max.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
iD8DBQFEPnsjfFNSmcDyxYARArAAAJ4nFvBhXWNlICmCwdpKBkGicYXnNACgy2OY
UaSMK0NkLlKphHj5VTFvP9o=
=BnOq
-END PGP
Package: sqlite3
Version: 3.3.5-0.1
Severity: normal
sqlite = 3.3.3 exposes a bug in some pysqlite versions.
Specifically, the bug is present in:
The 2.0.x series, 2.0.7 (package: python-pysqlite2)
The 1.1.x series, 1.1.7 (package: python-pysqlite)
The 2.1.x series, 2.1.3 (not in
Package: mailman
Version: 2.1.7-2.1.8rc1-1
Severity: important
The explicit zero epoch in this version of the Mailman package exposes a
bug in apt-get: the package is perpetually considered in need of
upgrade, and apt-get reinstalls it every time an upgrade or dist-upgrade
is done.
The current
Package: apt
Version: 0.6.43.3
Severity: normal
Usually, an epoch value is either absent, and so zero implicitly, or
explicitly present and greater than zero.
If a package version number includes an explicit epoch value of zero,
apt-get misbehaves, considering the version present in the available
tags 233099 upstream fixed-upstream
thanks
Subversion trunk (1.4.x-dev) now (r18522) has support for per-subcommand
varying of option descriptions, and uses it to avoid the overgeneral
description for the --file option.
Fixed.
Max.
signature.asc
Description: OpenPGP digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Samuelson wrote:
[Julian Gilbey]
burnside:~/debian/tex/tetex-bin $ perl -MSVN::Client -e \
'sub print_names { print $_[0]\n; } $ctx=new SVN::Client;
$ctx-status(, BASE, \print_names, 1, 1, 0, 1);' | head -5
.pc
.pc/.version
Package: libreadline5
Version: 5.1-5
Severity: minor
libreadline5_5.1-5_amd64.deb has the file
/usr/share/doc/libreadline5/examples/Inputrc
owned by uid 286.
The sparc and i386 packages have correct (root) ownership.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
tags 347725 - patch
merge 347725 343113
thanks
It is true that the config/postinst script is causing an invalid
password to be stored in the directory, but not because of not using
slappasswd.
The perl snippet generates the same crypted password as slappasswd
would, but then bug #343113
retitle 343113 admin password set via debconf is not correctly set in
the ldap directory
severity 343113 serious
thanks
I've increased the severity of this bug, because it affects every fresh
installation of the current etch/sid version, and creates a
hard-to-debug problem for someone new to
Package: dovecot-common
Version: 1.0.beta7-1
Severity: important
I have edited dovecot.conf to use a non-default SSL certificate and key,
instead of /etc/ssl/{private,certs}/dovecot.pem. My cert+key is shared
between multiple services, not only Dovecot.
The Dovecot postinst gets the cert/key
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Laszlo Boszormenyi wrote:
Hi Max!
On Fri, 14 Apr 2006 11:34:56 -0500 Max Bowsher wrote:
sqlite = 3.3.3 exposes a bug in some pysqlite versions.
Specifically, the bug is present in:
The 2.0.x series, 2.0.7 (package: python-pysqlite2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Laszlo Boszormenyi wrote:
On Mon, 2006-05-01 at 13:25 +0100, Max Bowsher wrote:
$ apt-cache show python2.3-pysqlite2
Package: python2.3-pysqlite2
...
Depends: libc6 (= 2.3.5-1), libsqlite3-0 (= 3.3.5), python2.3
...
As you can see
Package: adduser
Version: 3.80
Followup-For: Bug #352496
Cause of the bug appears to be a missing backslash reference operator
inside the call to GetOptions().
Making this one-character fix appears to solve the problem.
-conf=s = $configfile,
+conf=s = \$configfile,
Max.
Package: spamassassin
Version: 3.1.0a-2
Severity: important
As mentioned in bug 278030, spamd --auth-ident is incompatible with
pidentd and gidentd.
Since the cause of this is very obscure, and liable to cause the person
attempting to configure --auth-ident some fruitless struggles, this
should
tags 307184 wontfix
thanks
The indicated script is unmaintained, and includes hardcoded assumptions
about repo naming.
Therefore, tagging wontfix, with a recommendation to close.
There is a bash_completion script maintained within the Subversion
distribution, which is kept up-to-date with
tags 287756 wontfix upstream
thanks
Tagging wontfix, with a recommendation to close, because the reason 'svn
log' defaults to -rBASE:1 when run in a WC is actually dictated by the
underlying structure of the Subversion database:
Whilst the Subversion database makes it very easy to trace history
retitle 359315 Differing versions of libsvn0 vs. subversion packages is
opportunity for confusion
thanks
Perhaps subversion should
Depends: libsvn0 (= ${Source-Version}) ?
This would avoid potential for confusion.
Are there any situations where having differing subversion and libsvn0
versions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Samuelson wrote:
[Max Bowsher]
Perhaps subversion should
Depends: libsvn0 (= ${Source-Version}) ?
This would avoid potential for confusion.
Hmmm. On the one hand, in Debian we try to keep our dependencies only
as tight as they need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Samuelson wrote:
[Max Bowsher]
From 1.3.0 onwards, adequate Makefile support is in place to make this
fairly easy.
Attached is a patch which adds a new libsvn0-doc subpackage containing
doxygen docs.
Thanks! Looks pretty
tags 349825 upstream fixed-upstream
thanks
Fixed in trunk, nominated for 1.3.1.
Max.
signature.asc
Description: OpenPGP digital signature
The current dav_svn.conf is self-consistent, in that it specifies no
uncommented Auth* directives at all.
Therefore, I think whatever trouble this bug report referred to is long
gone, and no further action is required here. The bug looks closeable
as-is to me.
Max.
signature.asc
Description:
tags 282480 upstream fixed-upstream
thanks
mailer.py distributed with 1.3.0 has the ability to include custom diff
urls in the messages.
Max.
signature.asc
Description: OpenPGP digital signature
The script has the fairly serious flaw that on any repository of large
activity, there will be many revisions in which a particular file
undergoes no changes. Thus, very many diff calls will be made, which
discover no difference.
The script could be improved to an acceptable level of efficiency
tags 249683 upstream wontfix
thanks
I have to disagree that this is a common operation - most people use an
editor to compose their log messages, rather than composing them on the
command line.
A full implementation of this feature encounters complexities such as
how to handle commits and log
Package: python-setuptools
Version: 0.6b3-1
Severity: normal
$ easy_install-2.3
...
ImportError: Entry point ('console_scripts', 'easy_install-2.3') not found
The problem is due to the use of python-central to install egg-info built for
Python 2.4 into the python2.3/site-packages dir.
Package: python-json
Version: 3.4-1
Severity: normal
Installing python-json causes the directory
/var/lib/python-support/python2.4/json_py-3.4-py2.3.egg-info to be
created. Note the mismatch between python versions in the containing
directory, and the egg-info name.
This creates issues for the
Package: python-formencode
Version: 0.4-5
Severity: wishlist
Please package new upstream version 0.5.1 - thanks!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: simplejson
Version: 1.1-1
Severity: normal
The content of the debian/copyright file appears to be intended for a
different package entirely. It refers to a piece of software called
'Pyflakes', and makes no reference to simplejson.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Package: simplejson
Severity: wishlist
Please package new upstream version 1.3 - thanks!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Gustavo Noronha Silva wrote:
Hey Max!
Em Sáb, 2006-06-10 às 06:23 -0500, Max Bowsher escreveu:
Whilst pkg_resources.require() tolerates this, and still finds the
json-py egg, setuptools' easy_install does *not* find it, because it
performs filtering based on Python version declared in egg
Package: python-configobj
Version: 4.3.1-1
Severity: normal
The .egg-info directory installed by python-configobj includes the
-py2.3 substring identifying it as version specific. Since the package
tries to be handled through python-support, it should remove the
version-specific specifier from
tags 373387 patch
done
Here's an attempt at upgrading the package to the new Python policy.
Max.
Index: debian/control
===
--- debian/control (revision 588)
+++ debian/control (working copy)
@@ -3,7 +3,7 @@
Priority:
Package: bidentd
Severity: important
Justification for severity(important): An update to latest upstream
would solve the bug which is currently keeping bidentd out of testing.
Getting bidentd back into testing soon would be very nice, as it is not
just yet another identd - it's an identd with a
Package: apt-show-versions
Version: 0.09
Severity: normal
apt-show-versions is misbehaving for mailman. It says...
# apt-show-versions mailman
mailman 2.1.8-1 installed: No available version in archive
...but it is wrong, there is an available version...
# apt-cache policy mailman
mailman:
is still active at the time of disconnect.
Either calling $sth_vars-finish;, or moving the 5 lines concerning
$sth_vars into an enclosing block to cause $sth_vars to go out of scope
as soon as it is no longer required successfully avoid the warning.
Max Bowsher.
--
To UNSUBSCRIBE, email to [EMAIL
Package: x11-common
Version: 1:7.0.20
Severity: important
x11-common contains versioned conflicts with many old xorg-x11 packages
using the version specifier '= 6.9.0.dfsg.1-6'.
However, there was an AMD64 binNMU into testing via
testing-proposed-updates, of version 6.9.0.dfsg.1-6+b1, which
Package: python-setuptools
Version: 0.6b3-3
Severity: normal
/usr/bin/easy_install-2.3 contains a clearly invalid shebang of:
#!/usr/bin/python2.4
This makes it rather difficult to perform easy_install maintenance on
Python 2.3 packages.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Package: ntp
Version: 1:4.2.2+dfsg-1
Severity: important
Setting severity to important for now, since I cannot actually point to
a specific policy directive, but this should quite possibly be elevated
to serious.
Upgrading to the 4.2.2 ntp packages, which merge the ntp-server and
ntp-simple
to be sure that this issue receives human attention before testing
migration, which the abnormal shortening of the 10-day delay due to the
sticky high urgency persisting from two months ago might otherwise
circumvent.
Thanks,
Max Bowsher.
signature.asc
Description: OpenPGP digital signature
Peter Eisentraut wrote:
Max Bowsher wrote:
Upgrading to the 4.2.2 ntp packages, which merge the ntp-server and
ntp-simple packages into the ntp package leaves the old packages in
the 'config-files' state. In particular, this leaves active cron
scripts under the name 'ntp-server', which
Package: grub
Version: 0.97-12
Severity: normal
Suppose you have kernel 2.6.15-1-somearch installed, and also have
2.6.15-1-somearch-somesuffix.
If you set the default kernel to 2.6.15-1-somearch, and run update-grub
with grub's 'update the default setting to continue pointing to the same
Package: mailman
Version: 2.1.7-1
Severity: important
Mailman's postinst currently contains the following command:
chmod o-r,o+x /var/lib/mailman/archives/private
The effect of o+x permissions on this directory is that ANY local user
has read access to ALL mailman mail archives, if they
severity 427804 important
thanks
Based on my own and the other users comments above, I think it's
reasonable to say that this bug has a major effect on the usability of
the package.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Package: zaptel
Version: 1:1.2.7.dfsg-1
Severity: important
Justification: Renders package unusable to users of specific hardware
Dropping support for wct4xxp represents a critical regression to people
using that hardware.
Ideally, a non-free package would have been created to avoid
Package: reprepro
Version: 3.9.2-1
Severity: normal
Tags: patch
I was trying to set up an 'update', and provided a 'VerifyRelease:' with
16-digit keyid as specified in the manpage. It appeared to be ignored.
After a bit of debugging, I found an off-by-one error in signature.c
line 129:
Dmitrijs Ledkovs wrote:
--- debian/rules (revision 2804)
+++ debian/rules (working copy)
@@ -10,17 +10,15 @@
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/rules/patchsys-quilt.mk
DEB_INSTALL_DOCS_ALL=
+DEB_PYTHON_DESTDIR =
1 - 100 of 151 matches
Mail list logo
